android binder機制詳解

binder是android中一個很重要且很複雜的概念，它在系統的整體運作中發揮着極其重要的作用，不過本文并不打算從深層次分析binder機制，有兩點原因：1是目前網上已經有2篇很好的文章了，2是對binder機制進行深入底層乃至驅動的分析這一過程相當困難且相當耗時，是以并不适合重複造輪子。本文的角度是對android的binder機制從整體和概念上進行分析，能夠讓大家很快明白到底什麼是binder，binder是幹什麼的，binder和應用開發的關系是什麼，總之，這篇文章還是很值得去看一看的。

1. 直覺來說，binder是android中的一個類，它繼承了ibinder接口

2. 從ipc角度來說，binder是android中的一種跨程序通信方式，binder還可以了解為一種虛拟的實體裝置，它的裝置驅動是/dev/binder，該通信方式在linux中沒有

3. 從android framework角度來說，binder是servicemanager連接配接各種manager（activitymanager、windowmanager，etc）和相應managerservice的橋梁

4. 從android應用層來說，binder是用戶端和服務端進行通信的媒介，當你bindservice的時候，服務端會傳回一個包含了服務端業務調用的binder對象，通過這個binder對象，用戶端就可以擷取服務端提供的服務或者資料，這裡的服務包括普通服務和基于aidl的服務

android中有大量的cs（client-server）應用方式，這就要求android内部提供ipc方法，而linux所支援的程序通信方式有兩個問題：性能和安全性。

目前linux支援的ipc包括傳統的管道，system v ipc(消息隊列/共享記憶體/信号量)，以及socket，但隻有socket支援client-server的通信方式，由于socket是一套通用的網絡通信方式，其傳輸效率低下切有很大的開銷，比如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通信過程示例：

參考：