⑴ Android為什麼選擇binder
Binder主要能提供以下一些功能：
用驅動程序來推進進程間的通信。
通過共享內存來提高性能。
為進程請求分配每個進程的線程池。
針對系統中的對象引入了引用計數和跨進程的對象引用映射。
進程間同步調用。
Android Binder設計與實現 – 設計篇：
目前linux支持的IPC包括傳統的管道、System V IPC、即消息隊列/共享內存/信號量，以及socket中只有socket支持Client-Server的通信方式。
當然也可以在這些底層機制上架設一套協議來實現Client-Server通信，但這樣增加了系統的復雜性，在手機這種條件復雜，資源稀缺的環境下可靠性也難以保證。
另一方面是傳輸性能:
socket作為一款通用介面，其傳輸效率低，開銷大，主要用在跨網路的進程間通信和本機上進程間的低速通信。
消息隊列和管道採用存儲-轉發方式，即數據先從發送方緩存區拷貝到內核開辟的緩存區中，然後再從內核緩存區拷貝到接收方緩存區，
至少有兩次拷貝過程。共享內存雖然無需拷貝，但控制復雜，難以使用。
還有一點是出於安全性考慮:
Android作為一個開放式，擁有眾多開發者的平台，應用程序的來源廣泛，確保智能終端的安全是非常重要的。
終端用戶不希望從網上下載的程序在不知情的情況下偷窺隱私數據，連接無線網路，長期操作底層設備導致電池很快耗盡等等。傳統IPC沒有任何
安全措施，完全依賴上層協議來確保。首先傳統IPC的接收方無法獲得對方進程可靠的UID/PID（用戶ID/進程ID），從而無法鑒別對方身份。
Android為每個安裝好的應用程序分配了自己的UID，故進程的UID是鑒別進程身份的重要標志。使用傳統IPC只能由用戶在數據包里填入UID/PID，
但這樣不可靠，容易被惡意程序利用。可靠的身份標記只有由IPC機制本身在內核中添加。其次傳統IPC訪問接入點是開放的，無法建立私有通道。
比如命名管道的名稱、system V的鍵值、socket的ip地址或文件名都是開放的，只要知道這些接入點的程序都可以和對端建立連接，不管怎樣都無法
阻止惡意程序通過猜測接收方地址獲得連接。
基於以上原因，Android需要建立一套新的IPC機制來滿足系統對通信方式，傳輸性能和安全性的要求，這就是Binder。
Binder基於 Client-Server通信模式，傳輸過程只需一次拷貝，為發送發添加UID/PID身份，既支持實名Binder也支持匿名Binder，安全性高。
面向對象的 Binder IPC：
面向對象思想的引入將進程間通信轉化為通過對某個Binder對象的引用調用該對象的方法，而其獨特之處在於Binder對象是一個
可以跨進程引用的對象，它的實體位於一個進程中，而它的引用卻遍布於系統的各個進程之中。最誘人的是，這個引用和java里引用
一樣既可以是強類型，也可以是弱類型，而且可以從一個進程傳給其它進程，讓大家都能訪問同一Server，就像將一個對象或引用賦
值給另一個引用一樣。Binder模糊了進程邊界，淡化了進程間通信過程，整個系統彷彿運行於同一個面向對象的程序之中。
面向對象只是針對應用程序而言，對於Binder驅動和內核其它模塊一樣使用C語言實現，沒有類和對象的概念。
Binder驅動為面向對象的進程間通信提供底層支持。