這篇文章會先對比Binder機制與Linux的通信機制的差別,，了解為什么Android會另起爐灶,，采用Binder。接著,，會根據(jù)Binder的機制,，去理解什么是Service Manager，在C/S模型中扮演什么角色,。最后,，會從一次完整的通信活動中，去理解Binder通信的過程,。

1.1 Android與Linux通信機制的比較

雖然Android繼承使用Linux的內(nèi)核,，但Linux與Android的通信機制不同,。

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

1. 傳統(tǒng)IPC：無名pipe, signal, trace, 有名管道
2. AT&T Unix 系統(tǒng)V：共享內(nèi)存,，信號燈，消息隊列
3. BSD Unix：Socket
   

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

1. 采用C/S的通信模式,。而在linux通信機制中，目前只有socket支持C/S的通信模式,，但socket有其劣勢,，具體參看第二條。
2. 有更好的傳輸性能,。對比于Linux的通信機制,，
   • socket：是一個通用接口，導(dǎo)致其傳輸效率低,，開銷大,；
   • 管道和消息隊列：因為采用存儲轉(zhuǎn)發(fā)方式，所以至少需要拷貝2次數(shù)據(jù),，效率低,；
   • 共享內(nèi)存：雖然在傳輸時沒有拷貝數(shù)據(jù)，但其控制機制復(fù)雜（比如跨進(jìn)程通信時,，需獲取對方進(jìn)程的pid,，得多種機制協(xié)同操作）。
3. 安全性更高,。Linux的IPC機制在本身的實現(xiàn)中,，并沒有安全措施，得依賴上層協(xié)議來進(jìn)行安全控制。而Binder機制的UID/PID是由Binder機制本身在內(nèi)核空間添加身份標(biāo)識,，安全性高,；并且Binder可以建立私有通道，這是linux的通信機制所無法實現(xiàn)的（Linux訪問的接入點是開放的）,。
   

綜上所述,，Android采用Binder機制是有道理的。既然Binder機制這么多優(yōu)點,，那么我們接下來看看它是怎樣通過C/S模型來實現(xiàn)的,。

1.2 Binder在Service服務(wù)中的作用

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

•     AudioFlinger 音頻核心服務(wù)
•     AudioPolicyService：音頻策略相關(guān)的重要服務(wù)
•     MediaPlayerService：多媒體系統(tǒng)中的重要服務(wù)
•     CameraService：有關(guān)攝像/照相的重要服務(wù)

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

1. Server注冊服務(wù),。Server作為眾多Service的擁有者,，當(dāng)它想向Client提供服務(wù)時，得先去Service Manager（以后縮寫成SM）那兒注冊自己的服務(wù),。Server可以向SM注冊一個或多個服務(wù),。
2. Client申請服務(wù)。Client作為Service的使用者,，當(dāng)它想使用服務(wù)時,，得向SM申請自己所需要的服務(wù)。Client可以申請一個或多個服務(wù),。
3. 當(dāng)Client申請服務(wù)成功后,，Client就可以使用服務(wù)了。
   

SM一方面管理Server所提供的服務(wù),，同時又響應(yīng)Client的請求并為之分配相應(yīng)的服務(wù),。扮演的角色相當(dāng)于月老，兩邊牽線,。這種通信方式的好處是：一方面,，service和Client請求便于管理，另一方面在應(yīng)用程序開發(fā)時,，只需為Client建立到Server的連接,，就可花很少時間和精力去實現(xiàn)Server相應(yīng)功能。那么,，Binder與這個通信模式有什么關(guān)系呢,？！其實,，3者的通信方式就是Binder機制（例如：Server向SM注冊服務(wù),，使用Binder通信；Client申請請求,，用的是Binder通訊）

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

上圖即是Binder的通信模型,。我們可以發(fā)現(xiàn)：

1. Client和Server是存在于用戶空間
2. Client與Server通信的實現(xiàn),，是由Binder驅(qū)動在內(nèi)核空間實現(xiàn)
3. SM作為守護進(jìn)程，處理客戶端請求,，管理所有服務(wù)項,。
   

為了方便理解，我們可以把SM理解成DNS服務(wù)器; 那么Binder Driver 就相當(dāng)于路由的功能,。這里就涉及到Client和Server是如何通信的問題,。下面對1.2中提到的3個流程進(jìn)行說明。

1.3.1 Server向SM注冊服務(wù)

1. 首先,，XXXServer(XXX代表某個)在自己的進(jìn)程中向Binder驅(qū)動申請創(chuàng)建一個XXXService的Binder的實體,，
2. Binder驅(qū)動為這個XXXService創(chuàng)建位于內(nèi)核中的Binder實體節(jié)點以及Binder的引用，注意,，是將名字和新建的引用打包傳遞給SM（實體沒有傳給SM）,，通知SM注冊一個名叫XXX的Service。
3. SM收到數(shù)據(jù)包后,，從中取出XXXService名字和引用,，填入一張查找表中。
4. 此時,，如果有Client向SM發(fā)送申請服務(wù)XXXService的請求,，那么SM就可以在查找表中找到該Service的Binder引用,，并把Binder引用(XXXBpBinder)返回給Client,。

在進(jìn)一步了解Binder通信機制之前，我們先弄清幾個概念,。

1. 引用和實體,。這里，對于一個用于通信的實體（可以理解成具有真實空間的Object）,，可以有多個該實體的引用（沒有真實空間,，可以理解成實體的一個鏈接，操作引用就會操作對應(yīng)鏈接上的實體）,。如果一個進(jìn)程持有某個實體,，其他進(jìn)程也想操作該實體，最高效的做法是去獲得該實體的引用,，再去操作這個引用,。
2. 有些資料把實體稱為本地對象，引用成為遠(yuǎn)程對象,?？梢赃@么理解：引用是從本地進(jìn)程發(fā)送給其他進(jìn)程來操作實體之用，所以有本地和遠(yuǎn)程對象之名,。

1.3.2 一個問題-如何獲得SM的遠(yuǎn)程接口

如果你足夠細(xì)心,，會發(fā)現(xiàn)這里有一個問題：

Sm和Server都是進(jìn)程,，Server向SM注冊Binder需要進(jìn)程間通信，當(dāng)前實現(xiàn)的是進(jìn)程間通信卻又用到進(jìn)程間通信,。這就好比雞生蛋,、蛋生雞，但至少得先有其中之一,。

巧妙的Binder解決思路：

針對Binder的通信機制,，Server端擁有的是Binder的實體；Client端擁有的是Binder的引用,。
如果把SM看作Server端,，讓它在Binder驅(qū)動一運行起來時就有自己的Binder實體（代碼中設(shè)置ServiceManager的Binder其handle值恒為0）。這個Binder實體沒有名字也不需要注冊,，所有的client都認(rèn)為handle值為0的binder引用是用來與SM通信的（代碼中是這么實現(xiàn)的）,，那么這個問題就解決了。那么,，Client和Server中這么達(dá)成協(xié)議了（handle值為0的引用是專門與SM通信之用的）,，還不行，還需要讓SM有handle值為0的實體才算大功告成,。怎么實現(xiàn)的呢,？！當(dāng)一個進(jìn)程調(diào)用Binder驅(qū)動時,，使用BINDER_SET_CONTEXT_MGR命令（在驅(qū)動的binder_ioctl中）將自己注冊成SM時,，Binder驅(qū)動會自動為它創(chuàng)建Binder實體。這個Binder的引用對所有的Client都為0,。

1.3.3 Client從SM獲得Service的遠(yuǎn)程接口

Server向SM注冊了Binder實體及其名字后,，Client就可以通過Service的名字在SM的查找表中獲得該Binder的引用了（BpBinder）。Client也利用保留的handle值為0的引用向SM請求訪問某個Service：我申請訪問XXXService的引用,。SM就會從請求數(shù)據(jù)包中獲得XXXService的名字,，在查找表中找到該名字對應(yīng)的條目，取出Binder的引用打包回復(fù)給client,。之后,，Client就可以利用XXXService的引用使用XXXService的服務(wù)了。
如果有更多的Client請求該Service,，系統(tǒng)中就會有更多的Client獲得這個引用,。

1.3.4 建立C/S通路后

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

• 從client向Server發(fā)數(shù)據(jù)：Client為發(fā)送方,，擁有Binder的實體,；Server為接收方,，擁有Binder的引用
• 從server向client發(fā)數(shù)據(jù)：Server為發(fā)送方，擁有Binder的實體,；client為接收方,，擁有Binder的引用。

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

建立CS通路后的流程：（當(dāng)接收方獲得Binder的實體，發(fā)送方獲得Binder的引用后）

1. 發(fā)送方會通過Binder實體請求發(fā)送操作,。
2. Binder驅(qū)動會處理這個操作請求,把發(fā)送方的數(shù)據(jù)放入寫緩存(binder_write_read.write_buffer) (對于接收方為讀緩沖區(qū)),，并把read_size(接收方讀數(shù)據(jù))置為數(shù)據(jù)大小（對于具體的實現(xiàn)后面會介紹）,；
3. 接收方之前一直在阻塞狀態(tài)中,，當(dāng)寫緩存中有數(shù)據(jù)，則會讀取數(shù)據(jù),，執(zhí)行命令操作
4. 接收方執(zhí)行完后,，會把返回結(jié)果同樣用binder_transaction_data結(jié)構(gòu)體封裝，寫入寫緩沖區(qū)（對于發(fā)送方,，為讀緩沖區(qū)）

1.3.5 匿名Binder

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

這樣,，整個Binder的通信流程就介紹完畢了，但是對于具體的代碼實現(xiàn)（比如binder_transaction_data是什么,？binder_write_read.write_buffer又是什么,？具體的驅(qū)動和邏輯實現(xiàn)又是怎么樣？）,，在后面章節(jié)中會一一介紹,。

幾點疑問：
1. 是誰，怎么樣成為SM守護進(jìn)程,，handle為0的binder實體什么時候創(chuàng)建,？
2.  binder引用和實體是如何創(chuàng)建的,？在驅(qū)動中如何實現(xiàn)的通信？
3. 在SM中,，binder實體是怎樣轉(zhuǎn)換成為引用的,？
4. Server是如何注冊服務(wù)，Client是如何獲取服務(wù)的,？