Android Serialization Comparison

This article transferred from: https://www.zybuluo.com/linux1s1s/note/91046

Note: Some of the content is changed

Using serialization in Android is nothing more than two ways: Parcelable andSerializable

Difference between the two

• Serializable's role is to save the object's properties to local files, databases, network streams, RMI for easy data transfer, which can be within a program or between two programs.
• Parcelable is designed to be designed for efficient transmission of data between different components within a program and between different Android programs (AIDL), because serializable is inefficient, and this data is only available in memory, Parcelable is the carrier of the message through IBinder communication. If you want to learn more about interprocess communication aidl, see blog: Android interprocess communication Ipc_aidl
• Parcelable has better performance than serializable and is smaller in terms of memory overhead, so it is recommended to use parcelable when transferring data between memory, such as transfers between activity
• Serializable data persistence is easy to save, so choose serializable when you need to save or transfer data from the network, because Android versions parcelable may be different, so it is not recommended to use parcelable for data persistence

Serializable

 public  class     Serializabledeveloper implements   Serializable    String name;     int   yearsofexperience;    List  <skill> skillset;     float   Favoritefloat;  static  class  Skill "implements   Serializable {String name;     boolean   programmingrelated; }}

The beauty of serializable is that you only need to implement serializable interfaces for a class and its properties. The Serializable interface is an identity interface (marker interface), which means that Java will efficiently serialize the object without implementing a method.
The disadvantage of this approach is that reflection is used, and the process of serialization is slow. This mechanism creates many temporary objects at serialization time and easily triggers garbage collection.

Parcelable

 Public classVideoImplementsparcelable {Private LongID; PrivateString picture; PrivateString title; PrivateString author; PrivateString duration; PrivateString Uploadtime;  PublicVideo () {} PublicVideo (Parcel input) {ID=Input.readlong (); picture=input.readstring (); Title=input.readstring (); Author=input.readstring (); Duration=input.readstring (); Uploadtime=input.readstring (); }     PublicVideo (LongID, string picture, string title, string author, string duration, string uploadtime) {         This. Author =author;  This. Duration =duration;  This. ID =ID;  This. Picture =Picture ;  This. title =title;  This. Uploadtime =Uploadtime; }     PublicString Getauthor () {returnauthor; }     Public voidSetauthor (String author) { This. Author =author; }     PublicString getduration () {returnduration; }     Public voidsetduration (String duration) { This. Duration =duration; }     Public LonggetId () {returnID; }     Public voidSetId (LongID) { This. ID =ID; }     PublicString getpicture () {returnPicture ; }     Public voidsetpicture (String picture) { This. Picture =Picture ; }     PublicString GetTitle () {returntitle; }     Public voidSettitle (String title) { This. title =title; }     PublicString Getuploadtime () {returnUploadtime; }     Public voidsetuploadtime (String uploadtime) { This. Uploadtime =Uploadtime; } @Override Public intdescribecontents () {return0; } @Override Public voidWritetoparcel (Parcel dest,intflags)        {Dest.writelong (ID);        dest.writestring (picture);        Dest.writestring (title);        Dest.writestring (author);        Dest.writestring (duration);    Dest.writestring (Uploadtime); }     Public Static FinalParcelable.creator<video> Creator =NewParcelable.creator<video>() {@Override PublicVideo Createfromparcel (Parcel source) {return NewVideo (source); } @Override PublicVideo[] NewArray (intsize) {            return NewVideo[size]; }    };}

According to Google engineers, the code will run very fast. One reason is that we have a clear understanding of the process of serialization without the need to use reflection to infer it. The code of the object also needs to be highly optimized for faster serialization.
Therefore, it is obviously not easy to achieve parcelable. Implementing the Parcelable interface requires writing a lot of template code, which makes the object code difficult to read and maintain.

Performance testing

By putting an object into a bundle and then invoking the Bundle#writetoparcel (Parcel, int) method to simulate passing the object to an activity, then take the object out and run it 1000 times in a loop.

Summary

If you want to be a good software engineer, you need to spend more time implementing parcelable, because it will be more than 10 times faster for your object's serialization process and takes up less resources.

But in most cases, Serializable's turtle speed is not too noticeable. You want to steal a little lazy to use it, but remember serialization is a relatively resource-intensive operation, as far as possible use less.

If you want to pass a list that contains many objects, the entire serialization process can take more than a second, which can make the screen turn into a lag.

Another argument is that passing data between activity using serializable in some cases will fail, a case that has not yet been encountered. (Personal guess: is persistent data need to write to the extended SD card, if the write or read fails, then the transmission will fail)

This article was translated and collated from: http://www.developerphil.com/parcelable-vs-serializable/

Android Serialization Comparison