一、多進(jìn)程的開啟模式
android 中使用多進(jìn)程只有一種方法，那就是給四大組件（Activity/Service/Receiver/ContentProvider）在AndroidMenifest中指定android：process屬性，除此之外沒有其他辦法，也就是說我們無法給一個(gè)線程或者一個(gè)實(shí)體類指定一個(gè)其運(yùn)行時(shí)所在的進(jìn)程。其實(shí)還有另一種非常規(guī)的多進(jìn)程方法，那就是通過jni去native層fork一個(gè)新進(jìn)程，但這不是常用的創(chuàng)建多進(jìn)程的方式。
進(jìn)程名以“：”開頭的進(jìn)程屬于當(dāng)前應(yīng)用的私有進(jìn)程，其它應(yīng)用的組件不可以和它跑在同一個(gè)進(jìn)程中，而進(jìn)程名不以“：”開頭的進(jìn)程屬于全局進(jìn)程，其它應(yīng)用通過ShareUID方式可以和它跑在同一個(gè)進(jìn)程中。
我們知道Android系統(tǒng)會(huì)為每個(gè)應(yīng)用分配一個(gè)唯一的UID，具有相同UID的應(yīng)用才能共享數(shù)據(jù)。兩個(gè)應(yīng)用跑在同一個(gè)進(jìn)程中是有要求的，只有當(dāng)他們有相同的ShareUID和簽名時(shí)才可以，這種情況下他們可以訪問對(duì)方的私有數(shù)據(jù)，比如data目錄，組件信息等，不管他們是否跑在同一個(gè)進(jìn)程中，如果跑在同一個(gè)進(jìn)程中的話還可以共享內(nèi)存數(shù)據(jù)。
一般來說，使用對(duì)進(jìn)程會(huì)造成如下幾方面的問題：
1、靜態(tài)成員和單例模式完全失效。
2、 線程同步機(jī)制完全失效
3、SharedPreferences的可靠性下降。
4、Application會(huì)多次創(chuàng)建。
二、IPC基礎(chǔ)概念介紹
- Serializable接口
- Parcelable接口
- Binder
1、Serializable接口
Serializable是java所提供的一個(gè)序列化接口，它是一個(gè)空接口，為對(duì)象提供標(biāo)準(zhǔn)的序列化和反序列化操作。實(shí)現(xiàn)方式：只需要該類實(shí)現(xiàn)Serializable接口并且在類的聲明中指定一個(gè)類似下面的標(biāo)識(shí)即可自動(dòng)實(shí)現(xiàn)默認(rèn)的序列化過程。
private static final long serialVersionUID = 8711368828010083044L
甚至這個(gè)serialVersionUID 變量也不是必須的，不聲明同樣可以實(shí)現(xiàn)序列化，只是這會(huì)影響其反序列化過程。案例如下：
public class User implements Serializable {
private static final long serialVersionUID = 8711368828010083044L;
public int userId;
public String userName;
public boolean isMale;
}
如何對(duì)對(duì)象進(jìn)行序列化和反序列化也很簡(jiǎn)單，只需要采用ObjectOutputStream和ObjectInputStream即可輕松實(shí)現(xiàn)。下面舉個(gè)簡(jiǎn)單的例子。
//序列化過程
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();
注意：
1/如果我們不手動(dòng)指定一個(gè)ShareUID的值，Eclipse會(huì)自動(dòng)根據(jù)當(dāng)前類的結(jié)構(gòu)去自動(dòng)生成它的hash值，那么當(dāng)當(dāng)前類有改變時(shí)，比如刪除或者增加某個(gè)成員變量，系統(tǒng)會(huì)重新計(jì)算當(dāng)前的hash值并把它賦值給serialVersionUID ，這時(shí)候當(dāng)前類的serialVersionUID 就和序列化數(shù)據(jù)中的serialVersionUID 值不一致導(dǎo)致反序列化失敗，程序就會(huì)出現(xiàn)crash。所以我們手動(dòng)指定serialVersionUID 值可以很大程度上避免反序列化過程的失敗。
2/靜態(tài)成員變量屬于類不屬于對(duì)象，所以不參與序列化過程。
3/transient關(guān)鍵字標(biāo)記的成員變量不參與序列化過程。
2、Parcelable接口
Parcelable也是一個(gè)接口，只要實(shí)現(xiàn)這個(gè)接口，一個(gè)類的對(duì)象就可以實(shí)現(xiàn)序列化并可以通過Intent和Binder傳遞，系統(tǒng)給我提供了許多實(shí)現(xiàn)了Parcelable接口的類，他們都是可以直接序列化的，比如Intent、Bundle、Bitmap等，同時(shí)List、Map也可以序列化，前提是他們里面的每個(gè)元素都是可以序列化的。以下示例是一個(gè)典型用法：
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;
}
//返回當(dāng)前對(duì)象的內(nèi)容描述，幾乎所以情況都返回0。
public int describeContent(){
return 0;
}
//將當(dāng)前對(duì)象寫入序列化結(jié)構(gòu)中，其中flags標(biāo)識(shí)有兩種值：0或者1,
//1時(shí)表示當(dāng)前對(duì)象要作為返回值返回，不能立即釋放資源，幾乎所以情況都為0.
public void witeToParcel(Parcel out,int flags){
out.writeInt(userId);
out.writeString(userName);
out.writeInt(isMale ? 1:0);
out.writeParcelable(book,0);
}
//從序列化后的對(duì)象中創(chuàng)建原始對(duì)象
public static final Parcelable.Creator<User> CREATOR = new Parcelable.Creator<User>() {
public User createFromParcel(Parcel in){
return new User(in);
}
//創(chuàng)建指定長(zhǎng)度的原始對(duì)象數(shù)組
public User[] newArray(int size){
return new User[size];
}
};
//從序列化后的對(duì)象中創(chuàng)建原始對(duì)象
private User(Parcel in){
userId = in.readInt();
userName = in.readString();
isMale = in.readInt() ==1;
book = in.readParcelable(Thread.currentThread().getContextClassLoader());
}
}
對(duì)比:Serializable 是java接口，使用起來簡(jiǎn)單但是開銷大，而Parcelable是Android中的序列化方式，更適合在android平臺(tái)上，用起來麻煩點(diǎn)但是效率很高，這是android 推薦的序列化方式。Parcelable主要用在內(nèi)存序列化上,通過Parcelable將對(duì)象序列化到存儲(chǔ)設(shè)備中或者將對(duì)象序列化后通過網(wǎng)絡(luò)傳輸也是可以的，但是這個(gè)過程稍顯復(fù)雜，因此在這兩種情況下建議使用Serializable ，以上是兩種序列化方式的區(qū)別。
3、Binder
Binder工作機(jī)制：
1、當(dāng)客戶端發(fā)起遠(yuǎn)程請(qǐng)求時(shí)，當(dāng)前線程會(huì)被掛起直至服務(wù)器端進(jìn)程返回?cái)?shù)據(jù)，所以如果一個(gè)遠(yuǎn)程方法是很耗時(shí)的，那么不能再UI線程發(fā)起此遠(yuǎn)程請(qǐng)求。
2、由于服務(wù)端的Binder方法運(yùn)行在Binder線程池中，所以Binder方法不管是否耗時(shí)都應(yīng)該采用同步的方式去實(shí)現(xiàn)，因?yàn)樗呀?jīng)運(yùn)行在一個(gè)線程中了。
為了更好的說明Bindler,下面給一個(gè)Bindler工作機(jī)制圖
其實(shí)我們完成可以不提供AIDL文件即可實(shí)現(xiàn)Bindler，因?yàn)橹蕴峁┰撐募菫榱朔奖阆到y(tǒng)為我們生成代碼。系統(tǒng)根據(jù)AIDL文件生成Java文件的格式是固定的，我們完全可以拋開AIDL文件直接寫一個(gè)Bindler出來，AIDL的本質(zhì)是系統(tǒng)為我們提供一種快速實(shí)現(xiàn)Bindler的工具，僅此而已。
三、Android中的不同IPC方式對(duì)比
