Android IPC

1. 什麼是Android IPC

• IPC：inter-process Commnication跨進程的通訊，多進程之間的通訊，不一樣的操做系統有不一樣的通訊方式，Android繼承自Linux，但其IPC並無徹底繼承Linux，除了socket進程通訊以外，其最具特點通訊方式之一的是binder機制
• 爲何須要進程通訊：咱們知道Android通常狀況下一個應用是默認運行在一個進程中，但有可能一個應用中須要採用多進程模式來實現(好比獲取多分內存空間），或者兩個應用之間須要獲取彼此之間的數據，還有AMS（系統服務）對每一個應用中四大組件的管理，系統服務是運行在一個單獨的進程中，這些通通須要IPC
• Android在一個應用中開啓多線程模式
  1. 爲四大組件在Android Manifest中指定Android:process屬性，進程名以 : 開頭的進程屬於當前應用的私有進程，其餘應用的組件不能夠和它在同一個進程中，進程名不以： 開頭的屬於全局進程，其餘應用能夠經過ShareUID方式跑在一個進程中，這意味着能夠共享內存數據。
  2. 多進程運行：咱們知道Android爲每個進程獨立分配了一個獨立的虛擬機，因此在內存分配上是有不一樣的地址空間，因此運行在不一樣進程的四大組件，他們之間沒辦法共享數據，所以咱們須要進程間的通訊
  3. Android進程間通訊方式包括：經過intent傳遞數據，共享文件和sharedPreference，基於binder的message和AIDL還有socket

2. IPC 基礎概念

Serializable和Parcelable接口能夠完成對象的序列化。
序列化是指將一個對象轉化爲二進制或者是某種格式的字節流，將其轉換爲易於保存或網絡傳輸的格式的過程，反序列化則是將這些字節重建爲一個對象的過程。
在Android中，intent和Binder在傳輸數據的時候就須要將對象實現parcelable或者serializable接口。

• Serializable接口：
  1. Java提供的序列化接口，使用時只須要實現Serializable接口並聲明一個serialVersionUID（用於反序列化）
  2. 使用方法

• Parcelable接口：
  Android中Parcelable接口用法

• 二者均可以實現序列化並可用於intent間的數據傳遞，Serializable使用簡單，可是開銷很大，Parcelable是Android中的序列化方式，使用起來麻煩一點，可是效率很高，是Android推薦的方式。Parcelable主要用在內存序列化上，若是要將對象序列化到存儲設備或者經過網絡傳輸也是能夠的，可是會比較複雜，這兩種狀況建議使用Serializable。

• Binder機制：爲何Android 要採用Binder做爲IPC機制？
  1. 性能：Binder數據拷貝只須要一次，而管道、消息隊列和socket都須要2次，共享內存不須要一次內存拷貝，從性能角度來看，binder性能僅次於共享內存。
  2. 穩定性：Binder基於C/S 架構 ，server端與client端相對獨立，共享內存須要考慮訪問臨界資源的併發同步問題，binder結構的穩定性較好

  3. 安全性：Android爲每一個人應用程序分配了本身的UID，進程的UID是鑑別進程身份的重要標誌，Android系統中對外只暴露Client端，Client端將任務發送給Server端，Server端會根據權限控制策略

     Android OS中的Zygote進程的IPC採用的是Socket（套接字）機制，Android中的Kill Process採用的signal（信號）機制等等。而Binder更多則用在system_server進程與上層App層的IPC交互。

Binder在Android系統中江湖地位很是之高。在Zygote孵化出system_server進程後，在system_server進程中出初始化支持整個Android framework的各類各樣的Service，而這些Service從大的方向來劃分，分爲Java層Framework和Native Framework層(C++)的Service，幾乎都是基於BInder IPC機制。

1. Java framework：做爲Server端繼承(或間接繼承)於Binder類，Client端繼承(或間接繼承)於BinderProxy類。例如ActivityManagerService(用於控制Activity、Service、進程等) 這個服務做爲Server端，間接繼承Binder類，而相應的ActivityManager做爲Client端，間接繼承於BinderProxy類。 固然還有PackageManagerService、WindowManagerService等等不少系統服務都是採用C/S架構；
2. Native Framework層：這是C++層，做爲Server端繼承(或間接繼承)於BBinder類，Client端繼承(或間接繼承)於BpBinder。例如MediaPlayService(用於多媒體相關)做爲Server端，繼承於BBinder類，而相應的MediaPlay做爲Client端，間接繼承於BpBinder類。

3. Android 中的binder

參考：
Binder系列—開篇
多是講解Binder機制最好的文章
 Android Bander設計與實現 - 設計篇
Android - Binder驅動

3.1 面向對象的binder IPC

• Binder使用C/S 模式，一個進程做爲server提供諸如視頻解碼，網絡鏈接、查詢等多種服務，多個進程做爲client向server發起服務請求，得到所須要的服務。
• Binder的獨特之處在於Binder對象是一個能夠跨進程實現的的對象，它的實體位於一個進程中，而它的引用則在其餘client進程中，Binder驅動爲面向對象的進程間通訊提供底層支持。

3.2 Binder通訊框架

Binder框架定義了四個角色，Server，Client，ServiceManager，以及binder驅動，驅動運行在內核空間，其餘三者運行在用戶空間。

• Binder 驅動：binder驅動與硬件設備沒有關係，可是它的工做方式與設備驅動程序是同樣的，工做在內核態，提供open(),mmap(),ioctl等標準文件操做，用戶能夠經過/dev/binder來訪問它，驅動負責進程之間binder通訊的創建，傳遞，計數管理以及數據的傳遞交互等底層支持。
• ServiceManager：將Binder名字轉換爲client中對該binder的引用，使得client能夠經過binder名字得到server中binder實體的引用。
• Client和Server在Binder驅動和Service Manager提供的基礎設施上，進行Client-Server之間的通訊
• Server建立了Binder實體，爲其取一個字符形式，可讀易記的名字，將這個Binder連同名字以數據包的形式經過Binder驅動發送給SMgr，通知SMgr註冊一個名叫張三的Binder，它位於某個Server中。驅動爲這個穿過進程邊界的Binder建立位於內核中的實體節點以及SMgr對實體的引用，將名字及新建的引用打包傳遞給SMgr。SMgr收數據包後，從中取出名字和引用填入一張查找表中。
• Server向SMgr註冊了Binder實體及其名字後，Client就能夠經過名字得到該Binder的引用