Android為什麼選擇binder

　　Android為什麼選擇binder

Binder (Android技術內幕)：

　　在上面這些可供選擇的方式中，Android使用得最多也最被認可的還是Binder機制。

為什麼會選擇Binder來作為進程之間的通訊機制呢？因為Binder更加簡潔和快速，消耗的記憶體資源更小嗎？

不錯，這些也正是Binder的優點。

　　當然，也還有很多其他原因，比如傳統的處理序間通訊可能會增加進程的開銷，而且有進程過載和安全性漏洞等方面的風險，Binder正好能解決和避免這些問題。

Binder主要能提供以下一些功能：

　　用驅動程式來推進進程間的通訊。

　　通過共用記憶體來提高效能。

　　為進程請求分配每個進程的線程池。

　　針對系統中的對象引入了引用計數和跨進程的對象引用映射。

　　進程間同步調用。

 

Android Binder設計與實現 – 設計篇：

　　目前linux支援的IPC包括傳統的管道、System V IPC、即訊息佇列/共用記憶體/訊號量，以及socket中只有socket支援Client-Server的通訊方式。

當然也可以在這些底層機制上架設一套協議來實現Client-Server通訊，但這樣增加了系統的複雜性，在手機這種條件複雜，資源稀缺的環境下可靠性也難以保證。

另一方面是傳輸效能:

　　socket作為一款通用介面，其傳輸效率低，開銷大，主要用在跨網路的處理序間通訊和本機上進程間的低速通訊。

訊息佇列和管道採用儲存-轉寄方式，即資料先從發送方緩衝區拷貝到核心開闢的緩衝區中，然後再從核心緩衝區拷貝到接收方緩衝區，

至少有兩次拷貝過程。共用記憶體雖然無需拷貝，但控制複雜，難以使用。

表 1 各種IPC方式資料拷貝次數

IPC	資料拷貝次數
共用記憶體	0
Binder	1
Socket/管道/訊息佇列	2

 

還有一點是出於安全性考慮:

　　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驅動為物件導向的處理序間通訊提供底層支援。

來自：http://wenku.baidu.com/view/4186490690c69ec3d5bb753a.html