Serializable 接口和 Parcelable 接口區別:

一、前言:

Serializable和Parcelable接口可以完成對象的序列化的過程,當我們需要通過Intent和Binder傳輸數據時就需要使用Parcelable或者Serializable,有時候我們還需要把對象持久化到存儲設備上或者通過網絡傳輸給其他客戶端,這個時候也需要使用Seriazable來完成對象的持久化。

二、Serializable接口:

1. Serializable簡介:

Serializable 是Java所提供的一個序列化接口,它是一個空接口,為對象提供標準的序列化和反序列化操作。使用Serializable來實現序列化相當簡單,只需要類在聲明中指定一個類似下面的標示即可實現默認的序列化過程。

public class User implements Serializable{

    private static final long serialVersionUID=1L;
    private String name;
    private int age;
}

所以如果想讓一個類實現序列化,只需要將這個類實現Serializable接口,并聲明一個seriaVersionUID即可,實際上,甚至這個seriaVersionUID也不是必需的,我們不聲明這個serialVersionUID,同樣也可以實現反序列化,但是這將會對反序列化過程產生影響,具體影響我們后面介紹。

2. Serializable序列化和反序列化

我們舉一個例子吧,Person類是一個實現了Serializable接口的類,它有3個字段,name,sex,age

public class Persion implements Serializable{
  private static final  long serialVersionUID=1L;
  public String name;
  public String sex;
  public int age;

  public Persion(String name,String sex,int age){
         this.name=name;
         this.sex=sex;
         this.age=age;
  }
}

通過Serializable方式來實現對象的序列化,實現起來非常簡單,幾乎所有工作都被系統自動完成了。對象的序列化和反序列化也非常簡單,只需要采用ObjectOutputStream和ObjectInputStream即可輕松實現。代碼如下:

//序列化過程
Person person=new Person("張三","男",23);
ObjectOutputStream out=new ObjectOutputStream(new FileOutStream("cache.txt"));
out.writeObject(person);
out.close();

//反序列化過程
ObjectInputStream in=new ObjectInputStream(new FileInputStream("cache.txt"));
Person newPerson=(Person)in.readObejct();
in.close();

上面的代碼演示了采用Serializable方式序列化對象的典型過程,很簡單,只需要把實現了Serializable接口的Person對象寫到文件中就可以快速恢復了,恢復后的對象newPerson和person內容完全一樣,但是兩者并不是同一個對象。

3. serialVersionUID的作用

即使不指定serialVersionUID也可以實現序列化,那到底要不要指定呢?serialVersionUID后面的數字有什么含義?

這個serialVersionUID是用來輔助序列化和反序列化的過程。原則上序列化后的數據中的serialVersionUID只有和當前類的serialVersionUID一致才能成功的反序列化.

serialVersionUID的詳細工作機制是這樣的:序列化的時候系統會把當前類的serialVersionUID寫入序列化的文件中(也可能是其他中介),當反序列化的時候系統會去檢測文件中的serialVersionUID,看它是否和當前類的serialVersionUID一致,如果一致就說明序列化的類的版本和當前類的版本是相同的,這個時候可以成功反序列化;否則就說明當前類和序列化的類相比發生了某些變換,比如成員變量的數量、類型可能會發生變化,這時候就無法正常的反序列化。會報如下錯誤:

java.io.InvalidClassException

所以一般來說,我們應該手動去指定serialVersionUID的值,比如"1L",也可以讓IDE根據當前類的結構去生成對應的hash值,這樣序列化和反序列化時兩者的serialVersionUID是相同的,因此可以正常的進行反序列化。如果不不設置serialVersionUID,系統在序列化的時候默認會根據類的結構在生成對應的serialVersionUID,在反序列化的時候,如果當類有變化,比如增加或者減少字段,這時候當前的類的serialVersionUID和序列化的時候的serialVersionUID就不一樣了,就會出現反序列化失敗,如果沒有捕獲異常會導致crash。

所以當我們手動制訂了它之后,就可以很大程度上避免了反序列化過程的失敗

比如當版本升級以后,我們可能刪除了某個成員變量也可能增加一些新的成員變量,這個時候我們的反序列化過程仍然可以成功,程序仍然能夠最大限度地恢復數據。相反 如果我們沒有指定serialVersionUID的話,程序就會掛掉。當然我們也要考慮到另外一種情況,如果類結構發生了給常規性的改變,比如修改了類名,修改了成員變量的類型,這個時候盡管serialVersionUID驗證通過了,但是反序列化過程還是會失敗,因為類的而結構有了重大改變,根本無法從老版本的數據還原出一個新的類結構對象。

4. 補充

通過上面的分析,我們知道給serialVersionUID指定為1L或者采用IDE根據當前類結構去生成的hash值,這兩者并沒有本質區別,效果完全一樣。再補充三點:

  • 1、靜態成員變量屬于類,不屬于對象,所以不會參與序列化的過程
  • 2、用transient關鍵字編輯的成員變量不參與序列化的過程。
  • 3、可以通過重寫writeObject()和readObject()兩個方法來重寫系統默認的序列化和反序列化的過程。不過本人并不推薦

三、Parcelable接口

Parcelable也是一個接口,只要實現了這個接口,一個類的對象就可以實現序列化和并且通過Intent和Binder傳遞。我們就借用上面Person類來看下代碼:

public class Person implements Parcelable{
    private static final  long serialVersionUID=1L;
    public String name;
    public String sex;
    public int age;

    public Person(String name,String sex,int age){
        this.name=name;
        this.sex=sex;
        this.age=age;
    }

    @Override
    public int describeContents() {
        return 0;
    }

    @Override
    public void writeToParcel(Parcel dest, int flags) {
        dest.writeString(name);
        dest.writeString(sex);
        dest.writeInt(age);
    }

    public static final Parcelable.Creator<Person> CREATOR= new Creator<Person>() {
        @Override
        public Person createFromParcel(Parcel source) {
            return new Person(source);
        }

        @Override
        public Person[] newArray(int size) {
            return new Person[size];
        }
    };

    private Person(Parcel source){
        name=source.readString();
        sex=source.readString();
        age=source.readInt();
    }
}

這里先說一下Parcel,Parcel內部包裝了可序列化的數據,可以在Binder中自由傳輸,從上面的代碼我們可以看出,在序列化的過程中,需要實現的功能有序列化,反序列化的和內容描述。

  • 1、序列化功能由writeToParcel來完成,最終是通過Parcel中的一些列write方法來完成的。
  • 2、反序列化是由CREATOR來完成,其內部標明了如何創建序列化對象和數組,并通過Parcel的一些列read方法來完成反序列化過程。
  • 3、內容描述功能由describeContents方法來完成,幾乎在所有情況下這個方法都應該返回0,僅當前對象中存在文件描述符時,此方法返回1。

Parcelable的方法說明:

方法 功能 標記為
createFromParcel(Parcel source) 從序列化后的對象中創建原始對象
newArray 創建指定長度的原始對象數組
Person(Parcel source) 從序列化后的對象中創建原始對象
writeToParcel(Parcel dest, int flags) 從當前對象吸入序列化結構中,其中flag標識有兩種值0或者1,為1時標識當前對象需要作為返回值返回,不能立刻釋放資源,幾乎所有情況都為0 Parcelable.PARCELABLE_WRITE_RETURN_VALUE
describeContents 返回當前對象的內容描述,如果含有文件描述符,返回1,否則返回0,幾乎所有情況都是返回0 Parcelable.CONTENTS_FILE_DESCRIPTOR

系統已經為我們提供了許多實現了Parcelable接口的類,它們都是可以直接序列化的,比如Intent,Bundle,Bitmap等,同時List和Map也可以序列化,不過要求它們的每一個元素都是可以序列化的。

四、Serializable 和Parcelable的區別

1. 平臺區別

  • Serializable是屬于 Java 自帶的,表示一個對象可以轉換成可存儲或者可傳輸的狀態,序列化后的對象可以在網絡上進行傳輸,也可以存儲到本地。
  • Parcelable 是屬于 Android 專用。不過不同于Serializable,Parcelable實現的原理是將一個完整的對象進行分解。而分解后的每一部分都是Intent所支持的數據類型。

2. 編寫上的區別

  • Serializable代碼量少,寫起來方便
  • Parcelable代碼多一些,略復雜

3. 選擇的原則

  • 1、如果是僅僅在內存中使用,比如activity、service之間進行對象的傳遞,強烈推薦使用Parcelable,因為Parcelable比Serializable性能高很多。因為Serializable在序列化的時候會產生大量的臨時變量, 從而引起頻繁的GC。
  • 2、如果是持久化操作,推薦Serializable,雖然Serializable效率比較低,但是還是要選擇它,因為在外界有變化的情況下,Parcelable不能很好的保存數據的持續性。

4. 本質的區別

  • 1、Serializable的本質是使用了反射,序列化的過程比較慢,這種機制在序列化的時候會創建很多臨時的對象,比引起頻繁的GC、
  • 2、Parcelable方式的本質是將一個完整的對象進行分解,而分解后的每一部分都是Intent所支持的類型,這樣就實現了傳遞對象的功能了。

作者:Sophia_dd35
鏈接:http://www.lxweimin.com/p/2ed41bb7aa3a

?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 229,565評論 6 539
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 99,115評論 3 423
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 177,577評論 0 382
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,514評論 1 316
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 72,234評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,621評論 1 326
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,641評論 3 444
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,822評論 0 289
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 49,380評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 41,128評論 3 356
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,319評論 1 371
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,879評論 5 362
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,548評論 3 348
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,970評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,229評論 1 291
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 52,048評論 3 397
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 48,285評論 2 376

推薦閱讀更多精彩內容