Linux IPC 機制
IPC(InterProcess Communication)進程間通訊，我們都知道Android內核其實就是Linux內核，而每個Android Application進程其實就是一個Linux進程，Linux 已經有比較好的IPC機制，爲什麼Android用Binder實現IPC機制呢？，分析Linux 一下的IPC 機制，方便深入理解Android Binder機制。
Linux 現有IPC機制
- 1.管道(pipe)
- 2.信號量
- 3.信號
- 4.消息隊列
- 5.共享內存
- 6.socket
管道
- 數據拷貝兩次(讀取端 & 寫入端)
- 藉助內核緩存區(4K 限制)
信號量
- 資源共享，（PV操作）信號量提供互斥鎖，防止多進程訪問資源衝突。主要用於多進程和多線程的同步手段
信號
- 進程間通信外，進程還可以發送信號給進程本身，多用於消息傳遞 & 通知，不適合傳遞信息。
消息隊列
- 數據拷貝兩次，數據有最大限制。
共享內存
- 可直接加載到內存，但是不提供同步工具，需要結合類似信號量使用。
socket
- 傳輸效率低，C/S架構，多用於跨網絡,跨設備的通信
參考
爲什麼選用Binder作爲Android IPC機制呢
- 從性能來說，管道、消息隊列、Socket對數據都會進行兩次拷貝，耗費性能，而Binder只需要一次，對於移動設備來說，性能不得不考慮。
- 從架構來看，C/S架構，功能分離明確，穩定性好
- 最重要的一點，Linux IPC 無法鑑別身份，而Binder 可以鑑別用戶進程Uid，給予Android身份機制。
- 從語言來說，Linux 是基於C語言面向過程，而Binder是基於Java面向對象來實現的。
貼出 Gityuan 的架構分析
最後，簡單講講Android
* Binder架構Binder在Android系統中江湖地位非常之高。在Zygote孵化出system_server進程後，在system_server進程中出初始化支持整個Android framework的各種各樣的Service，而這些Service從大的方向來劃分，分爲Java層Framework和Native Framework層(C++)的Service，幾乎都是基於BInder IPC機制。
* Java framework：作爲Server端繼承(或間接繼承)於Binder類，Client端繼承(或間接繼承)於BinderProxy類。例如 ActivityManagerService(用於控制Activity、Service、進程等) 這個服務作爲Server端，間接繼承Binder類，而相應的ActivityManager作爲Client端，間接繼承於BinderProxy類。 當然還有PackageManagerService、WindowManagerService等等很多系統服務都是採用C/S架構；
* Native Framework層：這是C++層，作爲Server端繼承(或間接繼承)於BBinder類，Client端繼承(或間接繼承)於BpBinder。例如MediaPlayService(用於多媒體相關)作爲Server端，繼承於BBinder類，而相應的MediaPlay作爲Client端，間接繼承於BpBinder類。