Android Binder總結

woff · 發表於 2014-12-9 23:25:27

本文原創作者: Cloud Chou.歡迎轉載，請註明出處和本文鏈接

從前面的博客中我們已經學習到如何使用binder，也學習到binder的框架及原理。今天就聊聊我對android為什麼使用binder作為最重要的IPC機制這個問題的想法，並總結一下先前的android binder相關博客。

binder其實不是android首先提出來的IPC機制，它是基於OpenBinder來實現的。OpenBinder有許可問題，andriod不能直接使用，故此重新開發了自己的一套binder實現，基於寬鬆的Apache協議發布，架構與OpenBinder類似，相關信息可以參考: http://www.open-binder.org。

Android為什麼選用Binder作為最重要的IPC機制

我們知道在Linux系統中，進程間的通信方式有socket，named pipe，message queue，signal，sharememory等。這幾種通信方式的優缺點如下：

1) named pipe: 任何進程都能通訊，但速度慢
2) message queue: 容量受到系統限制，且要注意第一次讀的時候，要考慮上一次沒有讀完數據的問題
3) signal: 不能傳遞複雜消息，只能用來同步
4) shared memory: 能夠很容易控制容量，速度快，但要保持同步，比如一個進程在寫的時候，另一個進程要注意讀寫的問題，相當於線程中的線程安全，當然，共享內存同樣可以作為線程通訊，不過沒這個必要，線程間本來就已經共享了同一進程內的一塊內存。
5) socket：本機進程之間可以利用socket通信，跨主機之間也可利用socket通信，通常rpc的實現最底層都是通過socket通信。socket通信是一種比較複雜的通信方式，通常客戶端需要開啟單獨的監聽線程來接收從服務端發送過來的數據，客戶端線程發送數據給服務端后，如果需要等待服務端的響應，並通過監聽線程接收數據，需要進行同步，是一件很麻煩的事情。通過socket通信速度也不快。Android中屬性服務的實現和vold服務的實現採用了socket，getprop和setprop等命令都是通過socket和init進程通信來獲得屬性或者設置屬性，vdc命令或者mount service也是通過socket和vold服務通信來操作外接設備，比如sd卡。

message queue允許任意進程通過共享消息隊列來實現進程間通信，並由系統調用函數來實現消息發送和接收之間的同步，從而使得用戶在使用消息緩衝進行通信時不再需要考慮同步問題。使用方便，但是信息的複制需要額外消耗CPU的時間，不適宜於信息量大或者操作頻繁的場合。共享內存針對消息緩衝的缺點改而利用內存緩衝區直接交換信息，無須複製，快速，信息量大是其優點。但是共享內存的通信方式是通過將共享的緩衝區直接加到進程的虛擬地址空間中來實現的。因此這些進程之間的讀寫操作的同步問題操作系統無法實現。必須由進程利用其它同步工具解決。另外由於內存實體存在於計算機系統中，所以只能由處於同一個計算機系統的進程共享。不方便網絡通信。

共享內存塊提供了在任意數量的進程之間進行高效雙向通信的機制，每個使用者都可以讀取寫入數據，但是所有程序之間必須達成並遵守一定的協議，以防止諸如在讀取信息之前覆蓋內存空間等競爭狀態的實現。不幸的是，Linux無法嚴格保證對內存塊的獨占訪問，甚至是您通過使用IPC_PRIVATE創建新的共享內存塊的時候，也不能保證訪問的獨占性。同時，多個使用共享內存塊的進程之間必須協調使用同一個鍵值。

Android應用程序開發者開發應用程序時，對系統框架的進程和線程運作機制不必了解，只需要利用四大組件開發，Android應用開發時可以輕易調用別的軟件提供的功能，甚至可以調用系統App，在Android的世界裡，所有應用生而平等，但實質上應用進程被隔離在不同的沙盒裡。

Android平台的進程之間需要頻繁的通信，比如打開一個應用便需要Home應用程序進程和運行在system_server進程裡的AcitivityManagerService通信才能打開。正是由於Android平台的進程需要非常頻繁的通信，故此對進程間通信機制要求比較高，速度要快，還要能進行複雜數據的交換，應用開發時應盡可能簡單，並能提供同步調用。雖然共享內存的效率高，但是它需要復雜的同步機制，使用時很麻煩，故此不能採用。binder能滿足這些要求，所以Android選擇了binder作為最核心的進程間通信方式。binder主要提供以下一些功能：