??? ??? 已經(jīng)不止一次想要花些時(shí)間把Android的Binder機(jī)制搞搞明白，最近的工作總算比較清閑，所以花了差不多3周時(shí)間，看了一些資料，讀了不少代碼?，F(xiàn)在把這些資料整理下，方便自己以后忘了回來(lái)看看。

Binder機(jī)制的引入原因

??????? Binder機(jī)制是為C/S架構(gòu)設(shè)計(jì)的IPC機(jī)制，基于性能和安全性的考慮，Android系統(tǒng)在傳統(tǒng)IPC機(jī)制之外，又引入了Binder機(jī)制。

性能??? 傳統(tǒng)的Socket/管道/消息隊(duì)列等IPC機(jī)制有一個(gè)共同點(diǎn)，數(shù)據(jù)傳輸過(guò)程中，先從發(fā)送方的緩沖區(qū)copy到內(nèi)核緩沖區(qū)，再?gòu)膬?nèi)核緩沖區(qū)copy到接收方緩沖區(qū)，數(shù)據(jù)至少經(jīng)過(guò)兩次copy。Binder機(jī)制的優(yōu)化設(shè)計(jì)，使其僅需要從發(fā)送方緩沖區(qū)拷貝數(shù)據(jù)到內(nèi)核緩沖區(qū)，接收方即可直接讀取內(nèi)核緩沖區(qū)中的數(shù)據(jù)，數(shù)據(jù)僅需一次copy，提升了數(shù)據(jù)傳輸性能。安全性???? Binder機(jī)制提供通信方的UID和PID，有助于判斷非法訪問(wèn)。并且，Binder機(jī)制支持匿名Binder，可以用于規(guī)避通過(guò)猜測(cè)（i.e. 通過(guò)猜測(cè)端口地址進(jìn)行Socket通信）進(jìn)行通信的風(fēng)險(xiǎn)。Binder機(jī)制的角色

??????? Binder機(jī)制包括四個(gè)角色：Binder driver、Service Manager、Service、Client.

Binder driver

??????? Binder driver工作于內(nèi)核態(tài)（kernel space), 作為linux內(nèi)核的一部分，跟隨linux系統(tǒng)啟動(dòng)。它向linux內(nèi)核注冊(cè)了MISC設(shè)備，就是我們看到的dev/binder設(shè)備文件，當(dāng)Service/Client調(diào)用open/ioctl等系統(tǒng)調(diào)用操作dev/binder文件時(shí)，就會(huì)進(jìn)入到內(nèi)核態(tài)，執(zhí)行Binder driver提供的實(shí)現(xiàn)（binder_open/binder_ioctl)，然后，根據(jù)調(diào)用者請(qǐng)求的操作（數(shù)據(jù)寫(xiě)入/發(fā)送、數(shù)據(jù)讀取/接收），binder 驅(qū)動(dòng)執(zhí)行不同的工作。Binder driver沒(méi)有自己的進(jìn)程，它總是工作在Client、Service、ServiceManager的進(jìn)程中。

??????? 基于其將一塊物理內(nèi)存同時(shí)映射到Binder driver所在的內(nèi)核空間和接收進(jìn)程的用戶空間地址的設(shè)計(jì)，當(dāng)數(shù)據(jù)從數(shù)據(jù)發(fā)送方的發(fā)送緩存中copy到內(nèi)核緩沖區(qū)時(shí)，相當(dāng)于同時(shí)也copy到了接收進(jìn)程的接收緩沖區(qū)內(nèi)，所以，整個(gè)數(shù)據(jù)傳輸過(guò)程中，數(shù)據(jù)僅需要經(jīng)過(guò)1次copy，提升了數(shù)據(jù)傳輸性能。

??????? 此外，Binder driver還提供了調(diào)用者的UID&PID，這些數(shù)據(jù)有助于數(shù)據(jù)接收者判斷數(shù)據(jù)的有效性，回避非法訪問(wèn)，提高系統(tǒng)安全性。

??????? 其他方面來(lái)說(shuō)，Binder driver還負(fù)責(zé)Binder機(jī)制使用者（client、service、service manager）的緩存管理，還提供數(shù)據(jù)接收方線程管理的功能。

Service Manager

??????? Service Manager作為所有實(shí)名Binder的管理者，管理著系統(tǒng)中常用的基本Service（這里的Service與Android四大組建之一的Service是不同的概念），例如MediaPlayerService、CameraService、BlueToothService等。

??????? 首先，所有這些Service啟動(dòng)后，會(huì)把自己注冊(cè)到Service Manager中。然后，Service Manager就把Service的handle添加到內(nèi)部的列表中。最后，Client向Service Manager索取Service的Handle時(shí)，Service Manager就從內(nèi)部的列表中查找對(duì)應(yīng)service的handle，并返回給Client，之后Client就可以根據(jù)Handle向Service申請(qǐng)自己需要的服務(wù)。

??????? 從廣義角度來(lái)說(shuō)，擁有Binder實(shí)體的進(jìn)程即是Service，從這個(gè)角度來(lái)看，ServiceManager本身也是一個(gè)Service，同時(shí)它也是系統(tǒng)內(nèi)第一個(gè)啟動(dòng)的Service。從功能的角度來(lái)說(shuō)，Service Manager相當(dāng)于一個(gè)全局列表，Service把自己添加到列表中，所以Client可以從列表中檢索自己需要的Service。

Service

??????? Service即服務(wù)的提供者，每個(gè)Service都擁有一個(gè)Binder實(shí)體，Service可以根據(jù)需要把自己注冊(cè)到Service Manager(即實(shí)名Binder），也可以不注冊(cè)（即匿名Binder）。匿名Binder必須依賴實(shí)名Binder才能工作（因?yàn)樗仨毻ㄟ^(guò)一個(gè)Binder把自己發(fā)送到Client端，才能開(kāi)始Binder通信）。

Client

??????? Client即服務(wù)的使用者，Client持有一個(gè)Binder引用，而B(niǎo)inder引用則指向特定的Binder實(shí)體。Client通過(guò)這個(gè)Binder引用與Binder實(shí)體（即Service）通信，從而獲取Service的服務(wù)。廣義上來(lái)說(shuō)，持有Binder引用即為Binder機(jī)制的Client，除了ServiceManager這個(gè)特例，ServicerManager持有所有實(shí)名Binder的引用，但是從來(lái)不呼叫這個(gè)Binder的服務(wù)。

Binder的工作方式

??????? Binder對(duì)象在不同的場(chǎng)景中表現(xiàn)為不同的形式：?????

? Client Service 用戶空間 BpBinder （準(zhǔn)確的說(shuō)，應(yīng)該是繼承自BpBinder的對(duì)象） BBinder（準(zhǔn)確來(lái)說(shuō)，應(yīng)該是繼承自BBinder的對(duì)象） 內(nèi)核空間 binder_ref binder_node ??????? 這里的內(nèi)核空間即binder driver。

???????? 模糊的講，BpBinder和Binder_ref都是Binder引用，而B(niǎo)Binder和Binder_node都是binder實(shí)體。

BBinder是服務(wù)提供者，它實(shí)現(xiàn)了具體的業(yè)務(wù)邏輯。Binder_node則是Binder driver為BBinder在內(nèi)核空間創(chuàng)建的對(duì)象，BBinder總是和binder_node一一對(duì)應(yīng)，binder_node的ptr成員指針指向BBinder。一個(gè)進(jìn)程可以有多個(gè)binder_node,binder_node的ptr成員是“ID”，進(jìn)程內(nèi)唯一。Binder_ref則是Binder driver為Client在內(nèi)核空間創(chuàng)建的對(duì)象，binder_ref的node成員指向binder_node，所以一個(gè)bind_ref總是關(guān)聯(lián)到一個(gè)Binder_node，但是一個(gè)binder_node可以被多個(gè)binder_ref關(guān)聯(lián)。一個(gè)進(jìn)程可以有多個(gè)binder_ref，進(jìn)程內(nèi)binder_ref的desc成員是"ID",進(jìn)程內(nèi)唯一。BpBinder是BBinder的代理，它實(shí)現(xiàn)與BBinder相同的接口，但是不提供具體的服務(wù)。BpBinder的handle成員總是和進(jìn)程內(nèi)的某個(gè)binder_ref的desc成員相同，這樣BpBinder才能關(guān)聯(lián)到一個(gè)binder_ref，否則BpBinder無(wú)法工作。

?????? 從上面的圖中，我們可以看到client通過(guò)BpBinder-》binder_ref-》binder_node-》BBinder最終關(guān)聯(lián)到一個(gè)Service，所以，Client可以通過(guò)BpBinder向Service發(fā)起請(qǐng)求。而Service無(wú)法主動(dòng)聯(lián)系Client，因?yàn)橥瑫r(shí)可以有多個(gè)Client關(guān)聯(lián)到Service。

?????? 整個(gè)Binder機(jī)制的工作過(guò)程是這樣的（暫不討論匿名Binder）：

Linux系統(tǒng)啟動(dòng)，Binder driver開(kāi)始工作，注冊(cè)設(shè)備文件/dev/binderAndroid系統(tǒng)啟動(dòng)，ServiceManager開(kāi)始工作，向Binder driver注冊(cè)ContextManager，這個(gè)過(guò)程中，Binder driver中創(chuàng)建了第一個(gè)binder_node(注意：ServiceManager在內(nèi)核空間有binder_node,但是在用戶空間沒(méi)有對(duì)應(yīng)的BBinder）。Service進(jìn)程啟動(dòng)，在用戶空間創(chuàng)建了BBinder，并向ServiceManager注冊(cè)服務(wù)，注冊(cè)的過(guò)程中，Binder driver為Service在內(nèi)核空間創(chuàng)建了binder_node
Client啟動(dòng)，向ServiceManager請(qǐng)求指定Serivce的Handle,這個(gè)過(guò)程中，Binder driver為Client在內(nèi)核空間創(chuàng)建了handle對(duì)應(yīng)的binder_ref
Client根據(jù)ServiceManager提供的handle,向Service請(qǐng)求服務(wù)。

?????? 而上面第5步中，一個(gè)“完整”的Binder通信過(guò)程（Client發(fā)起請(qǐng)求》》Service讀取請(qǐng)求》》Service處理請(qǐng)求》》Service回復(fù)處理結(jié)果》》Client端讀取結(jié)果），大致流程如下：

Client進(jìn)程在用戶態(tài)調(diào)用BpBinder的接口BpBinder調(diào)用ioctl向dev/binder文件寫(xiě)入數(shù)據(jù)，數(shù)據(jù)中包含自己的handle進(jìn)程進(jìn)入到核心態(tài)，執(zhí)行binder driver的代碼，先查找handle關(guān)聯(lián)的binder_ref進(jìn)一步根據(jù)binder_ref關(guān)聯(lián)的binder_node,確定目標(biāo)Service進(jìn)程即(binder_proc)把數(shù)據(jù)保存到目標(biāo)進(jìn)程（或目標(biāo)線程）的todo隊(duì)列，這時(shí)的數(shù)據(jù)中添加了當(dāng)前線程（binder_thread)信息，并喚醒ServiceClient開(kāi)始等待回復(fù)Service進(jìn)程內(nèi)的binder driver被喚醒，緩存client發(fā)送過(guò)來(lái)的數(shù)據(jù)Service進(jìn)程返回用戶態(tài)，調(diào)用BBinder到接口，開(kāi)始處理請(qǐng)求請(qǐng)求處理結(jié)束，調(diào)用ioctl，回復(fù)Client的請(qǐng)求進(jìn)程進(jìn)入核心態(tài)，通過(guò)步驟7緩存的數(shù)據(jù)，確定請(qǐng)求發(fā)起線程（步驟五中，數(shù)據(jù)內(nèi)添加了請(qǐng)求發(fā)起線程的信息）把回復(fù)數(shù)據(jù)保存到client進(jìn)程請(qǐng)求線程的todo隊(duì)列中，并喚醒Client進(jìn)程中的請(qǐng)求線程
Service進(jìn)程繼續(xù)等待請(qǐng)求Client進(jìn)程內(nèi)的請(qǐng)求線程被喚醒，返回用戶態(tài)返回到用戶態(tài)，client進(jìn)程處理回復(fù)數(shù)據(jù)

????? （這個(gè)時(shí)序圖中，BBinder和Service被畫(huà)在一起，因?yàn)锳ndroid中很多Service的直接繼承自BBinder，所以Service和BBinder可以是一體的）

個(gè)人對(duì)于Binder機(jī)制的理解

??????? 作為一個(gè)為C/S架構(gòu)設(shè)計(jì)的IPC機(jī)制，Binder機(jī)制對(duì)于C/S架構(gòu)有相當(dāng)良好的支持：

Service可以同時(shí)為多個(gè)Client提供服務(wù)。Client可以同時(shí)呼叫多個(gè)Service的服務(wù)。Service和Client的角色并不互斥，同一個(gè)進(jìn)程可以同時(shí)身兼兩個(gè)角色（i.e. MediaPlayerService 在向MediaPlayer提供服務(wù)擔(dān)當(dāng)著Service的角色，但是向ServiceManager注冊(cè)服務(wù)的過(guò)程中，則扮演著Client的角色）。

??????? Binder通信支持同步通信，也支持異步通信，但是異步通信的處理優(yōu)先級(jí)低于同步通信。

??????? 但是Binder機(jī)制也存在缺陷，成然Binder機(jī)制支持雙工通信，但是不同與管道和Socket，通信只能由Client發(fā)起，然后Service應(yīng)答（這點(diǎn)和HTTP協(xié)議類似）。Service無(wú)法主動(dòng)向任何一個(gè)Client發(fā)起通信。當(dāng)然，這個(gè)問(wèn)題也并不是無(wú)法解決，通信雙方同時(shí)擔(dān)任Sevice和Client的角色就可以解決問(wèn)題（i.e. ActivityManagerService啟動(dòng)新的activity時(shí)，ActivityManagerService和ActivityThread就是這樣的情況: ActivityManagerService通過(guò)ApplicationThreadProxy控制ApplicationThread創(chuàng)建Activity，而ApplicationThread則通過(guò)ActivityManagerProxy通知ActivityManagerService操作結(jié)果。）

參考資料：

Android進(jìn)程間通信（IPC）機(jī)制Binder簡(jiǎn)要介紹和學(xué)習(xí)計(jì)劃

Android深入淺出之Binder機(jī)制

Android Binder設(shè)計(jì)與實(shí)現(xiàn) – 設(shè)計(jì)篇