IPC簡(jiǎn)介
IPC(Inter-Process Communication)，含義進(jìn)程間通信或者跨進(jìn)程通信，指兩個(gè)進(jìn)程之間進(jìn)行數(shù)據(jù)交換的過程。
Android中特色的兩個(gè)IPC方式：Binder和socket，還有其他如ContentProvider。
Android中的多進(jìn)程
通過給四大組件指定android:process屬性，輕易的開啟多進(jìn)程模式。或者通過JNI在native層fork一個(gè)新的進(jìn)程（微信的保活手段）。
使用shell命令來查看進(jìn)程信息：adb shell ps或者adb shell ps | grep 包名。
另外以":"開頭的進(jìn)程屬于當(dāng)前應(yīng)用的私有進(jìn)程，不以":"開頭的進(jìn)程則屬于全局進(jìn)程，其他應(yīng)用通過shareUID方式可以和它跑在同一個(gè)進(jìn)程里。
多進(jìn)程模式運(yùn)行機(jī)制
android:process導(dǎo)致的主要問題：共享內(nèi)存失敗，因?yàn)槊總€(gè)應(yīng)用/進(jìn)程分配一個(gè)獨(dú)立的虛擬機(jī)，不同虛擬機(jī)在內(nèi)存分配上有不同的內(nèi)存地址空間，導(dǎo)致不同的虛擬機(jī)訪問同一個(gè)類的對(duì)象會(huì)產(chǎn)生多個(gè)副本。具體包括：
1） 靜態(tài)成員和單例模式完全失效
2）線程同步機(jī)制完全失效
3）SharedPreferences的可靠性下降（不支持多進(jìn)程同時(shí)寫操作，一定幾率丟失，底層基于讀寫XML實(shí)現(xiàn)）
4）Application會(huì)多次創(chuàng)建
第四點(diǎn)我們理解為：運(yùn)行在不同進(jìn)程中的組件是屬于兩個(gè)不同的虛擬機(jī)和Application的
同一個(gè)應(yīng)用間的多進(jìn)程即相當(dāng)于兩個(gè)不同應(yīng)用采用了SharedUID的模式。所以系統(tǒng)提供了很多跨進(jìn)程通信方法實(shí)現(xiàn)數(shù)據(jù)交互。實(shí)現(xiàn)跨進(jìn)程通信的方式很多：
1）Intent傳遞數(shù)據(jù)
2）共享文件和SharedPreferences
3）基于Binder的Messenger和AIDL
4）Socket
IPC基礎(chǔ)概念
Serializable接口
Serializable是一個(gè)序列化接口，提供標(biāo)準(zhǔn)的序列化和反序列化操作。在類中聲明如下標(biāo)識(shí)即可自動(dòng)實(shí)現(xiàn)默認(rèn)的序列化
private static final long serialVersionUID = 8887778284818858825L;
同樣不聲明serialVersionUID也是可以的，但是會(huì)影響反序列化過程。
簡(jiǎn)單舉例實(shí)現(xiàn)序列化和反序列化過程，如下
// 序列化
User user = new User(0,"jack",true);
ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream("user.dat"));
out.writeObject(user);
out.close();
// 反序列化
ObjectInputStream out = new ObjectInputStream (new FileInputStream("user.dat"));
User newUser = (User)in.readObject();
in.close();
現(xiàn)在我們來說明serialVersionUID在反序列化過程中的重要作用。原則上序列化后的數(shù)據(jù)中的serialVersionUID只有和當(dāng)前類的serialVersionUID相同才能正常地被反序列化。
serialVersionUID的詳細(xì)工作機(jī)制：
序列化時(shí)候serialVersionUID會(huì)被寫入到序列化的文件（也可能是其他中介），反序列化的時(shí)候系統(tǒng)會(huì)去檢測(cè)文件中serialVersionUID，是否和當(dāng)前類一致，一致說明序列化的類的版本和當(dāng)前類的版本相同，可以成功的反序列化。
一般需要手動(dòng)指定，也可以由當(dāng)前類的結(jié)構(gòu)自動(dòng)去生成hash值并賦值給serialVersionUID。但是建議手動(dòng)指定，盡管版本發(fā)生改變，仍然能最大限度的恢復(fù)數(shù)據(jù)，若不指定則直接崩潰。
不參與序列化化過程的情況：
1）靜態(tài)成員變量屬于類不屬于對(duì)象
2）采用transient關(guān)鍵字修飾的成員變量
Parcelable接口
一個(gè)類通過實(shí)現(xiàn)Parcelable接口，這個(gè)類的對(duì)象就可以實(shí)現(xiàn)序列化并可以通過Intent和Binder傳遞。
public interface Parcelable
{
//內(nèi)容描述接口，基本不用管
public int describeContents();
//寫入接口函數(shù)，打包
public void writeToParcel(Parcel dest, int flags);
//讀取接口，目的是要從Parcel中構(gòu)造一個(gè)實(shí)現(xiàn)了Parcelable的類的實(shí)例處理。因?yàn)閷?shí)現(xiàn)類在這里還是不可知的，所以需要用到模板的方式，繼承類名通過模板參數(shù)傳入
//為了能夠?qū)崿F(xiàn)模板參數(shù)的傳入，這里定義Creator嵌入接口,內(nèi)含兩個(gè)接口函數(shù)分別返回單個(gè)和多個(gè)繼承類實(shí)例
public interface Creator<T>
{
public T createFromParcel(Parcel source);
public T[] newArray(int size);
}
}
下面示例是一個(gè)典型的用法。
public class User implements Parcelable
{
public int userId;
public String userName;
public boolean isMale;
public Book book;
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<MyParcelable> 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().getContextClassLoader());
}
}
系統(tǒng)已實(shí)現(xiàn)Parcelable接口的類有如：Intent，Bundle，Bitmap，甚至List和Map也可以，前提是每個(gè)元素都是可序列化的。
和Serializable接口的差異：
- Serializable使用簡(jiǎn)單但開銷大，序列化和反序列化需要大量的IO操作
- Parcelable使用起來麻煩，但是效率很高，主要應(yīng)用在內(nèi)存的序列化上
Binder
Android開發(fā)中，Binder主要用于Service中，包括AIDL和Messenger（底層即AIDL），這里詳細(xì)介紹AIDL來分析Binder工作機(jī)制。
to edit...
