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

Binder機制的引入原因

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

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

??????? Binder機制包括四個角色：Binder driver、Service Manager、Service、Client.

Binder driver

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

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

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

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

Service Manager

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

??????? 首先，所有這些Service啟動后，會把自己注冊到Service Manager中。然后，Service Manager就把Service的handle添加到內部的列表中。最后，Client向Service Manager索取Service的Handle時，Service Manager就從內部的列表中查找對應service的handle，并返回給Client，之后Client就可以根據(jù)Handle向Service申請自己需要的服務。

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

Service

??????? Service即服務的提供者，每個Service都擁有一個Binder實體，Service可以根據(jù)需要把自己注冊到Service Manager(即實名Binder），也可以不注冊（即匿名Binder）。匿名Binder必須依賴實名Binder才能工作（因為它必須通過一個Binder把自己發(fā)送到Client端，才能開始Binder通信）。

Client

??????? Client即服務的使用者，Client持有一個Binder引用，而Binder引用則指向特定的Binder實體。Client通過這個Binder引用與Binder實體（即Service）通信，從而獲取Service的服務。廣義上來說，持有Binder引用即為Binder機制的Client，除了ServiceManager這個特例，ServicerManager持有所有實名Binder的引用，但是從來不呼叫這個Binder的服務。

Binder的工作方式

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

? Client Service 用戶空間 BpBinder （準確的說，應該是繼承自BpBinder的對象） BBinder（準確來說，應該是繼承自BBinder的對象） 內核空間 binder_ref binder_node ??????? 這里的內核空間即binder driver。

???????? 模糊的講，BpBinder和Binder_ref都是Binder引用，而BBinder和Binder_node都是binder實體。

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

?????? 從上面的圖中，我們可以看到client通過BpBinder-》binder_ref-》binder_node-》BBinder最終關聯(lián)到一個Service，所以，Client可以通過BpBinder向Service發(fā)起請求。而Service無法主動聯(lián)系Client，因為同時可以有多個Client關聯(lián)到Service。

?????? 整個Binder機制的工作過程是這樣的（暫不討論匿名Binder）：

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

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

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

????? （這個時序圖中，BBinder和Service被畫在一起，因為Android中很多Service的直接繼承自BBinder，所以Service和BBinder可以是一體的）

個人對于Binder機制的理解

??????? 作為一個為C/S架構設計的IPC機制，Binder機制對于C/S架構有相當良好的支持：

Service可以同時為多個Client提供服務。Client可以同時呼叫多個Service的服務。Service和Client的角色并不互斥，同一個進程可以同時身兼兩個角色（i.e. MediaPlayerService 在向MediaPlayer提供服務擔當著Service的角色，但是向ServiceManager注冊服務的過程中，則扮演著Client的角色）。

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

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

參考資料：

Android進程間通信（IPC）機制Binder簡要介紹和學習計劃

Android深入淺出之Binder機制

Android Binder設計與實現(xiàn) – 設計篇