首發(fā)：關(guān)于Binder，作為應(yīng)用開發(fā)者你需要知道的全部

為什么要理解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是邁入高級工程師的第一步。

Binder機(jī)制很復(fù)雜，想要徹底弄懂比較難，除了需要了解操作系統(tǒng)中的各種知識(shí)外，還需要看懂Binder驅(qū)動(dòng)層的代碼實(shí)現(xiàn)。最近看了很多關(guān)于Binder的文章，大部分過于抽象或者過于深入源碼細(xì)節(jié)，真正淺顯易懂的文章很少。個(gè)人認(rèn)為最有參考價(jià)值的是以下三篇：（其他參考文章附在文末）

Android Binder設(shè)計(jì)與實(shí)現(xiàn) - 設(shè)計(jì)篇
Binder學(xué)習(xí)指南
寫給 Android 應(yīng)用工程師的 Binder 原理剖析

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

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

為什么是Binder？
- 傳統(tǒng)Linux IPC機(jī)制的缺點(diǎn)
- Linux的一些基本知識(shí)
- 傳統(tǒng)Linux IPC機(jī)制的通信原理
Binder的基本原理
- Binder的底層原理
- Binder的通信模型
- Binder的代理機(jī)制
- 對Binder概念的重新理解
通過代碼來理解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)于其它方式。

IPC機(jī)制	數(shù)據(jù)拷貝次數(shù)
共享內(nèi)存	0
Binder	1
管道、消息隊(duì)列、Socket	2

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ī)制除外）：

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

IPC.png

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

需要進(jìn)行2次數(shù)據(jù)拷貝，第1次是從發(fā)送方用戶空間拷貝到內(nèi)核緩存區(qū)，第2次是從內(nèi)核緩存區(qū)拷貝到接收方用戶空間。
接收方進(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ù)拷貝。

binder.png

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ò)通信大體過程如下：

Client輸入Server的域名
DNS解析域名

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

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

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

Server向ServiceManager注冊

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

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

Client拿到這個(gè)Binder引用后，就可以通過Binder驅(qū)動(dòng)和Server進(jìn)行通信了。
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)造第一只下蛋的雞呢？

當(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í)體（第一只下蛋的雞）；
并且這個(gè)Binder實(shí)體的引用在所有的Client中都為0，也就說各個(gè)Client通過這個(gè)0號引用就可以和ServiceManager進(jìn)行通信。Server通過0號引用向ServiceManager進(jìn)行注冊，Client通過0號引用就可以獲取到要通信的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方法的呢？

binder_proxy.png

比如一個(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è)類：

IRemoteService

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

IRemoteService的靜態(tài)抽象內(nèi)部類，繼承自Binder，其子類需要實(shí)現(xiàn)IRemoteService接口，表明它是Server的Binder本地對象，需要實(shí)現(xiàn)getPid接口。
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)。也就是說：

Client和Server在同一個(gè)進(jìn)程，obj是Binder本地對象（Stub的子類），asInterface方法返回的就是Binder本地對象；
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方法有兩種場景：

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

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

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è)方法定義了方法編號，transact方法中傳入getPid方法的編號。此時(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;
}

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

Proxy中的mRemote成員實(shí)際上是BinderProxy，而BinderProxy中的transact方法最終調(diào)用于transactNative方法，也就是說Client的請求派發(fā)給了Binder驅(qū)動(dòng)來處理。
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í)傳入的方法編號來區(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);
}

喚醒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";
    //方法編號
    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ò)誤或不足之處，歡迎大家指正。

參考資料

寫這篇文章學(xué)習(xí)了很多資料，整篇文章的思維結(jié)構(gòu)和結(jié)構(gòu)圖在很大程度上都參考了下面的文章，真誠感謝各位作者。

Android Binder設(shè)計(jì)與實(shí)現(xiàn) - 設(shè)計(jì)篇
Binder學(xué)習(xí)指南
寫給 Android 應(yīng)用工程師的 Binder 原理剖析
Android進(jìn)程間通信（IPC）機(jī)制Binder簡要介紹和學(xué)習(xí)計(jì)劃
為什么 Android 要采用 Binder 作為 IPC 機(jī)制？
Linux 虛擬內(nèi)存和物理內(nèi)存的理解
認(rèn)真分析mmap：是什么為什么怎么用
用戶空間與內(nèi)核空間
Android 接口定義語言 (AIDL)
ServiceManager進(jìn)程守護(hù)

色偷偷精品伊人,欧洲久久精品,欧美综合婷婷骚逼,国产AV主播,国产最新探花在线,九色在线视频一区,伊人大交九欧美,1769亚洲,黄色成人av

關(guān)于Binder，作為應(yīng)用開發(fā)者你需要知道的全部

關(guān)于Binder，作為應(yīng)用開發(fā)者你需要知道的全部

為什么要理解Binder？

1. 為什么是Binder？

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

1.1.1 性能角度

1.1.2 安全性考慮

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

1.2.1 進(jìn)程隔離

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

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

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

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

2. Binder的基本原理

2.1 Binder底層原理

2.2 Binder通信模型

2.3 Binder的代理機(jī)制

2.4 對Binder概念的重新理解

3. 通過代碼來理解Binder

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

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

3.1.2 AIDL實(shí)例

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

參考資料

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容

色偷偷精品伊人,欧洲久久精品,欧美综合婷婷骚逼,国产AV主播,国产最新探花在线,九色在线视频一区,伊人大交九 欧美,1769亚洲,黄色成人av

關(guān)于Binder，作為應(yīng)用開發(fā)者你需要知道的全部

為什么要理解Binder？

1. 為什么是Binder？

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

1.1.1 性能角度

1.1.2 安全性考慮

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

1.2.1 進(jìn)程隔離

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

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

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

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

2. Binder的基本原理

2.1 Binder底層原理

2.2 Binder通信模型

2.3 Binder的代理機(jī)制

2.4 對Binder概念的重新理解

3. 通過代碼來理解Binder

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

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

3.1.2 AIDL實(shí)例

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

參考資料

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容

色偷偷精品伊人,欧洲久久精品,欧美综合婷婷骚逼,国产AV主播,国产最新探花在线,九色在线视频一区,伊人大交九欧美,1769亚洲,黄色成人av

為什么要理解Binder？