一、前言:
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