IPC

IPC概念

1. 使用多進程：android:process屬性

2. Android爲每個進程都分配一個獨立的虛擬機，致使在不一樣的虛擬機中訪問同一個類的對象會產生多份副本，即便是public static int sUerId = 1之類的靜態變量也同樣

3. 使用多進程會形成：

   • 靜態成員和單例模式徹底失效
   • 線程同步機制徹底失效
   • SharedPreferences的可靠性降低
   • Application屢次建立

4. Serializable接口

   1. 要想讓一個對象序列化，只須要這個類實現Serializable接口並聲明一個serialVersionUID便可

5. Parcelable接口

   1. 實現decribleContents方法,writeToParcel方法，和CREATOR

6. Binder

Android實現IPC的方式

1. 使用Bundle

2. 使用文件共享

   • 有侷限性，好比並發讀寫
   • 文件共享的方式適合在對數據同步要求不高的進程間進行通訊，而且要妥善處理併發讀寫的問題
   • 不建議在進程間通訊使用SharedPrefetences

3. 使用Messenger

   • 只能串行的方式處理客戶端發來的信息
   1. 服務端進程
      • 咱們須要在服務端建立一個Service，同時建立一個Handler並經過它來建立一個Messenger對象，而後在Service的onBind中返回這個Messenger對象底層的Binder便可
   2. 客戶端進程
      • 首先綁定服務端的Service，綁定成功後用服務端返回的IBinder對象建立一個Messenger，經過這個Messenger就能夠向服務端發送消息了，發送消息類型爲Message對象。這就實現了客戶端到服務端的通訊
      • 若是想要服務端迴應客戶端。須要在客戶端建立一個Handler並建立一個新的Messenger，並把這個Messenger對象經過Message的replyTo參數傳遞給服務端，服務端經過這個replyTo參數就能夠迴應客戶端

4. 使用AIDL

   • AIDL是平常開發涉及進程間通訊時的首選
   1. 服務端
      • 首先建立一個Service，而後建立一個AIDL文件，將暴露給客戶端的接口在這個AIDL文件中聲明，最後在Service中，建立一個類繼承自AIDL接口中的Stub類並實現Stub中的抽象方法，在Service的onBind方法中返回這個類的對象
   2. 客戶端
      • 綁定Service，將服務端返回的Binder對象轉成AIDL接口所屬的類型，接着就能夠調用AIDL中的方法了
   • 拓展：
     • 使用觀察者模式，讓服務端爲被觀察者，客戶端爲觀察者
     • 用RemoteCallbackList來實現刪除跨進程listener接口
     • 服務端進程意外中止，須要重連服務
       1. 給Binder設置DeathRecipient接聽
       2. 或者在onServiceDisconnected中重連遠程服務
     • 如何在AIDL中使用權限驗證功能
       1. 能夠在onBind中進行驗證
       2. 在服務端的onTransact中進行驗證
     • 用Binder鏈接池，將全部AIDL放在同一個Service中去管理

5. 使用ContentProvider

6. 使用Socket(「套接字」)

   1. Socket稱爲「套接字」，分爲流式套接字和用戶數據報套接字，分別對應於網絡傳輸控制層中的TCP和UDP協議

名稱	優勢	缺點	使用場景
Bundle	簡單	只能傳輸Bundle支持的數據類型	四大組件之間進程通訊
文件共享	簡單	不適合高併發，沒法作到進程間即時通訊	無併發訪問情形
AIDL	一對多併發即時通訊		一對多通訊且有RPC需求
Messenger	一對多串行通訊，支持實時通訊	不能處理好高併發，不支持RPC，	低併發的一對多即時通訊，無RPC需求
ContentProvider	支持一對多併發數據共享，	理解爲受約束的AIDL，主要提供CRUD操做	一對多進程間的數據共享
Socket	功能強大，經過網絡傳輸字節流，支持一對多併發實時通訊	不支持直接RPC	網絡數據交換

參考：《Android開發藝術探索》