實現序列化的兩種方式Serializable和Parcelable

Serializable

      Serializable是Java所提供的一個序列化接口,它是一個空接口,爲對象提供標準的序列化和反序列化操作

       libcore/ojluni/src/main/java/java/io/Serializable.java

       public interface Serializable { }

      通過Serializable實現序列化很簡單,只需要我們的類實現Serializable接口並聲明一個serialVersionUID,serialVersionUID如何不實將會影響我們反序列化的過程,User類就是一個實現了Serializable接口的類,它是可以被序列化和反序列化的,如下所
示。     

public class User implements Serializable {
private static final long serialVersionUID = 519067123721295773L;
public int userId;
public String userName;
public boolean isMale;
...
}

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

//序列化過程
User user = new User(0,"jake",true);
ObjectOutputStream out = new ObjectOutputStream(
new FileOutputStream("cache.txt"));
out.writeObject(user);
out.close();
//反序列化過程
ObjectInputStream in = new ObjectInputStream(
new FileInputStream("cache.txt"));
User newUser = (User) in.readObject();
in.close();

       剛開始提到,即使不指定serialVersionUID也可以實現序列化,那到底要不要指定呢?如果指定的話,serialVersionUID後面那一長串數字又是什麼含義呢?我們要明白,系統既然提供了這個serialVersionUID,那麼它必須是有用的。這個serialVersionUID是用來輔助序列化和反序列化過程的,原則上序列化後的數據中的serialVersionUID只有和當前類的serialVersionUID相同才能夠正常地被反序列化。serialVersionUID的詳細工作機制是這樣的:序列化的時候系統會把當前類的serialVersionUID寫入序列化的文件中(也可能是其他中介),當反序列化的時候系統會去檢測文件中的serialVersionUID,看它是否和當前類的serialVersionUID一致,如果一致就說明序列化的類的版本和當前類的版本是相同的,這個時候可以成功反序列化;否則就說明當前類和序列化的類相比發生了某些變換,比如成員變量的數量、類型可能發生了改變,這個時候是無法正常反序列化的,因此會報如下錯誤:

java.io.InvalidClassException: Main; local class incompatible: stream
classdesc serialVersionUID = 8711368828010083044,local class serial-
VersionUID = 8711368828010083043。

       一般來說,我們應該手動指定serialVersionUID的值,比如1L,也可以讓Eclipse根據當前類的結構自動去生成它的hash值,這樣序列化和反序列化時兩者的serialVersionUID是相同的,因此可以正常進行反序列化。如果不手動指定serialVersionUID的值,反序列化時當前類有所改變,比如增加或者刪除了某些成員變量,那麼系統就會重新計算當前類的hash值並把它賦值給serialVersionUID,這個時候當前類的serialVersionUID就和序列化的數據中的serialVersionUID不一致,於是反序列化失敗,程序就會出現crash。所以,我們可以明顯感覺到serialVersionUID的作用,當我們手動指定了它以後,就可以在很大程度上避免反序列化過程的失敗。比如當版本升級後,我們可能刪除了某個成員變量也可能增加了一些新的成員變量,這個時候我們的反向序列化過程仍然能夠成功,程序仍然能夠最大限度地恢復數據,相反,如果不指定serialVersionUID的話,程序則會掛掉。當然我們還要考慮另外一種情況,如果類結構發生了非常規性改變,比如修改了類名,修改了成員變量的類型,這個時候儘管serialVersionUID驗證通過了,但是反序列化過程還是會失敗,因爲類結構有了毀滅性的改變,根本無法從老版本的數據中還原出一個新的類結構的對象。

       根據上面的分析,我們可以知道,給serialVersionUID指定爲1L或者採用Eclipse根據當前類結構去生成的hash值,這兩者並沒有本質區別,效果完全一樣。以下兩點需要特別提一下,首先靜態成員變量屬於類不屬於對象,所以不會參與序列化過程;其次用transient關鍵字標記的成員變量不參與序列化過程。

      系統的默認序列化過程也是可以改變的,通過實現如下兩個方法即可重寫系統默認的序列化和反序列化過程,不過一般情況下我們不需要這麼做

private void writeObject(java.io.ObjectOutputStream out)
throws IOException {
// write 'this' to 'out'...
}
private void readObject(java.io.ObjectInputStream in)
throws IOException,ClassNotFoundException {
// populate the fields of 'this' from the data in 'in'...
}

Parcelable接口

    Parcelable也是一個接口,只要實現這個接口,一個類的對象就可以實現序列化並可以通過Intent和Binder傳遞。

public class User implements Parcelable {
public int userId;
public String userName;
public boolean isMale;
public Book book;
public User(int userId,String userName,boolean isMale) {
this.userId = userId;
this.userName = userName;
this.isMale = isMale;
}
public int describeContents() {
return 0;
}
public void writeToParcel(Parcel out,int flags) {
out.writeInt(userId);
out.writeString(userName);
out.writeInt(isMale ? 1 : 0);
out.writeParcelable(book,0);
}
public static final Parcelable.Creator<User> CREATOR = new Parcelable.
Creator<User>() {
public User createFromParcel(Parcel in) {
return new User(in);
}
public User[] newArray(int size) {
return new User[size];
}
};
private User(Parcel in) {
userId = in.readInt();
userName = in.readString();
isMale = in.readInt() == 1;
book = in.readParcelable(Thread.currentThread().getContextClass-
Loader());
}
}

Parcel內部包裝了可序列化的數據,可以在Binder中自由傳輸。從上述代碼中可以看出,在序列化過程中需要實現的功能有序列化、反序列化和內容描述。序列化功能由writeToParcel方法來完成,最終是通過Parcel中的一系列write方法來完成的;反序列化功能由CREATOR來完成,其內部標明瞭如何創建序列化對象和數組,並通過Parcel的一系列read方法來完成反序列化過程;內容描述功能由describeContents方法來完成,幾乎在所有情況下這個方法都應該返回0,僅噹噹前對象中存在文件描述符時,此方法返回1。需要注意的是,在User(Parcelin)方法中,由於book是另一個可序列化對象,所以它的反序列化過程需要傳遞當前線程的上下文類加載器,否則會報無法找到類的錯誤

系統已經爲我們提供了許多實現了Parcelable接口的類,它們都是可以直接序列化的,比如Intent、Bundle、Bitmap等,同時List和Map也可以序列化,前提是它們裏面的每個元素都是可序列化的。既然Parcelable和Serializable都能實現序列化並且都可用於Intent間的數據傳遞,那麼二者該如何選取呢?Serializable是Java中的序列化接口,其使用起來簡單但是開銷很大,序列化和反序列化過程需要大量I/O操作。而Parcelable是Android中的序列化方式,因此更適合用在Android平臺上,它的缺點就是使用起來稍微麻煩點,但是它的效率很高,這是Android推薦的序列化方式,因此我們要首選Parcelable。Parcelable主要用在內存序列化上,通過Parcelable將對象序列化到存儲設備中或者將對象序列化後通過網絡傳輸也都是可以的,但是這個過程會稍顯複雜

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章