android Binder設計與實現一

摘要

Binder是Android系統進程間通信(IPC)方式之一。Linux已經擁有管道,system V IPC,socket等IPC手段,卻還要倚賴Binder來實現進程間通信,說明Binder具有無可比擬的優勢。深入瞭解Binder並將之與傳統 IPC做對比有助於我們深入領會進程間通信的實現和性能優化。本文將對Binder的設計細節做一個全面的闡述,首先通過介紹Binder通信模型和 Binder通信協議瞭解Binder的設計需求;然後分別闡述Binder在系統不同部分的表述方式和起的作用;最後還會解釋Binder在數據接收端的設計考慮,包括線程池管理,內存映射和等待隊列管理等。通過本文對Binder的詳細介紹以及與其它IPC通信方式的對比,讀者將對Binder的優勢 和使用Binder作為Android主要IPC方式的原因有深入瞭解。
1 引言

基於Client-Server的通信方式廣泛應用於從互聯網和數據庫訪問到嵌入式手持設備內部通信等各個領域。智能手機平臺特別是Android 系統中,為瞭向應用開發者提供豐富多樣的功能,這種通信方式更是無處不在,諸如媒體播放,視音頻頻捕獲,到各種讓手機更智能的傳感器(加速度,方位,溫度,光亮度等)都由不同的Server負責管理,應用程序隻需做為Client與這些Server建立連接便可以使用這些服務,花很少的時間和精力就能開 發出令人眩目的功能。Client-Server方式的廣泛采用對進程間通信(IPC)機制是一個挑戰。目前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,安全性 高。
2 面向對象的 Binder IPC

Binder使用Client-Server通信方式:一個進程作為Server提供諸如視頻/音頻解碼,視頻捕獲,地址本查詢,網絡連接等服務;多個進程作為Client向Server發起服務請求,獲得所需要的服務。要想實現Client-Server通信據必須實現以下兩點:一是server 必須有確定的訪問接入點或者說地址來接受Client的請求,並且Client可以通過某種途徑獲知Server的地址;二是制定Command- Reply協議來傳輸數據。例如在網絡通信中Server的訪問接入點就是Server主機的IP地址+端口號,傳輸協議為TCP協議。對Binder而 言,Binder可以看成Server提供的實現某個特定服務的訪問接入點, Client通過這個‘地址’向Server發送請求來使用該服務;對Client而言,Binder可以看成是通向Server的管道入口,要想和某個 Server通信首先必須建立這個管道並獲得管道入口。

與其它IPC不同,Binder使用瞭面向對象的思想來描述作為訪問接入點的Binder及其在Client中的入口:Binder是一個實體位於 Server中的對象,該對象提供瞭一套方法用以實現對服務的請求,就象類的成員函數。遍佈於client中的入口可以看成指向這個binder對象的 ‘指針’,一旦獲得瞭這個‘指針’就可以調用該對象的方法訪問server。在Client看來,通過Binder‘指針’調用其提供的方法和通過指針調用其它任何本地對象的方法並無區別,盡管前者的實體位於遠端Server中,而後者實體位於本地內存中。‘指針’是C++的術語,而更通常的說法是引用,即Client通過Binder的引用訪問Server。而軟件領域另一個術語‘句柄’也可以用來表述Binder在Client中的存在方式。從通信的 角度看,Client中的Binder也可以看作是Server Binder的‘代理’,在本地代表遠端Server為Client提供服務。本文中會使用‘引用’或‘句柄’這個兩廣泛使用的術語。

面向對象思想的引入將進程間通信轉化為通過對某個Binder對象的引用調用該對象的方法,而其獨特之處在於Binder對象是一個可以跨進程引用的對象,它的實體位於一個進程中,而它的引用卻遍佈於系統的各個進程之中。最誘人的是,這個引用和java裡引用一樣既可以是強類型,也可以是弱類型,而且可以從一個進程傳給其它進程,讓大傢都能訪問同一Server,就象將一個對象或引用賦值給另一個引用一樣。Binder模糊瞭進程邊界,淡化瞭進程間 通信過程,整個系統仿佛運行於同一個面向對象的程序之中。形形色色的Binder對象以及星羅棋佈的引用仿佛粘接各個應用程序的膠水,這也是Binder 在英文裡的原意。

當然面向對象隻是針對應用程序而言,對於Binder驅動和內核其它模塊一樣使用C語言實現,沒有類和對象的概念。Binder驅動為面向對象的進程間通信提供底層支持。
3 Binder 通信模型

Binder框架定義瞭四個角色:Server,Client,ServiceManager(以後簡稱SMgr)以及驅動。其中 Server,Client,SMgr運行於用戶空間,驅動運行於內核空間。這四個角色的關系和互聯網類似:Server是服務器,Client是客戶終 端,SMgr是域名服務器(DNS),驅動是路由器。
3.1 Binder 驅動

和路由器一樣,Binder驅動雖然默默無聞,卻是通信的核心。盡管名叫‘驅動’,實際上和硬件設備沒有任何關系,隻是實現方式和設備驅動程序是一 樣的:它工作於內核態,提供open(),mmap(),poll(),ioctl()等標準文件操作,以字符驅動設備中的misc設備註冊在設備目錄 /dev下,用戶通過/dev/binder訪問該它。驅動負責進程之間Binder通信的建立,Binder在進程之間的傳遞,Binder引用計數管 理,數據包在進程之間的傳遞和交互等一系列底層支持。驅動和應用程序之間定義瞭一套接口協議,主要功能由ioctl()接口實現,不提供 read(),write()接口,因為ioctl()靈活方便,且能夠一次調用實現先寫後讀以滿足同步交互,而不必分別調用write()和 read()。
3.2 ServiceManager 與實名Binder

和DNS類似,SMgr的作用是將字符形式的Binder名字轉化成Client中對該Binder的引用,使得Client能夠通過Binder 名字獲得對Server中Binder實體的引用。註冊瞭名字的Binder叫實名Binder,就象每個網站除瞭有IP地址外都有自己的網址。 Server創建瞭Binder實體,為其取一個字符形式,可讀易記的名字,將這個Binder連同名字以數據包的形式通過Binder驅動發送給 SMgr,通知SMgr註冊一個名叫張三的Binder,它位於某個Server中。驅動為這個穿過進程邊界的Binder創建位於內核中的實體節點以及 SMgr對實體的引用,將名字及新建的引用傳遞給SMgr。SMgr收數據包後,從中取出名字和引用填入一張查找表中。

細心的讀者可能會發現其中的蹊蹺:SMgr是一個進程,Server是另一個進程,Server向SMgr註冊Binder必然會涉及進程間通信。當前實現的是進程間通信卻又要用到進程間通信,這就好象蛋可以孵出雞前提卻是要找隻雞來孵蛋。Binder的實現比較巧妙:預先創造一隻雞來孵蛋。 SMgr和其它進程同樣采用Binder通信,SMgr是Server端,有自己的Binder實體,其它進程都是Client,需要通過這個 Binder的引用來實現Binder的註冊,查詢和獲取。SMgr提供的Binder比較特殊,它沒有名字也不需要註冊,當一個進程使用 BINDER_SET_CONTEXT_MGR命令將自己註冊成SMgr時Binder驅動會自動為它創建Binder實體(這就是那隻預先造好的雞)。其次這個Binder的引用在所有Client中都固定為0而無須通過其它手段獲得。也就是說,一個Server若要向SMgr註冊自己Binder就必需通過0這個引用和SMgr的Binder通信。類比網絡通信,0號引用就好比域名服務器的地址,你必須手工或動態配置好。要註意這裡說的Client是 相對SMgr而言的,一個應用程序是個提供服務的Server,但對SMgr來說它仍然是個Client。
3.3 Client 獲得實名Binder的引用

Server向SMgr註冊瞭Binder實體及其名字後,Client就可以通過名字獲得該Binder的引用瞭。Client也利用保留的0號 引用向SMgr請求訪問某個Binder:我申請獲得名字叫張三的Binder的引用。SMgr收到這個連接請求,從請求數據包裡獲得Binder的名 字,在查找表裡找到該名字對應的條目,從條目中取出Binder的引用,將該引用作為回復發送給發起請求的Client。從面向對象的角度,這個 Binder對象現在有瞭兩個引用:一個位於SMgr中,一個位於發起請求的Client中。如果接下來有更多的Client請求該Binder,系統中 就會有更多的引用指向該Binder,就象java裡一個對象存在多個引用一樣。而且類似的這些指向Binder的引用是強類型,從而確保隻要有引用 Binder實體就不會被釋放掉。通過以上過程可以看出,SMgr象個火車票代售點,收集瞭所有火車的車票,可以通過它購買到乘坐各趟火車的票,即得到某個Binder的引用。
3.4 匿名 Binder

並不是所有Binder都需要註冊給SMgr廣而告之的。Server端可以通過已經建立的Binder連接將創建的Binder實體傳給 Client,當然這條已經建立的Binder連接必須是通過實名Binder實現。由於這個Binder沒有向SMgr註冊名字,所以是個匿名 Binder。Client將會收到這個匿名Binder的引用,通過這個引用向位於Server中的實體發送請求。匿名Binder為通信雙方建立一條 私密通道,隻要Server沒有把匿名Binder發給別的進程,別的進程就無法通過窮舉或猜測等任何方式獲得該Binder的引用,向該Binder發 送請求。

下圖展示瞭參與Binder通信的所有角色,將在以後章節中一一提到。

 

圖1 Binder通信示例

 

摘自 LuoXianXiong,您的夥伴

發佈留言