為什么要理解Binder?

一般Android應(yīng)用開發(fā)很少直接用到跨進(jìn)程信通信(IPC)，但如果你想知道：

• App是如何啟動(dòng)并初始化的?
• Activity的啟動(dòng)過程是怎樣的?
• 進(jìn)程間是如何通信的?
• AIDL的具體原理是什么?
• 眾多插件化框架的設(shè)計(jì)原理 等等

就必須對Binder有所了解，無論是四大組件，還是各種系統(tǒng)Service，比如ActivityManagerService、PackageManagerService，它們的實(shí)現(xiàn)都依賴Binder的通信機(jī)制，可見Binder在Android系統(tǒng)中的重要性，可以說Binder是邁入高級(jí)工程師的***步。

[[245146]]

Binder機(jī)制很復(fù)雜，想要徹底弄懂比較難，除了需要了解操作系統(tǒng)中的各種知識(shí)外，還需要看懂Binder驅(qū)動(dòng)層的代碼實(shí)現(xiàn)。最近看了很多關(guān)于Binder的文章，大部分過于抽象或者過于深入源碼細(xì)節(jié)，真正淺顯易懂的文章很少。

這篇文章主要從宏觀的層面去理解Binder中的各種概念和基本通信過程，只關(guān)注Java層的實(shí)現(xiàn)，底層實(shí)現(xiàn)不做介紹。對于應(yīng)用開發(fā)者而言，理解Binder的基本設(shè)計(jì)原理和通信過程已經(jīng)夠了，想要深入理解Binder需要自行閱讀源碼。

本文主要從三個(gè)方面來做分析：

1、為什么是Binder?

• 傳統(tǒng)Linux IPC機(jī)制的缺點(diǎn)
• Linux的一些基本知識(shí)
• 傳統(tǒng)Linux IPC機(jī)制的通信原理

2、Binder的基本原理

• Binder的底層原理
• Binder的通信模型
• Binder的代理機(jī)制
• 對Binder概念的重新理解

3、通過代碼來理解Binder

• 通過AIDL實(shí)例來了解Binder的用法
• 通過手動(dòng)編碼實(shí)現(xiàn)ActivityManagerService

1、為什么是Binder?

1.1 傳統(tǒng)IPC機(jī)制的缺點(diǎn)

大家都知道Android系統(tǒng)是基于Linux內(nèi)核實(shí)現(xiàn)的，Linux已經(jīng)提供了多種進(jìn)程間通信機(jī)制，比如：管道、消息隊(duì)列、共享內(nèi)存和套接字(Socket)等等，為什么還要再實(shí)現(xiàn)一套IPC機(jī)制呢?主要是基于兩方面的原因：

1.1.1 性能角度

管道、消息隊(duì)列、Socket實(shí)現(xiàn)一次進(jìn)程通信都需要2次內(nèi)存拷貝，效率太低;共享內(nèi)存雖然不需要拷貝內(nèi)存，但管理復(fù)雜;Binder只需要一次內(nèi)存拷貝，從性能角度來看，低于共享內(nèi)存方式，優(yōu)于其它方式。

1.1.2 安全性考慮

傳統(tǒng)的IPC機(jī)制沒有安全措施，接收方無法獲得對方可靠的進(jìn)程ID或用戶ID，完全靠上層的協(xié)議來保護(hù)，比如Socket通信的IP地址是客戶端填入的，很可能被惡意程序篡改。Android作為面向終端用戶的開源平臺(tái)，應(yīng)用市場中有海量的應(yīng)用供用戶選擇，因此安全性極為重要。Android系統(tǒng)為每個(gè)已安裝的App都分配了用戶ID(UID)，UID是鑒別進(jìn)程身份的重要標(biāo)識(shí)，通過UID可以進(jìn)行一系列的權(quán)限校驗(yàn)。另一方面 ，傳統(tǒng)IPC的接入點(diǎn)是開放的，任何程序都可以根據(jù)協(xié)議進(jìn)行訪問，無法阻止惡意程序的訪問，Android需要一種基于C/S架構(gòu)的IPC機(jī)制，Server端需要能夠?qū)lient的請求進(jìn)行身份校驗(yàn)，來保證數(shù)據(jù)的安全性。

1.2 Linux的一些基本知識(shí)

要知道Binder是如何只用一次內(nèi)存拷貝即實(shí)現(xiàn)跨進(jìn)程通信的，首先需要弄清楚為什么傳統(tǒng)IPC機(jī)制為什么需要兩次內(nèi)存拷貝，這就需要先了解一些操作系統(tǒng)的基礎(chǔ)知識(shí)。

1.2.1 進(jìn)程隔離

先來看一下維基百科對“進(jìn)程隔離”的定義：

進(jìn)程隔離是為保護(hù)操作系統(tǒng)中進(jìn)程互不干擾而設(shè)計(jì)的一組不同硬件和軟件的技術(shù)。這個(gè)技術(shù)是為了避免進(jìn)程A寫入進(jìn)程B的情況發(fā)生。 進(jìn)程的隔離實(shí)現(xiàn)，使用了虛擬地址空間。進(jìn)程A的虛擬地址和進(jìn)程B的虛擬地址不同，這樣就防止進(jìn)程A將數(shù)據(jù)信息寫入進(jìn)程B。

也就是說，進(jìn)程之間的數(shù)據(jù)是不共享的，A進(jìn)程無法直接訪問B進(jìn)程的數(shù)據(jù)，以此來保證數(shù)據(jù)的安全性。在進(jìn)程隔離的操作系統(tǒng)中，進(jìn)程之間的交互必須通過IPC機(jī)制。

進(jìn)程隔離的實(shí)現(xiàn)使用了虛擬地址空間，什么是虛擬地址空間呢?首先需要了解操作系統(tǒng)中的虛擬內(nèi)存概念，它是一種提高編程效率和提高物理內(nèi)存利用效率的一種技術(shù)。簡單來說，就是應(yīng)用程序看到了都一片連續(xù)完整的內(nèi)存地址空間，而實(shí)際上這些地壇空間是映射到碎片化的物理內(nèi)存中的，這個(gè)映射的過程對應(yīng)用程序來說是透明的。這個(gè)概念很重要，對于虛擬內(nèi)存更深入的理解可以參考這篇文章：Linux 虛擬內(nèi)存和物理內(nèi)存的理解

1.2.2 進(jìn)程空間：用戶空間/內(nèi)核空間

現(xiàn)在的操作系統(tǒng)都采用虛擬內(nèi)存，對32位的操作系統(tǒng)而言，尋址空間是2的32次方，即4G。操作系統(tǒng)的核心是內(nèi)核，內(nèi)核擁有對底層設(shè)備的所有訪問權(quán)限，因此需要和普通的應(yīng)用程序獨(dú)立開來，用戶進(jìn)程不能直接訪問內(nèi)核進(jìn)程。操作系統(tǒng)從邏輯上把虛擬地址空間劃分為用戶空間(User Space)和內(nèi)核空間(Kernel Space)。在32位的Linux操作系統(tǒng)中，將高位的1GB字節(jié)供內(nèi)核使用，稱之為內(nèi)核空間;剩下的3GB字節(jié)供用戶進(jìn)程使用，稱之為用戶空間。

1.2.3 系統(tǒng)調(diào)用：用戶態(tài)/內(nèi)核態(tài)

因?yàn)橛脩艨臻g的權(quán)限低于內(nèi)核空間，不可避免用戶空間需要訪問內(nèi)核空間的資源，比如讀寫文件和網(wǎng)絡(luò)訪問，如何實(shí)現(xiàn)呢?唯一的方式就是通過操作系統(tǒng)提供的系統(tǒng)調(diào)用接口，通過系統(tǒng)調(diào)用接口，用戶程序可以在內(nèi)核的控制下實(shí)現(xiàn)對內(nèi)核資源的有限訪問，這樣既能滿足應(yīng)用程序的資源請求，也能保障系統(tǒng)安全和穩(wěn)定。

當(dāng)用戶進(jìn)程執(zhí)行自己的代碼時(shí)，進(jìn)程當(dāng)前就處于用戶運(yùn)行態(tài)(用戶態(tài))，此時(shí)處理器執(zhí)行用戶代碼，權(quán)限較低;當(dāng)用戶進(jìn)程通過系統(tǒng)調(diào)用執(zhí)行內(nèi)核代碼時(shí)，進(jìn)程就暫時(shí)進(jìn)入了內(nèi)核運(yùn)行態(tài)(內(nèi)核態(tài))，此時(shí)處理器權(quán)限***，可以執(zhí)行特權(quán)指令。

1.2.4 內(nèi)核模塊/驅(qū)動(dòng)

前面說了用戶空間可以通過系統(tǒng)調(diào)用訪問內(nèi)核空間，那用戶空間之間(進(jìn)程間)怎么通信呢?傳統(tǒng)的IPC機(jī)制都是通過內(nèi)核來支持的，Binder也一樣，有一個(gè)運(yùn)行在內(nèi)核中的Binder驅(qū)動(dòng)程序負(fù)責(zé)進(jìn)程之間Binder的通信。

驅(qū)動(dòng)程序一般指的是設(shè)備驅(qū)動(dòng)程序(Device Driver)，是一種可以使計(jì)算機(jī)和設(shè)備通信的特殊程序。相當(dāng)于硬件的接口，操作系統(tǒng)只有通過這個(gè)接口。

Binder驅(qū)動(dòng)是一種虛擬的字符設(shè)備，注冊在/dev/binder中，其定義了一套Binder通信協(xié)議，負(fù)責(zé)建立進(jìn)程間的Binder通信，提供了數(shù)據(jù)包在進(jìn)程之間傳遞的一系列底層支持。應(yīng)用進(jìn)程訪問Binder驅(qū)動(dòng)也是通過系統(tǒng)調(diào)用實(shí)現(xiàn)的。

1.3 傳統(tǒng)IPC機(jī)制的通信原理

了解了上面的基礎(chǔ)知識(shí)后，我們來看看傳統(tǒng)IPC機(jī)制是如何實(shí)現(xiàn)，通常是下面兩個(gè)步驟(共享內(nèi)存機(jī)制除外)：

1. 發(fā)送方進(jìn)程通過系統(tǒng)調(diào)用(copy_from_user)將要發(fā)送的數(shù)據(jù)存拷貝到內(nèi)核緩存區(qū)中。
2. 接收方開辟一段內(nèi)存空間，內(nèi)核通過系統(tǒng)調(diào)用(copy_to_user)將內(nèi)核緩存區(qū)中的數(shù)據(jù)拷貝到接收方的內(nèi)存緩存區(qū)。

這種傳統(tǒng)IPC機(jī)制存在2個(gè)問題：

1. 需要進(jìn)行2次數(shù)據(jù)拷貝，第1次是從發(fā)送方用戶空間拷貝到內(nèi)核緩存區(qū)，第2次是從內(nèi)核緩存區(qū)拷貝到接收方用戶空間。
2. 接收方進(jìn)程不知道事先要分配多大的空間來接收數(shù)據(jù)，可能存在空間上的浪費(fèi)。

2、Binder的基本原理

2.1 Binder底層原理

傳統(tǒng)IPC機(jī)制需要拷貝2次內(nèi)存，Binder是如何只用1次內(nèi)存拷貝就實(shí)現(xiàn)進(jìn)程間通信的呢?前面我們已經(jīng)了解到，Linux是使用的是虛擬內(nèi)存尋址方式，用戶空間的虛擬內(nèi)存地址是映射到物理內(nèi)存中的，對虛擬內(nèi)存的讀寫實(shí)際上是對物理內(nèi)存的讀寫，這個(gè)過程就是內(nèi)存映射，這個(gè)內(nèi)存映射過程是通過系統(tǒng)調(diào)用mmap()來實(shí)現(xiàn)的。

Binder借助了內(nèi)存映射的方法，在內(nèi)核空間和接收方用戶空間的數(shù)據(jù)緩存區(qū)之間做了一層內(nèi)存映射。這樣一來，從發(fā)送方用戶空間拷貝到內(nèi)核空間緩存區(qū)的數(shù)據(jù)，就相當(dāng)于直接拷貝到了接收方用戶空間的數(shù)據(jù)緩存區(qū)，從而減少了一次數(shù)據(jù)拷貝。

2.2 Binder通信模型

Binder是基于C/S架構(gòu)的，對于通信雙方來說，發(fā)起請求的進(jìn)程屬于Client，接收請求的進(jìn)程屬于Server，由于存在進(jìn)程隔離，雙方不能直接通信，Binder是如何實(shí)現(xiàn)的呢?

寫給 Android 應(yīng)用工程師的 Binder 原理剖析中舉的網(wǎng)絡(luò)通信例子很貼切，Binder的通信過程與網(wǎng)絡(luò)請求類似，網(wǎng)絡(luò)通信過程可以簡化為4個(gè)角色：Client、Server、DNS服務(wù)器和路由器。一次完整的網(wǎng)絡(luò)通信大體過程如下：

a、Client輸入Server的域名

b、DNS解析域名

通過域名是無法直接找到相應(yīng)Server的，必須先通過DNS服務(wù)器將Server的域名轉(zhuǎn)化為具體的IP地址。

c、通過路由器將請求發(fā)送至Server

Client通過DNS服務(wù)器解析到Server的IP地址后，也還不能直接向Server發(fā)起請求，需要經(jīng)過路由器的層層中轉(zhuǎn)才還到達(dá)Server。

d、Server返回?cái)?shù)據(jù)

Server接收到請求并處理后，再通過路由器將數(shù)據(jù)返回給Client。

在Binder機(jī)制中，也定義了4個(gè)角色：Client、Server、Binder驅(qū)動(dòng)和ServiceManager。

Binder驅(qū)動(dòng)：類似網(wǎng)絡(luò)通信中的路由器，負(fù)責(zé)將Client的請求轉(zhuǎn)發(fā)到具體的Server中執(zhí)行，并將Server返回的數(shù)據(jù)傳回給Client。

ServiceManager：類似網(wǎng)絡(luò)通信中的DNS服務(wù)器，負(fù)責(zé)將Client請求的Binder描述符轉(zhuǎn)化為具體的Server地址，以便Binder驅(qū)動(dòng)能夠轉(zhuǎn)發(fā)給具體的Server。Server如需提供Binder服務(wù)，需要向ServiceManager注冊。

具體的通信過程是這樣的：

a、Server向ServiceManager注冊

Server通過Binder驅(qū)動(dòng)向ServiceManager注冊，聲明可以對外提供服務(wù)。ServiceManager中會(huì)保留一份映射表：名字為zhangsan的Server對應(yīng)的Binder引用是0x12345。

b、Client向ServiceManager請求Server的Binder引用

Client想要請求Server的數(shù)據(jù)時(shí)，需要先通過Binder驅(qū)動(dòng)向ServiceManager請求Server的Binder引用：我要向名字為zhangsan的Server通信，請告訴我Server的Binder引用。

c、向具體的Server發(fā)送請求

Client拿到這個(gè)Binder引用后，就可以通過Binder驅(qū)動(dòng)和Server進(jìn)行通信了。

d、Server返回結(jié)果

Server響應(yīng)請求后，需要再次通過Binder驅(qū)動(dòng)將結(jié)果返回給Client。

可以看到，Client、Server、ServiceManager之間的通信都是通過Binder驅(qū)動(dòng)作為橋梁的，可見Binder驅(qū)動(dòng)的重要性。也許你還有一點(diǎn)疑問，ServiceManager和Binder驅(qū)動(dòng)屬于兩個(gè)不同的進(jìn)程，它們是為Client和Server之間的進(jìn)程間通信服務(wù)的，也就是說Client和Server之間的進(jìn)程間通信依賴ServiceManager和Binder驅(qū)動(dòng)之間的進(jìn)程間通信，這就像是：“蛋生雞，雞生蛋，但***個(gè)蛋得通過一只雞孵出來”。Binder機(jī)制是如何創(chuàng)造***只下蛋的雞呢?

1. 當(dāng)Android系統(tǒng)啟動(dòng)后，會(huì)創(chuàng)建一個(gè)名稱為servicemanager的進(jìn)程，這個(gè)進(jìn)程通過一個(gè)約定的命令BINDERSETCONTEXT_MGR向Binder驅(qū)動(dòng)注冊，申請成為為ServiceManager，Binder驅(qū)動(dòng)會(huì)自動(dòng)為ServiceManager創(chuàng)建一個(gè)Binder實(shí)體(***只下蛋的雞);
2. 并且這個(gè)Binder實(shí)體的引用在所有的Client中都為0，也就說各個(gè)Client通過這個(gè)0號(hào)引用就可以和ServiceManager進(jìn)行通信。Server通過0號(hào)引用向ServiceManager進(jìn)行注冊，Client通過0號(hào)引用就可以獲取到要通信的Server的Binder引用。

Android Binder設(shè)計(jì)與實(shí)現(xiàn) - 設(shè)計(jì)篇中對Client、Server、Binder驅(qū)動(dòng)和ServiceManager有更詳細(xì)的介紹。

2.3 Binder的代理機(jī)制

通過上面的分析，我們已經(jīng)知道了Binder的基本通信過程：Client向SerivceManger獲取到Server的Binder引用，Client通過Binder引用向Server發(fā)起具體請求。Client通過這個(gè)Binder引用具體是如何調(diào)用Server方法的呢?

比如一個(gè)Server提供add方法，Client實(shí)際請求add的流程是這樣的：Client先通過Binder驅(qū)動(dòng)向ServiceManager獲取Server的Binder引用，這個(gè)引用就是一個(gè)Java Object，這個(gè)Object有一個(gè)add方法;Cient拿到這個(gè)Object后就可以直接請求add方法了。

實(shí)際上Client拿到的Object并不是Server真正的Binder實(shí)體，Binder驅(qū)動(dòng)做了一層對象轉(zhuǎn)換，將這個(gè)Object包裝成了一個(gè)代理對象ProxyObject，這個(gè)ProxyObject和真正的Binder實(shí)體有相同的方法簽名，Client通過這個(gè)ProxyObject請求add方法時(shí)，Binder驅(qū)動(dòng)會(huì)自動(dòng)將請求轉(zhuǎn)發(fā)到具體的Binder實(shí)體中執(zhí)行，這就是Binder的代理機(jī)制。由于ProxyObject和真正的Binder實(shí)體有相同的方法簽名，其實(shí)Client并不需要關(guān)心是ProxyObject還是真實(shí)的Object。

為了方便描述，下面將Server真正的Binder實(shí)體稱為Binder本地對象;將Client中的Binder引用，即ProxyObject，稱之為Binder代理對象。

2.4 對Binder概念的重新理解

經(jīng)過上面的分析，我們已經(jīng)大體清楚了Binder機(jī)制的基本通信原理，現(xiàn)在回過頭來重新梳理下對Binder機(jī)制的認(rèn)識(shí)：

總體來說，Binder是基于C/S結(jié)構(gòu)的一種面向?qū)ο蟮腎PC機(jī)制。包含：Client、Server、Binder驅(qū)動(dòng)和ServiceManager四大組成部分。各組成部分中的Binder含義都有所有不同：

• 對于Client

Binder是Server本地對象的一個(gè)引用，這個(gè)引用實(shí)際上是一個(gè)代理對象，Client通過這個(gè)代理對象來間接訪問Server的本地對象;

• 對于Server

Binder是提供具體實(shí)現(xiàn)的本地對象，需向ServiceManager注冊;

• 對于Binder驅(qū)動(dòng)

它是連接Client來Server的橋梁，負(fù)責(zé)將代理對象轉(zhuǎn)化為本地對象，并將Server的執(zhí)行結(jié)果返回給Client。

• 對于ServiceManager

它保存了Server Binder字符名稱和Binder引用的映射，Client通過它來找到Server的Binder引用。

Binder驅(qū)動(dòng)中保留了Binder代理對象和Binder本地對象的具體結(jié)構(gòu)，由于我們只關(guān)心Binder的基本通信機(jī)制，底層實(shí)現(xiàn)不做過多介紹，想具體了解的同學(xué)可以參考Android Binder設(shè)計(jì)與實(shí)現(xiàn) - 設(shè)計(jì)篇。

3、通過代碼來理解Binder

上面的介紹比較抽象，現(xiàn)在我們通過具體實(shí)例來理解Binder。

• 通過AIDL實(shí)例來了解Binder的用法
• 通過手動(dòng)編碼實(shí)現(xiàn)ActivityManagerService

3.1 通過AIDL實(shí)例來了解Binder的用法

實(shí)現(xiàn)Binder通信的最常用方法就是通過aidl，aidl接口定義了Client和Server進(jìn)行通信的接口，對aidl不了解的同學(xué)請參考官方文檔Android 接口定義語言 (AIDL)。

3.1.1 與Binder相關(guān)的幾個(gè)類的職責(zé)

在具體分析之前，我們需要先了解與Binder相關(guān)的幾個(gè)類的職責(zé)：

• IBinder

跨進(jìn)程通信的Base接口，它聲明了跨進(jìn)程通信需要實(shí)現(xiàn)的一系列抽象方法，實(shí)現(xiàn)了這個(gè)接口就說明可以進(jìn)行跨進(jìn)程通信，Client和Server都要實(shí)現(xiàn)此接口。

• IInterface

這也是一個(gè)Base接口，用來表示Server提供了哪些能力，是Client和Server通信的協(xié)議。

• Binder

提供Binder服務(wù)的本地對象的基類，它實(shí)現(xiàn)了IBinder接口，所有本地對象都要繼承這個(gè)類。

• BinderProxy

在Binder.java這個(gè)文件中還定義了一個(gè)BinderProxy類，這個(gè)類表示Binder代理對象它同樣實(shí)現(xiàn)了IBinder接口，不過它的很多實(shí)現(xiàn)都交由native層處理。Client中拿到的實(shí)際上是這個(gè)代理對象。

• Stub

這個(gè)類在編譯aidl文件后自動(dòng)生成，它繼承自Binder，表示它是一個(gè)Binder本地對象;它是一個(gè)抽象類，實(shí)現(xiàn)了IInterface接口，表明它的子類需要實(shí)現(xiàn)Server將要提供的具體能力(即aidl文件中聲明的方法)。

• Proxy

它實(shí)現(xiàn)了IInterface接口，說明它是Binder通信過程的一部分;它實(shí)現(xiàn)了aidl中聲明的方法，但最終還是交由其中的mRemote成員來處理，說明它是一個(gè)代理對象，mRemote成員實(shí)際上就是BinderProxy。

3.1.2 AIDL實(shí)例

首先定義一個(gè)aidl文件，這個(gè)接口中聲明了一個(gè)getPid方法：

// IRemoteService.aidl 
package com.rush.demo.aidltest; 
 
interface IRemoteService { 
    int getPid(); 
} 

下面是編譯IRemoteService.aild后生成的java類：

// IRemoteService.java 
package com.rush.demo.aidltest; 
 
public interface IRemoteService extends android.os.IInterface { 
    public static abstract class Stub extends android.os.Binder implements com.rush.demo.aidltest.IRemoteService { 
        //Binder描述符 
        private static final java.lang.String DESCRIPTOR = "com.rush.demo.aidltest.IRemoteService"; 
 
        public Stub() { 
            this.attachInterface(this, DESCRIPTOR); 
        } 
 
        public static com.rush.demo.aidltest.IRemoteService asInterface(android.os.IBinder obj) { 
            if ((obj == null)) { 
                return null; 
            } 
            android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR); 
            if (((iin != null) && (iin instanceof com.rush.demo.aidltest.IRemoteService))) { 
                return ((com.rush.demo.aidltest.IRemoteService) iin); 
            } 
            return new com.rush.demo.aidltest.IRemoteService.Stub.Proxy(obj); 
        } 
 
        @Override 
        public android.os.IBinder asBinder() { 
            return this; 
        } 
 
        @Override 
        public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) throws android.os.RemoteException { 
            switch (code) { 
                case INTERFACE_TRANSACTION: { 
                    reply.writeString(DESCRIPTOR); 
                    return true; 
                } 
                case TRANSACTION_getPid: { 
                    data.enforceInterface(DESCRIPTOR); 
                    java.lang.String _arg0; 
                    _arg0 = data.readString(); 
                    int _result = this.getPid(_arg0); 
                    reply.writeNoException(); 
                    reply.writeInt(_result); 
                    return true; 
                } 
            } 
            return super.onTransact(code, data, reply, flags); 
        } 
 
        private static class Proxy implements com.rush.demo.aidltest.IRemoteService { 
            private android.os.IBinder mRemote; 
 
            Proxy(android.os.IBinder remote) { 
                mRemote = remote; 
            } 
 
            @Override 
            public android.os.IBinder asBinder() { 
                return mRemote; 
            } 
 
            public java.lang.String getInterfaceDescriptor() { 
                return DESCRIPTOR; 
            } 
 
            @Override 
            public int getPid(java.lang.String name) throws android.os.RemoteException { 
                android.os.Parcel _data = android.os.Parcel.obtain(); 
                android.os.Parcel _reply = android.os.Parcel.obtain(); 
                int _result; 
                try { 
                    _data.writeInterfaceToken(DESCRIPTOR); 
                    _data.writeString(name); 
                    mRemote.transact(Stub.TRANSACTION_getPid, _data, _reply, 0); 
                    _reply.readException(); 
                    _result = _reply.readInt(); 
                } finally { 
                    _reply.recycle(); 
                    _data.recycle(); 
                } 
                return _result; 
            } 
 
        static final int TRANSACTION_getPid = (android.os.IBinder.FIRST_CALL_TRANSACTION + 0); 
    } 
 
    public int getPid(java.lang.String name) throws android.os.RemoteException; 
} 

這個(gè)文件中有3個(gè)類：

a、IRemoteService

繼承至IInterface接口，聲明了IRemoteService.aidl中聲明的getPid方法，它是Client和Service通信的接口。

b、IRemoteService.Stub

IRemoteService的靜態(tài)抽象內(nèi)部類，繼承自Binder，其子類需要實(shí)現(xiàn)IRemoteService接口，表明它是Server的Binder本地對象，需要實(shí)現(xiàn)getPid接口。

c、IRemoteService.Stub.Proxy

IRemoteService.Stub的靜態(tài)內(nèi)部類，它并沒有繼承自Binder，而是包含了一個(gè)IBinder對象，這個(gè)對象其實(shí)是BinderProxy，說明它是Server在Client中的本地代理對象。Proxy實(shí)現(xiàn)了getPid接口，將參數(shù)序列化后交由mRemote(BinderProxy)處理，實(shí)際上就是交給Binder驅(qū)動(dòng)來完成與遠(yuǎn)程Stub的通信。

先來看Stub中的asInterface方法，這個(gè)方法通常是Client在bindService成功后，由Client來調(diào)用的，作用是將綁定成功后返回的IBinder對象轉(zhuǎn)換為具體的IInterface接口，Client拿到這個(gè)IInterface接口后就可以和自由的調(diào)用Server提供的方法了。

public static com.rush.demo.aidltest.IRemoteService asInterface(android.os.IBinder obj) { 
    if ((obj == null)) { 
        return null; 
    } 
    android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR); 
    if (((iin != null) && (iin instanceof com.rush.demo.aidltest.IRemoteService))) { 
        return ((com.rush.demo.aidltest.IRemoteService) iin); 
    } 
    return new com.rush.demo.aidltest.IRemoteService.Stub.Proxy(obj); 
} 

asInterface方法中既可能返回Stub本身的IRemoteService對象，也可能創(chuàng)建一個(gè)Proxy對象，這是為什么呢?因?yàn)锽inder雖然是跨進(jìn)程通信機(jī)制，但也可以為本進(jìn)程服務(wù)，也就是說Client和Server可能在同一個(gè)進(jìn)程，在同一個(gè)進(jìn)程就沒必要通過Binder驅(qū)動(dòng)來中轉(zhuǎn)了，直接訪問就可以了;如果Client和Server在不同的進(jìn)程，就需要通過Binder代理對象來中轉(zhuǎn)。也就是說：

1. Client和Server在同一個(gè)進(jìn)程，obj是Binder本地對象(Stub的子類)，asInterface方法返回的就是Binder本地對象;
2. Client和Server在不同的進(jìn)程，obj實(shí)際上是Binder代理對象，asInterface返回一個(gè)Proxy對象。

//Binder.java 
/** 
 * obj.queryLocalInterface是怎樣去查找是否有本地的IInterface呢，從Binder的代碼中可以看到，只是簡單的比較Binder的描述符和要查找的描述符是否匹配，匹配的話直接返回mOwner，這個(gè)mOwner就是Stub構(gòu)造方法中調(diào)用attachInterface方法傳入的this參數(shù)。 
 */ 
public IInterface queryLocalInterface(String descriptor) { 
    if (mDescriptor.equals(descriptor)) { 
        return mOwner; 
    } 
    return null; 
} 
 
final class BinderProxy implements IBinder { 
    public IInterface queryLocalInterface(String descriptor) { 
        return null; 
    } 
} 
 
public static abstract class Stub extends android.os.Binder implements com.rush.demo.aidltest.IRemoteService { 
    // Binder描述符，值為接口類名全稱 
    private static final java.lang.String DESCRIPTOR = "com.rush.demo.aidltest.IRemoteService"; 
 
    public Stub() { 
        //向Binder中綁定owner和descriptor 
        this.attachInterface(this, DESCRIPTOR); 
    } 
} 

obj.queryLocalInterface是怎樣去查找是否有本地的IInterface呢，從Binder的代碼中可以看到，只是簡單的比較Binder的描述符和要查找的描述符是否匹配，匹配的話直接返回mOwner，這個(gè)mOwner就是Stub構(gòu)造方法中調(diào)用attachInterface方法傳入的this參數(shù)。而BinderProxy的queryLocalInterface方法直接返回null。

Client中通過Binder調(diào)用Server方法有兩種場景：

1、Client和Server在同一個(gè)進(jìn)程

Stub.asInterface方法返回的是Stub對象，即Binder本地對象。也就是說和Binder跨進(jìn)程通信無關(guān)，直接調(diào)用即可，此時(shí)Client調(diào)用方和Server響應(yīng)方在同一個(gè)線程中。

2、Client和Server在不同的進(jìn)程

Stub.asInterface方法返回的是Binder代理對象，需要通過Binder驅(qū)動(dòng)完成跨進(jìn)程通信。這種場景下，Client調(diào)用方線程會(huì)被掛起(Binder也提供了異步的方式，這里不討論)，等待Server響應(yīng)后返回?cái)?shù)據(jù)。這里要注意的是，Server的響應(yīng)是在Server進(jìn)程的Binder線程池中處理的，并不是主線程。

接下來分析跨進(jìn)程場景下，Client調(diào)用getPid方法的具體流程：

1、Client調(diào)用Binder代理對象，Client線程掛起

Client中拿到的IRemoteService引用實(shí)際上是Proxy，調(diào)用getPid方法實(shí)際上是調(diào)用Proxy的getPid方法，這個(gè)方法只是將參數(shù)序列化后，調(diào)用了mRemote成員的transact方法。Stub類中為IRemoteService中的每個(gè)方法定義了方法編號(hào)，transact方法中傳入getPid方法的編號(hào)。此時(shí)Client調(diào)用方線程掛起，等待Server響應(yīng)數(shù)據(jù)。

// Stub.Proxy 
public int getPid(java.lang.String name) throws android.os.RemoteException { 
    ... 
    _data.writeInterfaceToken(DESCRIPTOR); 
    _data.writeString(name); 
    mRemote.transact(Stub.TRANSACTION_getPid, _data, _reply, 0); 
    _reply.readException(); 
    _result = _reply.readInt(); 
    ... 
    return _result; 
} 

2、Binder代理對象將請求派發(fā)給Binder驅(qū)動(dòng)

Proxy中的mRemote成員實(shí)際上是BinderProxy，而BinderProxy中的transact方法最終調(diào)用于transactNative方法，也就是說Client的請求派發(fā)給了Binder驅(qū)動(dòng)來處理。

3、Binder驅(qū)動(dòng)將請求派發(fā)給Server

Binder驅(qū)動(dòng)經(jīng)過一系列的處理后，將請求派發(fā)給了Server，即調(diào)用Server本地Binder對象(Stub)的onTransact方法最終在此方法中完成getPid方法的具體調(diào)用。在onTransact方法中，根據(jù)Proxy中調(diào)用transact時(shí)傳入的方法編號(hào)來區(qū)別具體要處理的方法。

// Stub 
public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) throws android.os.RemoteException { 
    switch (code) { 
        ... 
        case TRANSACTION_getPid: { 
            data.enforceInterface(DESCRIPTOR); 
            //獲取方法參數(shù) 
            java.lang.String _arg0 = data.readString(); 
            //調(diào)用getPid方法，這個(gè)方法在Stub的子類，即Server中實(shí)現(xiàn) 
            int _result = this.getPid(_arg0); 
            reply.writeNoException(); 
            reply.writeInt(_result); 
            return true; 
        } 
    } 
    return super.onTransact(code, data, reply, flags); 
} 

4、喚醒Client線程，返回結(jié)果

onTransact處理結(jié)束后，將結(jié)果寫入reply并返回至Binder驅(qū)動(dòng)，驅(qū)動(dòng)喚醒掛起的Client線程，并將結(jié)果返回。至此，一次跨進(jìn)程通信完成。

3.2 手動(dòng)編碼來實(shí)現(xiàn)ActivityManagerService

通過前面的示例我們已經(jīng)知道，aidl文件只是用來定義C/S交互的接口，Android在編譯時(shí)會(huì)自動(dòng)生成相應(yīng)的Java類，生成的類中包含了Stub和Proxy靜態(tài)內(nèi)部類，用來封裝數(shù)據(jù)轉(zhuǎn)換的過程，實(shí)際使用時(shí)只關(guān)心具體的Java接口類即可。為什么Stub和Proxy是靜態(tài)內(nèi)部類呢?這其實(shí)只是為了將三個(gè)類放在一個(gè)文件中，提高代碼的聚合性。通過上面的分析，我們其實(shí)完全可以不通過aidl，手動(dòng)編碼來實(shí)現(xiàn)Binder的通信，下面我們通過編碼來實(shí)現(xiàn)ActivityManagerService。

首先定義IActivityManager接口：

public interface IActivityManager extends IInterface { 
    //binder描述符 
    String DESCRIPTOR = "android.app.IActivityManager"; 
    //方法編號(hào) 
    int TRANSACTION_startActivity = IBinder.FIRST_CALL_TRANSACTION + 0; 
    //聲明一個(gè)啟動(dòng)activity的方法，為了簡化，這里只傳入intent參數(shù) 
    int startActivity(Intent intent) throws RemoteException; 
} 

其次，實(shí)現(xiàn)ActivityManagerService側(cè)的本地Binder對象基類：

// 名稱隨意，不一致叫Stub 
public abstract class ActivityManagerNative extends Binder implements IActivityManager { 
 
    public static IActivityManager asInterface(IBinder obj) { 
        if (obj == null) { 
            return null; 
        } 
        IActivityManager in = (IActivityManager) obj.queryLocalInterface(IActivityManager.DESCRIPTOR); 
        if (in != null) { 
            return in; 
        } 
        //代理對象，見下面的代碼 
        return new ActivityManagerProxy(obj); 
    } 
 
    @Override 
    public IBinder asBinder() { 
        return this; 
    } 
 
    @Override 
    protected boolean onTransact(int code, Parcel data, Parcel reply, int flags) throws RemoteException { 
        switch (code) { 
            // 獲取binder描述符 
            case INTERFACE_TRANSACTION: 
                reply.writeString(IActivityManager.DESCRIPTOR); 
                return true; 
            // 啟動(dòng)activity，從data中反序列化出intent參數(shù)后，直接調(diào)用子類startActivity方法啟動(dòng)activity。 
            case IActivityManager.TRANSACTION_startActivity: 
                data.enforceInterface(IActivityManager.DESCRIPTOR); 
                Intent intent = Intent.CREATOR.createFromParcel(data); 
                int result = this.startActivity(intent); 
                reply.writeNoException(); 
                reply.writeInt(result); 
                return true; 
        } 
        return super.onTransact(code, data, reply, flags); 
    } 
} 

再次，實(shí)現(xiàn)Client側(cè)的代理對象：

public class ActivityManagerProxy implements IActivityManager { 
    private IBinder mRemote; 
 
    public ActivityManagerProxy(IBinder remote) { 
        mRemote = remote; 
    } 
 
    @Override 
    public IBinder asBinder() { 
        return mRemote; 
    } 
 
    @Override 
    public int startActivity(Intent intent) throws RemoteException { 
        Parcel data = Parcel.obtain(); 
        Parcel reply = Parcel.obtain(); 
        int result; 
        try { 
            // 將intent參數(shù)序列化，寫入data中 
            intent.writeToParcel(data, 0); 
            // 調(diào)用BinderProxy對象的transact方法，交由Binder驅(qū)動(dòng)處理。 
            mRemote.transact(IActivityManager.TRANSACTION_startActivity, data, reply, 0); 
            reply.readException(); 
            // 等待server執(zhí)行結(jié)束后，讀取執(zhí)行結(jié)果 
            result = reply.readInt(); 
        } finally { 
            data.recycle(); 
            reply.recycle(); 
        } 
        return result; 
    } 
} 

***，實(shí)現(xiàn)Binder本地對象(IActivityManager接口)：

public class ActivityManagerService extends ActivityManagerNative { 
    @Override 
    public int startActivity(Intent intent) throws RemoteException { 
        // 啟動(dòng)activity 
        return 0; 
    } 
} 

簡化版的ActivityManagerService到這里就已經(jīng)實(shí)現(xiàn)了，剩下就是Client需要獲取到AMS的代理對象IActivityManager就可以通信了。實(shí)際開發(fā)過程中通過aidl文件能夠自動(dòng)編譯出中間代碼，并不需要我們手動(dòng)去實(shí)現(xiàn)，不過手動(dòng)編碼能夠加深對Binder機(jī)制的理解。在開發(fā)過程中我們也并不會(huì)直接使用到AMS，但了解AMS實(shí)現(xiàn)原理對熟悉Framework來說必不可少，關(guān)于AMS具體實(shí)現(xiàn)原理，我會(huì)在后續(xù)的文章中分析。

至此，Binder機(jī)制的基本通信過程就介紹完了，由于Binder機(jī)制太過復(fù)雜，本人水平有限，文中難免出現(xiàn)錯(cuò)誤或不足之處，歡迎大家指正。