Binder機制1---Binder原理介紹

來源 http://blog.csdn.net/bathinbreeze/article/details/8989105

1.Binder通信機制介紹

這篇文章會先對比Binder機制與Linux的通信機制的差別,瞭解爲什麼Android會另起爐竈,採用Binder。接着,會根據 Binder的機制,去理解什麼是Service  Manager,在C/S模型中扮演什麼角色。最後,會從一次完整的通信活動中,去理解Binder通信的過程。

1.1 Android與Linux通信機制的比較

雖然Android繼承使用Linux的內核,但Linux與Android的通信機制不同。

在Linux中使用的IPC通信機制如下:

  1. 傳統IPC:無名pipe, signal, trace, 有名管道

  2. AT&T Unix 系統V:共享內存,信號燈,消息隊列

  3. BSD Unix:Socket

而在Android中,並沒有使用這些,取而代之的是Binder機制。Binder機制是採用OpenBinder演化而來,在Android中使用它的原因如下:

  1. 採用C/S的通信模式。而在linux通信機制中,目前只有socket支持C/S的通信模式,但socket有其劣勢,具體參看第二條。

  2. 有更好的傳輸性能。對比於Linux的通信機制,

    • socket:是一個通用接口,導致其傳輸效率低,開銷大;

    • 管道和消息隊列:因爲採用存儲轉發方式,所以至少需要拷貝2次數據,效率低;

    • 共享內存:雖然在傳輸時沒有拷貝數據,但其控制機制複雜(比如跨進程通信時,需獲取對方進程的pid,得多種機制協同操作)。

  3. 安全性更高。Linux的IPC機制在本身的實現中,並沒有安全措施,得依賴上層協議來進行安全控制。而Binder機制的 UID/PID是由Binder機制本身在內核空間添加身份標識,安全性高;並且Binder可以建立私有通道,這是linux的通信機制所無法實現的 (Linux訪問的接入點是開放的)。

綜上所述,Android採用Binder機制是有道理的。既然Binder機制這麼多優點,那麼我們接下來看看它是怎樣通過C/S模型來實現的。

1.2 Binder在Service服務中的作用

在android中,有很多Service都是通過binder來通信的,比如MediaServer旗下包含了衆多service:

  •     AudioFlinger 音頻核心服務

  •     AudioPolicyService:音頻策略相關的重要服務

  •     MediaPlayerService:多媒體系統中的重要服務

  •     CameraService:有關攝像/照相的重要服務

Binder在C/S中的流程如下:


  1. Server註冊服務。Server作爲衆多Service的擁有者,當它想向Client提供服務時,得先去Service Manager(以後縮寫成SM)那兒註冊自己的服務。Server可以向SM註冊一個或多個服務。

  2. Client申請服務。Client作爲Service的使用者,當它想使用服務時,得向SM申請自己所需要的服務。Client可以申請一個或多個服務。

  3. 當Client申請服務成功後,Client就可以使用服務了。

SM一方面管理Server所提供的服務,同時又響應Client的請求併爲之分配相應的服務。扮演的角色相當於月老,兩邊牽線。這種通信方式的好處是: 一方面,service和Client請求便於管理,另一方面在應用程序開發時,只需爲Client建立到Server的連接,就可花很少時間和精力去實 現Server相應功能。那麼,Binder與這個通信模式有什麼關係呢?!其實,3者的通信方式就是Binder機制(例如:Server向SM註冊服 務,使用Binder通信;Client申請請求,用的是Binder通訊)

1.3 Binder通信機制流程(整體框架)


上圖即是Binder的通信模型。我們可以發現:

  1. Client和Server是存在於用戶空間

  2. Client與Server通信的實現,是由Binder驅動在內核空間實現

  3. SM作爲守護進程,處理客戶端請求,管理所有服務項。

爲了方便理解,我們可以把SM理解成DNS服務器; 那麼Binder Driver 就相當於路由的功能。這裏就涉及到Client和Server是如何通信的問題。下面對1.2中提到的3個流程進行說明。

1.3.1 Server向SM註冊服務


  1. 首先,XXXServer(XXX代表某個)在自己的進程中向Binder驅動申請創建一個XXXService的Binder的實體,

  2. Binder驅動爲這個XXXService創建位於內核中的Binder實體節點以及Binder的引用,注意,是將名字和新建的引用打包傳遞給SM(實體沒有傳給SM),通知SM註冊一個名叫XXX的Service。

  3. SM收到數據包後,從中取出XXXService名字和引用,填入一張查找表中。

  4. 此時,如果有Client向SM發送申請服務XXXService的請求,那麼SM就可以在查找表中找到該Service的Binder引用,並把Binder引用(XXXBpBinder)返回給Client。

在進一步瞭解Binder通信機制之前,我們先弄清幾個概念。

  1. 引用和實體。這裏,對於一個用於通信的實體(可以理解成具有真實空間的Object),可以有多個該實體的引用(沒有真實空間,可以理解成實體的 一個鏈接,操作引用就會操作對應鏈接上的實體)。如果一個進程持有某個實體,其他進程也想操作該實體,最高效的做法是去獲得該實體的引用,再去操作這個引 用。

  2. 有些資料把實體稱爲本地對象,引用成爲遠程對象。可以這麼理解:引用是從本地進程發送給其他進程來操作實體之用,所以有本地和遠程對象之名。

1.3.2 一個問題-如何獲得SM的遠程接口

如果你足夠細心,會發現這裏有一個問題:

Sm和Server都是進程,Server向SM註冊Binder需要進程間通信,當前實現的是進程間通信卻又用到進程間通信。這就好比雞生蛋、蛋生雞,但至少得先有其中之一。

巧妙的Binder解決思路:

針對Binder的通信機制,Server端擁有的是Binder的實體;Client端擁有的是Binder的引用。
如果把SM看作Server端,讓它在Binder驅動一運行起來時就有自己的Binder實體(代碼中設置ServiceManager的Binder 其handle值恆爲0)。這個Binder實體沒有名字也不需要註冊,所有的client都認爲handle值爲0的binder引用是用來與SM通信 的(代碼中是這麼實現的),那麼這個問題就解決了。那麼,Client和Server中這麼達成協議了(handle值爲0的引用是專門與SM通信之用 的),還不行,還需要讓SM有handle值爲0的實體纔算大功告成。怎麼實現的呢?!當一個進程調用Binder驅動時,使用 BINDER_SET_CONTEXT_MGR命令(在驅動的binder_ioctl中)將自己註冊成SM時,Binder驅動會自動爲它創建 Binder實體。這個Binder的引用對所有的Client都爲0。


1.3.3 Client從SM獲得Service的遠程接口


Server向SM註冊了Binder實體及其名字後,Client就可以通過Service的名字在SM的查找表中獲得該Binder的引用了 (BpBinder)。Client也利用保留的handle值爲0的引用向SM請求訪問某個Service:我申請訪問XXXService的引用。 SM就會從請求數據包中獲得XXXService的名字,在查找表中找到該名字對應的條目,取出Binder的引用打包回覆給client。之 後,Client就可以利用XXXService的引用使用XXXService的服務了。
如果有更多的Client請求該Service,系統中就會有更多的Client獲得這個引用。

1.3.4 建立C/S通路後

首先要理清一個概念:client擁有自己Binder的實體,以及Server的Binder的引用;Server擁有自己Binder的實體,以及Client的Binder的引用。我們也可以從接收方和發送方的方式來理解:

  • 從client向Server發數據:Client爲發送方,擁有Binder的實體;Server爲接收方,擁有Binder的引用

  • 從server向client發數據:Server爲發送方,擁有Binder的實體;client爲接收方,擁有Binder的引用。

也就是說,我們在建立了C/S通路後,無需考慮誰是Client誰是Server,只要理清誰是發送方誰是接收方,就能知道Binder的實體和引用在哪邊。


建立CS通路後的流程:(當接收方獲得Binder的實體,發送方獲得Binder的引用後)

  1. 發送方會通過Binder實體請求發送操作。

  2. Binder驅動會處理這個操作請求,把發送方的數據放入寫緩存(binder_write_read.write_buffer) (對於接收方爲讀緩衝區),並把read_size(接收方讀數據)置爲數據大小(對於具體的實現後面會介紹);

  3. 接收方之前一直在阻塞狀態中,當寫緩存中有數據,則會讀取數據,執行命令操作

  4. 接收方執行完後,會把返回結果同樣用binder_transaction_data結構體封裝,寫入寫緩衝區(對於發送方,爲讀緩衝區)

1.3.5 匿名Binder

之前在介紹Android使用Binder機制的優點中,提到Binder可以建立點對點的私有通道,匿名Binder就是這種方式。在 Binder通信中,並不是所有用來通信的Binder實體都需要註冊給SM廣而告之的,Server可以通過已建立的實體Binder連接將創建的 Binder實體傳給Client。而這個Binder沒有向SM註冊名字。這樣Server與Client的通信就有很高的隱私性和安全性。

這樣,整個Binder的通信流程就介紹完畢了,但是對於具體的代碼實現(比如binder_transaction_data是什 麼?binder_write_read.write_buffer又是什麼?具體的驅動和邏輯實現又是怎麼樣?),在後面章節中會一一介紹。

幾點疑問:
1. 是誰,怎麼樣成爲SM守護進程,handle爲0的binder實體什麼時候創建?
2.  binder引用和實體是如何創建的?在驅動中如何實現的通信?
3. 在SM中,binder實體是怎樣轉換成爲引用的?
4. Server是如何註冊服務,Client是如何獲取服務的?

讀完後續文章就會知道答案了!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章