#### 2.3.1 Serializable接口 **Serializable是Java所提供的一個序列化接口，它是一個空接口，為對象提供標準的序列化和反序列化操作**。使用Serializable來實現序列化相當簡單，只需要在類的聲明中指定一個類似下面的標識即可自動實現默認的序列化過程。 參考——[Java中的對象序列化](http://www.hmoore.net/alex_wsc/java/461699) ``` private static final long serialVersionUID = 8711368828010083044L ``` 在**Android中也提供了新的序列化方式，那就是Parcelable接口**，使用Parcelable來實現對象的序列號，其過程要稍微復雜一些，本節先介紹Serializable接口。上面提到，**想讓一個對象實現序列化，只需要這個類實現Serializable接口并聲明一個serialVersionUID即可，實際上，甚至這個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(); 上述代碼演示了采用Serializable方式序列化對象的典型過程，很簡單，**只需要把實現了Serializable接口的User對象寫到文件中就可以快速恢復了，恢復后的對象newUser和user的內容完全一樣，但是兩者并不是同一個對象**。 剛開始提到，即使不指定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值，這兩者并沒有本質區別，效果完全一樣。 以下兩點需要特別提一下， 1. 首先靜態成員變量屬于類不屬于對象，所以不會參與序列化過程； 2. 其次用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'... }