一、前言

這篇文章我醞釀了很久锨苏，參考了很多資料疙教，讀了很多源碼，卻依舊不敢下筆伞租。生怕自己理解上還有偏差贞谓，對大家造成誤解，貽笑大方葵诈。又怕自己理解不夠透徹经宏，無法用清晰直白的文字準(zhǔn)確的表達(dá)出 Binder 的設(shè)計(jì)精髓。直到今天提筆寫作時(shí)還依舊戰(zhàn)戰(zhàn)兢兢驯击。

Binder 之復(fù)雜遠(yuǎn)遠(yuǎn)不是一篇文章就能說清楚的烁兰，本文想站在一個(gè)更高的維度來俯瞰 Binder 的設(shè)計(jì)，最終幫助大家形成一個(gè)完整的概念徊都。對于應(yīng)用層開發(fā)的同學(xué)來說沪斟，理解到本文這個(gè)程度也就差不多了。希望更加深入理解 Binder 實(shí)現(xiàn)機(jī)制的，可以閱讀文末的參考資料以及相關(guān)源碼主之。

二择吊、Binder 概述

簡單介紹下什么是 Binder。Binder 是一種進(jìn)程間通信機(jī)制槽奕，基于開源的 OpenBinder 實(shí)現(xiàn)几睛；OpenBinder 起初由 Be Inc. 開發(fā)，后由 Plam Inc. 接手粤攒。從字面上來解釋 Binder 有膠水所森、粘合劑的意思，顧名思義就是粘和不同的進(jìn)程夯接，使之實(shí)現(xiàn)通信焕济。對于 Binder 更全面的定義，等我們介紹完 Binder 通信原理后再做詳細(xì)說明盔几。

1.1 為什么必須理解 Binder 晴弃？

作為 Android 工程師的你，是不是常常會(huì)有這樣的疑問：

• 為什么 Activity 間傳遞對象需要序列化逊拍？
• Activity 的啟動(dòng)流程是什么樣的上鞠？
• 四大組件底層的通信機(jī)制是怎樣的？
• AIDL 內(nèi)部的實(shí)現(xiàn)原理是什么芯丧？
• 插件化編程技術(shù)應(yīng)該從何學(xué)起芍阎？等等…

這些問題的背后都與 Binder 有莫大的關(guān)系注整，要弄懂上面這些問題理解 Bidner 通信機(jī)制是必須的度硝。

我們知道 Android 應(yīng)用程序是由 Activity、Service蕊程、Broadcast Receiver 和 Content Provide 四大組件中的一個(gè)或者多個(gè)組成的。有時(shí)這些組件運(yùn)行在同一進(jìn)程驹暑，有時(shí)運(yùn)行在不同的進(jìn)程辨赐。這些進(jìn)程間的通信就依賴于 Binder IPC 機(jī)制。不僅如此帆焕，Android 系統(tǒng)對應(yīng)用層提供的各種服務(wù)如：ActivityManagerService不恭、PackageManagerService 等都是基于 Binder IPC 機(jī)制來實(shí)現(xiàn)的叶雹。Binder 機(jī)制在 Android 中的位置非常重要财饥，毫不夸張的說理解 Binder 是邁向 Android 高級工程的第一步。

1.2 為什么是 Binder ?

Android 系統(tǒng)是基于 Linux 內(nèi)核的折晦，Linux 已經(jīng)提供了管道钥星、消息隊(duì)列、共享內(nèi)存和 Socket 等 IPC 機(jī)制满着。那為什么 Android 還要提供 Binder 來實(shí)現(xiàn) IPC 呢谦炒？主要是基于性能、穩(wěn)定性和安全性幾方面的原因漓滔。

性能

首先說說性能上的優(yōu)勢编饺。Socket 作為一款通用接口，其傳輸效率低响驴，開銷大透且，主要用在跨網(wǎng)絡(luò)的進(jìn)程間通信和本機(jī)上進(jìn)程間的低速通信。消息隊(duì)列和管道采用存儲(chǔ)-轉(zhuǎn)發(fā)方式豁鲤，即數(shù)據(jù)先從發(fā)送方緩存區(qū)拷貝到內(nèi)核開辟的緩存區(qū)中秽誊，然后再從內(nèi)核緩存區(qū)拷貝到接收方緩存區(qū)，至少有兩次拷貝過程琳骡。共享內(nèi)存雖然無需拷貝锅论，但控制復(fù)雜，難以使用楣号。Binder 只需要一次數(shù)據(jù)拷貝最易，性能上僅次于共享內(nèi)存。

注：各種IPC方式數(shù)據(jù)拷貝次數(shù)炫狱，此表來源于Android Binder 設(shè)計(jì)與實(shí)現(xiàn) - 設(shè)計(jì)篇

穩(wěn)定性

再說說穩(wěn)定性嬉荆，Binder 基于 C/S 架構(gòu)鄙早，客戶端（Client）有什么需求就丟給服務(wù)端（Server）去完成限番，架構(gòu)清晰弥虐、職責(zé)明確又相互獨(dú)立驴剔，自然穩(wěn)定性更好丧失。共享內(nèi)存雖然無需拷貝布讹，但是控制負(fù)責(zé)描验，難以使用膘流。從穩(wěn)定性的角度講呼股，Binder 機(jī)制是優(yōu)于內(nèi)存共享的。

安全性

另一方面就是安全性允扇。Android 作為一個(gè)開放性的平臺(tái)狭园，市場上有各類海量的應(yīng)用供用戶選擇安裝妙啃，因此安全性對于 Android 平臺(tái)而言極其重要。作為用戶當(dāng)然不希望我們下載的 APP 偷偷讀取我的通信錄馆匿，上傳我的隱私數(shù)據(jù)阿逃，后臺(tái)偷跑流量恃锉、消耗手機(jī)電量破托。傳統(tǒng)的 IPC 沒有任何安全措施土砂，完全依賴上層協(xié)議來確保吴叶。首先傳統(tǒng)的 IPC 接收方無法獲得對方可靠的進(jìn)程用戶ID/進(jìn)程ID（UID/PID）蚌卤，從而無法鑒別對方身份造寝。Android 為每個(gè)安裝好的 APP 分配了自己的 UID诫龙，故而進(jìn)程的 UID 是鑒別進(jìn)程身份的重要標(biāo)志签赃。傳統(tǒng)的 IPC 只能由用戶在數(shù)據(jù)包中填入 UID/PID锦聊，但這樣不可靠，容易被惡意程序利用材蛛⊙康可靠的身份標(biāo)識(shí)只有由 IPC 機(jī)制在內(nèi)核中添加挣菲。其次傳統(tǒng)的 IPC 訪問接入點(diǎn)是開放的白胀，只要知道這些接入點(diǎn)的程序都可以和對端建立連接或杠，不管怎樣都無法阻止惡意程序通過猜測接收方地址獲得連接蔓涧。同時(shí) Binder 既支持實(shí)名 Binder元暴，又支持匿名 Binder茉盏，安全性高鸠姨。

基于上述原因讶迁，Android 需要建立一套新的 IPC 機(jī)制來滿足系統(tǒng)對穩(wěn)定性巍糯、傳輸性能和安全性方面的要求，這就是 Binder宅楞。

最后用一張表格來總結(jié)下 Binder 的優(yōu)勢：

二换棚、Linux 下傳統(tǒng)的進(jìn)程間通信原理

了解 Linux IPC 相關(guān)的概念和原理有助于我們理解 Binder 通信原理固蚤。因此，在介紹 Binder 跨進(jìn)程通信原理之前惊豺，我們先聊聊 Linux 系統(tǒng)下傳統(tǒng)的進(jìn)程間通信是如何實(shí)現(xiàn)揩页。

2.1 基本概念介紹

這里我們先從 Linux 中進(jìn)程間通信涉及的一些基本概念開始介紹碍沐，然后逐步展開累提，向大家說明傳統(tǒng)的進(jìn)程間通信的原理斋陪。

image

上圖展示了 Liunx 中跨進(jìn)程通信涉及到的一些基本概念：

• 進(jìn)程隔離
• 進(jìn)程空間劃分：用戶空間(User Space)/內(nèi)核空間(Kernel Space)
• 系統(tǒng)調(diào)用：用戶態(tài)/內(nèi)核態(tài)

進(jìn)程隔離

簡單的說就是操作系統(tǒng)中，進(jìn)程與進(jìn)程間內(nèi)存是不共享的友题。兩個(gè)進(jìn)程就像兩個(gè)平行的世界度宦，A 進(jìn)程沒法直接訪問 B 進(jìn)程的數(shù)據(jù)戈抄，這就是進(jìn)程隔離的通俗解釋划鸽。A 進(jìn)程和 B 進(jìn)程之間要進(jìn)行數(shù)據(jù)交互就得采用特殊的通信機(jī)制：進(jìn)程間通信（IPC）嫂用。

進(jìn)程空間劃分：用戶空間(User Space)/內(nèi)核空間(Kernel Space)

現(xiàn)在操作系統(tǒng)都是采用的虛擬存儲(chǔ)器尸折，對于 32 位系統(tǒng)而言实夹，它的尋址空間（虛擬存儲(chǔ)空間）就是 2 的 32 次方亮航，也就是 4GB缴淋。操作系統(tǒng)的核心是內(nèi)核，獨(dú)立于普通的應(yīng)用程序祖灰，可以訪問受保護(hù)的內(nèi)存空間恨统，也可以訪問底層硬件設(shè)備的權(quán)限畜埋。為了保護(hù)用戶進(jìn)程不能直接操作內(nèi)核悠鞍，保證內(nèi)核的安全咖祭，操作系統(tǒng)從邏輯上將虛擬空間劃分為用戶空間（User Space）和內(nèi)核空間（Kernel Space）心肪。針對 Linux 操作系統(tǒng)而言硬鞍，將最高的 1GB 字節(jié)供內(nèi)核使用固该，稱為內(nèi)核空間伐坏；較低的 3GB 字節(jié)供各進(jìn)程使用，稱為用戶空間纯露。

簡單的說就是埠褪，內(nèi)核空間（Kernel）是系統(tǒng)內(nèi)核運(yùn)行的空間钞速，用戶空間（User Space）是用戶程序運(yùn)行的空間渴语。為了保證安全性遵班，它們之間是隔離的。

image

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

雖然從邏輯上進(jìn)行了用戶空間和內(nèi)核空間的劃分翰萨，但不可避免的用戶空間需要訪問內(nèi)核資源亩鬼，比如文件操作雳锋、訪問網(wǎng)絡(luò)等等玷过。為了突破隔離限制粤蝎，就需要借助系統(tǒng)調(diào)用來實(shí)現(xiàn)初澎。系統(tǒng)調(diào)用是用戶空間訪問內(nèi)核空間的唯一方式碑宴，保證了所有的資源訪問都是在內(nèi)核的控制下進(jìn)行的延柠，避免了用戶程序?qū)ο到y(tǒng)資源的越權(quán)訪問捕仔，提升了系統(tǒng)安全性和穩(wěn)定性。

Linux 使用兩級保護(hù)機(jī)制：0 級供系統(tǒng)內(nèi)核使用钓葫，3 級供用戶程序使用础浮。

當(dāng)一個(gè)任務(wù)（進(jìn)程）執(zhí)行系統(tǒng)調(diào)用而陷入內(nèi)核代碼中執(zhí)行時(shí)豆同，稱進(jìn)程處于內(nèi)核運(yùn)行態(tài)（內(nèi)核態(tài)）影锈。此時(shí)處理器處于特權(quán)級最高的（0級）內(nèi)核代碼中執(zhí)行枣抱。當(dāng)進(jìn)程處于內(nèi)核態(tài)時(shí)佳晶，執(zhí)行的內(nèi)核代碼會(huì)使用當(dāng)前進(jìn)程的內(nèi)核棧轿秧。每個(gè)進(jìn)程都有自己的內(nèi)核棧晒他。

當(dāng)進(jìn)程在執(zhí)行用戶自己的代碼的時(shí)候，我們稱其處于用戶運(yùn)行態(tài)（用戶態(tài)）津滞。此時(shí)處理器在特權(quán)級最低的（3級）用戶代碼中運(yùn)行触徐。

系統(tǒng)調(diào)用主要通過如下兩個(gè)函數(shù)來實(shí)現(xiàn)：

copy_from_user() //將數(shù)據(jù)從用戶空間拷貝到內(nèi)核空間
copy_to_user() //將數(shù)據(jù)從內(nèi)核空間拷貝到用戶空間

2.2 Linux 下的傳統(tǒng) IPC 通信原理

理解了上面的幾個(gè)概念，我們再來看看傳統(tǒng)的 IPC 方式中鸟雏，進(jìn)程之間是如何實(shí)現(xiàn)通信的孝鹊。

通常的做法是消息發(fā)送方將要發(fā)送的數(shù)據(jù)存放在內(nèi)存緩存區(qū)中又活，通過系統(tǒng)調(diào)用進(jìn)入內(nèi)核態(tài)柳骄。然后內(nèi)核程序在內(nèi)核空間分配內(nèi)存耐薯，開辟一塊內(nèi)核緩存區(qū)鸠踪，調(diào)用 copy_from_user() 函數(shù)將數(shù)據(jù)從用戶空間的內(nèi)存緩存區(qū)拷貝到內(nèi)核空間的內(nèi)核緩存區(qū)中营密。同樣的评汰，接收方進(jìn)程在接收數(shù)據(jù)時(shí)在自己的用戶空間開辟一塊內(nèi)存緩存區(qū)，然后內(nèi)核程序調(diào)用 copy_to_user() 函數(shù)將數(shù)據(jù)從內(nèi)核緩存區(qū)拷貝到接收進(jìn)程的內(nèi)存緩存區(qū)惨缆。這樣數(shù)據(jù)發(fā)送方進(jìn)程和數(shù)據(jù)接收方進(jìn)程就完成了一次數(shù)據(jù)傳輸坯墨，我們稱完成了一次進(jìn)程間通信捣染。如下圖：

image

這種傳統(tǒng)的 IPC 通信方式有兩個(gè)問題：

1. 性能低下，一次數(shù)據(jù)傳遞需要經(jīng)歷：內(nèi)存緩存區(qū) --> 內(nèi)核緩存區(qū) --> 內(nèi)存緩存區(qū)蕾各，需要 2 次數(shù)據(jù)拷貝示损；

2. 接收數(shù)據(jù)的緩存區(qū)由數(shù)據(jù)接收進(jìn)程提供检访，但是接收進(jìn)程并不知道需要多大的空間來存放將要傳遞過來的數(shù)據(jù)脆贵，因此只能開辟盡可能大的內(nèi)存空間或者先調(diào)用 API 接收消息頭來獲取消息體的大小，這兩種做法不是浪費(fèi)空間就是浪費(fèi)時(shí)間。

三柏腻、Binder 跨進(jìn)程通信原理

理解了 Linux IPC 相關(guān)概念和通信原理，接下來我們正式介紹下 Binder IPC 的原理肯尺。

3.1 動(dòng)態(tài)內(nèi)核可加載模塊 && 內(nèi)存映射

正如前面所說槐臀，跨進(jìn)程通信是需要內(nèi)核空間做支持的水慨。傳統(tǒng)的 IPC 機(jī)制如管道讥巡、Socket 都是內(nèi)核的一部分，因此通過內(nèi)核支持來實(shí)現(xiàn)進(jìn)程間通信自然是沒問題的捉蚤。但是 Binder 并不是 Linux 系統(tǒng)內(nèi)核的一部分缆巧，那怎么辦呢陕悬？這就得益于 Linux 的動(dòng)態(tài)內(nèi)核可加載模塊（Loadable Kernel Module捉超，LKM）的機(jī)制；模塊是具有獨(dú)立功能的程序况芒，它可以被單獨(dú)編譯耐版，但是不能獨(dú)立運(yùn)行粪牲。它在運(yùn)行時(shí)被鏈接到內(nèi)核作為內(nèi)核的一部分運(yùn)行湿滓。這樣叽奥，Android 系統(tǒng)就可以通過動(dòng)態(tài)添加一個(gè)內(nèi)核模塊運(yùn)行在內(nèi)核空間朝氓，用戶進(jìn)程之間通過這個(gè)內(nèi)核模塊作為橋梁來實(shí)現(xiàn)通信赵哲。

在 Android 系統(tǒng)中枫夺，這個(gè)運(yùn)行在內(nèi)核空間，負(fù)責(zé)各個(gè)用戶進(jìn)程通過 Binder 實(shí)現(xiàn)通信的內(nèi)核模塊就叫 Binder 驅(qū)動(dòng)（Binder Dirver）扒最。

那么在 Android 系統(tǒng)中用戶進(jìn)程之間是如何通過這個(gè)內(nèi)核模塊（Binder 驅(qū)動(dòng)）來實(shí)現(xiàn)通信的呢吧趣？難道是和前面說的傳統(tǒng) IPC 機(jī)制一樣强挫，先將數(shù)據(jù)從發(fā)送方進(jìn)程拷貝到內(nèi)核緩存區(qū)纠拔，然后再將數(shù)據(jù)從內(nèi)核緩存區(qū)拷貝到接收方進(jìn)程稠诲，通過兩次拷貝來實(shí)現(xiàn)嗎略水？顯然不是渊涝，否則也不會(huì)有開篇所說的 Binder 在性能方面的優(yōu)勢了跨释。

這就不得不通道 Linux 下的另一個(gè)概念：內(nèi)存映射鳖谈。

Binder IPC 機(jī)制中涉及到的內(nèi)存映射通過 mmap() 來實(shí)現(xiàn)，mmap() 是操作系統(tǒng)中一種內(nèi)存映射的方法瑰排。內(nèi)存映射簡單的講就是將用戶空間的一塊內(nèi)存區(qū)域映射到內(nèi)核空間崇渗。映射關(guān)系建立后显押，用戶對這塊內(nèi)存區(qū)域的修改可以直接反應(yīng)到內(nèi)核空間；反之內(nèi)核空間對這段區(qū)域的修改也能直接反應(yīng)到用戶空間金拒。

內(nèi)存映射能減少數(shù)據(jù)拷貝次數(shù)绪抛，實(shí)現(xiàn)用戶空間和內(nèi)核空間的高效互動(dòng)幢码。兩個(gè)空間各自的修改能直接反映在映射的內(nèi)存區(qū)域店雅，從而被對方空間及時(shí)感知闹啦。也正因?yàn)槿绱饲戏埽瑑?nèi)存映射能夠提供對進(jìn)程間通信的支持琳袄。

3.2 Binder IPC 實(shí)現(xiàn)原理

Binder IPC 正是基于內(nèi)存映射（mmap）來實(shí)現(xiàn)的，但是 mmap() 通常是用在有物理介質(zhì)的文件系統(tǒng)上的吁峻。

比如進(jìn)程中的用戶區(qū)域是不能直接和物理設(shè)備打交道的，如果想要把磁盤上的數(shù)據(jù)讀取到進(jìn)程的用戶區(qū)域矮慕，需要兩次拷貝（磁盤-->內(nèi)核空間-->用戶空間）痴鳄；通常在這種場景下 mmap() 就能發(fā)揮作用，通過在物理介質(zhì)和用戶空間之間建立映射橡类，減少數(shù)據(jù)的拷貝次數(shù)顾画，用內(nèi)存讀寫取代I/O讀寫研侣，提高文件讀取效率庶诡。

而 Binder 并不存在物理介質(zhì)末誓，因此 Binder 驅(qū)動(dòng)使用 mmap() 并不是為了在物理介質(zhì)和用戶空間之間建立映射蘸吓，而是用來在內(nèi)核空間創(chuàng)建數(shù)據(jù)接收的緩存空間库继。

一次完整的 Binder IPC 通信過程通常是這樣：

1. 首先 Binder 驅(qū)動(dòng)在內(nèi)核空間創(chuàng)建一個(gè)數(shù)據(jù)接收緩存區(qū)宪萄；

2. 接著在內(nèi)核空間開辟一塊內(nèi)核緩存區(qū)，建立內(nèi)核緩存區(qū)和內(nèi)核中數(shù)據(jù)接收緩存區(qū)之間的映射關(guān)系琅催，以及內(nèi)核中數(shù)據(jù)接收緩存區(qū)和接收進(jìn)程用戶空間地址的映射關(guān)系侠碧；

3. 發(fā)送方進(jìn)程通過系統(tǒng)調(diào)用 copy_from_user() 將數(shù)據(jù) copy 到內(nèi)核中的內(nèi)核緩存區(qū)弄兜，由于內(nèi)核緩存區(qū)和接收進(jìn)程的用戶空間存在內(nèi)存映射替饿，因此也就相當(dāng)于把數(shù)據(jù)發(fā)送到了接收進(jìn)程的用戶空間，這樣便完成了一次進(jìn)程間的通信瓤漏。

如下圖：

image

四、Binder 通信模型

介紹完 Binder IPC 的底層通信原理饥漫，接下來我們看看實(shí)現(xiàn)層面是如何設(shè)計(jì)的庸队。

一次完整的進(jìn)程間通信必然至少包含兩個(gè)進(jìn)程彻消，通常我們稱通信的雙方分別為客戶端進(jìn)程（Client）和服務(wù)端進(jìn)程（Server）宾尚，由于進(jìn)程隔離機(jī)制的存在御板，通信雙方必然需要借助 Binder 來實(shí)現(xiàn)怠肋。

4.1 Client/Server/ServiceManager/驅(qū)動(dòng)

前面我們介紹過笙各，Binder 是基于 C/S 架構(gòu)的杈抢。由一系列的組件組成春感，包括 Client鲫懒、Server窥岩、ServiceManager、Binder 驅(qū)動(dòng)朦乏。其中 Client呻疹、Server刽锤、Service Manager 運(yùn)行在用戶空間并思，Binder 驅(qū)動(dòng)運(yùn)行在內(nèi)核空間宋彼。其中 Service Manager 和 Binder 驅(qū)動(dòng)由系統(tǒng)提供输枯，而 Client桃熄、Server 由應(yīng)用程序來實(shí)現(xiàn)瞳收。Client螟深、Server 和 ServiceManager 均是通過系統(tǒng)調(diào)用 open界弧、mmap 和 ioctl 來訪問設(shè)備文件 /dev/binder，從而實(shí)現(xiàn)與 Binder 驅(qū)動(dòng)的交互來間接的實(shí)現(xiàn)跨進(jìn)程通信兑巾。

image

Client帅掘、Server修档、ServiceManager萍悴、Binder 驅(qū)動(dòng)這幾個(gè)組件在通信過程中扮演的角色就如同互聯(lián)網(wǎng)中服務(wù)器（Server）、客戶端（Client）撕予、DNS域名服務(wù)器（ServiceManager）以及路由器（Binder 驅(qū)動(dòng)）之前的關(guān)系蜈首。

通常我們訪問一個(gè)網(wǎng)頁的步驟是這樣的：首先在瀏覽器輸入一個(gè)地址吆寨，如 www.google.com 然后按下回車鍵啄清。但是并沒有辦法通過域名地址直接找到我們要訪問的服務(wù)器辣卒，因此需要首先訪問 DNS 域名服務(wù)器荣茫，域名服務(wù)器中保存了 www.google.com 對應(yīng)的 ip 地址 10.249.23.13啡莉，然后通過這個(gè) ip 地址才能放到到 www.google.com 對應(yīng)的服務(wù)器咧欣。

image

Android Binder 設(shè)計(jì)與實(shí)現(xiàn)一文中對 Client该押、Server蚕礼、ServiceManager、Binder 驅(qū)動(dòng)有很詳細(xì)的描述嗡午，以下是部分摘錄：

Binder 驅(qū)動(dòng)
Binder 驅(qū)動(dòng)就如同路由器一樣狸演，是整個(gè)通信的核心宵距；驅(qū)動(dòng)負(fù)責(zé)進(jìn)程之間 Binder 通信的建立满哪，Binder 在進(jìn)程之間的傳遞哨鸭，Binder 引用計(jì)數(shù)管理像鸡，數(shù)據(jù)包在進(jìn)程之間的傳遞和交互等一系列底層支持坟桅。

ServiceManager 與實(shí)名 Binder
ServiceManager 和 DNS 類似赖舟，作用是將字符形式的 Binder 名字轉(zhuǎn)化成 Client 中對該 Binder 的引用宾抓，使得 Client 能夠通過 Binder 的名字獲得對 Binder 實(shí)體的引用石洗。注冊了名字的 Binder 叫實(shí)名 Binder讲衫，就像網(wǎng)站一樣除了除了有 IP 地址意外還有自己的網(wǎng)址涉兽。Server 創(chuàng)建了 Binder枷畏，并為它起一個(gè)字符形式拥诡，可讀易記得名字渴肉，將這個(gè) Binder 實(shí)體連同名字一起以數(shù)據(jù)包的形式通過 Binder 驅(qū)動(dòng)發(fā)送給 ServiceManager 批狐，通知 ServiceManager 注冊一個(gè)名為“張三”的 Binder，它位于某個(gè) Server 中华弓。驅(qū)動(dòng)為這個(gè)穿越進(jìn)程邊界的 Binder 創(chuàng)建位于內(nèi)核中的實(shí)體節(jié)點(diǎn)以及 ServiceManager 對實(shí)體的引用寂屏，將名字以及新建的引用打包傳給 ServiceManager迁霎。ServiceManger 收到數(shù)據(jù)后從中取出名字和引用填入查找表。

細(xì)心的讀者可能會(huì)發(fā)現(xiàn)昌粤，ServierManager 是一個(gè)進(jìn)程涮坐，Server 是另一個(gè)進(jìn)程袱讹，Server 向 ServiceManager 中注冊 Binder 必然涉及到進(jìn)程間通信。當(dāng)前實(shí)現(xiàn)進(jìn)程間通信又要用到進(jìn)程間通信非区，這就好像蛋可以孵出雞的前提卻是要先找只雞下蛋征绸！Binder 的實(shí)現(xiàn)比較巧妙淆衷，就是預(yù)先創(chuàng)造一只雞來下蛋祝拯。ServiceManager 和其他進(jìn)程同樣采用 Bidner 通信蒲列，ServiceManager 是 Server 端康嘉，有自己的 Binder 實(shí)體籽前，其他進(jìn)程都是 Client亭珍，需要通過這個(gè) Binder 的引用來實(shí)現(xiàn) Binder 的注冊，查詢和獲取枝哄。ServiceManager 提供的 Binder 比較特殊肄梨，它沒有名字也不需要注冊。當(dāng)一個(gè)進(jìn)程使用 BINDER_SET_CONTEXT_MGR 命令將自己注冊成 ServiceManager 時(shí) Binder 驅(qū)動(dòng)會(huì)自動(dòng)為它創(chuàng)建 Binder 實(shí)體（這就是那只預(yù)先造好的那只雞）挠锥。其次這個(gè) Binder 實(shí)體的引用在所有 Client 中都固定為 0 而無需通過其它手段獲得众羡。也就是說，一個(gè) Server 想要向 ServiceManager 注冊自己的 Binder 就必須通過這個(gè) 0 號(hào)引用和 ServiceManager 的 Binder 通信。類比互聯(lián)網(wǎng)，0 號(hào)引用就好比是域名服務(wù)器的地址，你必須預(yù)先動(dòng)態(tài)或者手工配置好。要注意的是该肴，這里說的 Client 是相對于 ServiceManager 而言的涎嚼，一個(gè)進(jìn)程或者應(yīng)用程序可能是提供服務(wù)的 Server，但對于 ServiceManager 來說它仍然是個(gè) Client。

Client 獲得實(shí)名 Binder 的引用
Server 向 ServiceManager 中注冊了 Binder 以后， Client 就能通過名字獲得 Binder 的引用了尘颓。Client 也利用保留的 0 號(hào)引用向 ServiceManager 請求訪問某個(gè) Binder: 我申請?jiān)L問名字叫張三的 Binder 引用敛腌。ServiceManager 收到這個(gè)請求后從請求數(shù)據(jù)包中取出 Binder 名稱生棍，在查找表里找到對應(yīng)的條目，取出對應(yīng)的 Binder 引用作為回復(fù)發(fā)送給發(fā)起請求的 Client。從面向?qū)ο蟮慕嵌瓤聪敌撸琒erver 中的 Binder 實(shí)體現(xiàn)在有兩個(gè)引用：一個(gè)位于 ServiceManager 中杠人，一個(gè)位于發(fā)起請求的 Client 中学歧。如果接下來有更多的 Client 請求該 Binder横浑，系統(tǒng)中就會(huì)有更多的引用指向該 Binder 欺冀，就像 Java 中一個(gè)對象有多個(gè)引用一樣龙助。

4.2 Binder 通信過程

至此称勋，我們大致能總結(jié)出 Binder 通信過程：

1. 首先，一個(gè)進(jìn)程使用 BINDER_SET_CONTEXT_MGR 命令通過 Binder 驅(qū)動(dòng)將自己注冊成為 ServiceManager；

2. Server 通過驅(qū)動(dòng)向 ServiceManager 中注冊 Binder（Server 中的 Binder 實(shí)體）宠哄，表明可以對外提供服務(wù)。驅(qū)動(dòng)為這個(gè) Binder 創(chuàng)建位于內(nèi)核中的實(shí)體節(jié)點(diǎn)以及 ServiceManager 對實(shí)體的引用辛臊，將名字以及新建的引用打包傳給 ServiceManager负溪，ServiceManger 將其填入查找表侍咱。

3. Client 通過名字，在 Binder 驅(qū)動(dòng)的幫助下從 ServiceManager 中獲取到對 Binder 實(shí)體的引用，通過這個(gè)引用就能實(shí)現(xiàn)和 Server 進(jìn)程的通信寂玲。

我們看到整個(gè)通信過程都需要 Binder 驅(qū)動(dòng)的接入。下圖能更加直觀的展現(xiàn)整個(gè)通信過程(為了進(jìn)一步抽象通信過程以及呈現(xiàn)上的方便诸迟，下圖我們忽略了 Binder 實(shí)體及其引用的概念)：

image

4.3 Binder 通信中的代理模式

我們已經(jīng)解釋清楚 Client快耿、Server 借助 Binder 驅(qū)動(dòng)完成跨進(jìn)程通信的實(shí)現(xiàn)機(jī)制了，但是還有個(gè)問題會(huì)讓我們困惑。A 進(jìn)程想要 B 進(jìn)程中某個(gè)對象（object）是如何實(shí)現(xiàn)的呢惑折？畢竟它們分屬不同的進(jìn)程，A 進(jìn)程 沒法直接使用 B 進(jìn)程中的 object刨啸。

前面我們介紹過跨進(jìn)程通信的過程都有 Binder 驅(qū)動(dòng)的參與，因此在數(shù)據(jù)流經(jīng) Binder 驅(qū)動(dòng)的時(shí)候驅(qū)動(dòng)會(huì)對數(shù)據(jù)做一層轉(zhuǎn)換。當(dāng) A 進(jìn)程想要獲取 B 進(jìn)程中的 object 時(shí)磷醋，驅(qū)動(dòng)并不會(huì)真的把 object 返回給 A瑰抵，而是返回了一個(gè)跟 object 看起來一模一樣的代理對象 objectProxy渣磷，這個(gè) objectProxy 具有和 object 一摸一樣的方法，但是這些方法并沒有 B 進(jìn)程中 object 對象那些方法的能力官研，這些方法只需要把把請求參數(shù)交給驅(qū)動(dòng)即可。對于 A 進(jìn)程來說和直接調(diào)用 object 中的方法是一樣的浇垦。

當(dāng) Binder 驅(qū)動(dòng)接收到 A 進(jìn)程的消息后，發(fā)現(xiàn)這是個(gè) objectProxy 就去查詢自己維護(hù)的表單这溅，一查發(fā)現(xiàn)這是 B 進(jìn)程 object 的代理對象。于是就會(huì)去通知 B 進(jìn)程調(diào)用 object 的方法积锅，并要求 B 進(jìn)程把返回結(jié)果發(fā)給自己蝶缀。當(dāng)驅(qū)動(dòng)拿到 B 進(jìn)程的返回結(jié)果后就會(huì)轉(zhuǎn)發(fā)給 A 進(jìn)程坐搔，一次通信就完成了禽炬。

image

4.4 Binder 的完整定義

現(xiàn)在我們可以對 Binder 做個(gè)更加全面的定義了：

• 從進(jìn)程間通信的角度看，Binder 是一種進(jìn)程間通信的機(jī)制却嗡；

• 從 Server 進(jìn)程的角度看帝牡，Binder 指的是 Server 中的 Binder 實(shí)體對象个扰；

• 從 Client 進(jìn)程的角度看土榴，Binder 指的是對 Binder 代理對象撩银，是 Binder 實(shí)體對象的一個(gè)遠(yuǎn)程代理

• 從傳輸過程的角度看，Binder 是一個(gè)可以跨進(jìn)程傳輸?shù)膶ο蠡防穑籅inder 驅(qū)動(dòng)會(huì)對這個(gè)跨越進(jìn)程邊界的對象對一點(diǎn)點(diǎn)特殊處理蔫耽，自動(dòng)完成代理對象和本地對象之間的轉(zhuǎn)換。

五. 手動(dòng)編碼實(shí)現(xiàn)跨進(jìn)程調(diào)用

通常我們在做開發(fā)時(shí)琼开，實(shí)現(xiàn)進(jìn)程間通信用的最多的就是 AIDL飞主。當(dāng)我們定義好 AIDL 文件穆律，在編譯時(shí)編譯器會(huì)幫我們生成代碼實(shí)現(xiàn) IPC 通信洛口。借助 AIDL 編譯以后的代碼能幫助我們進(jìn)一步理解 Binder IPC 的通信原理。

但是無論是從可讀性還是可理解性上來看伤柄，編譯器生成的代碼對開發(fā)者并不友好。比如一個(gè) BookManager.aidl 文件對應(yīng)會(huì)生成一個(gè) BookManager.java 文件锐秦，這個(gè) java 文件包含了一個(gè) BookManager 接口料身、一個(gè) Stub 靜態(tài)的抽象類和一個(gè) Proxy 靜態(tài)類令蛉。Proxy 是 Stub 的靜態(tài)內(nèi)部類庸追，Stub 又是 BookManager 的靜態(tài)內(nèi)部類车伞，這就造成了可讀性和可理解性的問題。

Android 之所以這樣設(shè)計(jì)其實(shí)是有道理的奶赠，因?yàn)楫?dāng)有多個(gè) AIDL 文件的時(shí)候把 BookManager蜡励、Stub蚓土、Proxy 放在同一個(gè)文件里能有效避免 Stub 和 Proxy 重名的問題剃毒。

因此便于大家理解齿诞，下面我們來手動(dòng)編寫代碼來實(shí)現(xiàn)跨進(jìn)程調(diào)用踩叭。

5.1 各 Java 類職責(zé)描述

在正式編碼實(shí)現(xiàn)跨進(jìn)程調(diào)用之前脚囊，先介紹下實(shí)現(xiàn)過程中用到的一些類互妓。了解了這些類的職責(zé)，有助于我們更好的理解和實(shí)現(xiàn)跨進(jìn)程通信。

• IBinder : IBinder 是一個(gè)接口，代表了一種跨進(jìn)程通信的能力焦影。只要實(shí)現(xiàn)了這個(gè)借口，這個(gè)對象就能跨進(jìn)程傳輸。

• IInterface : IInterface 代表的就是 Server 進(jìn)程對象具備什么樣的能力（能提供哪些方法译断，其實(shí)對應(yīng)的就是 AIDL 文件中定義的接口）

• Binder : Java 層的 Binder 類理澎，代表的其實(shí)就是 Binder 本地對象烁设。BinderProxy 類是 Binder 類的一個(gè)內(nèi)部類，它代表遠(yuǎn)程進(jìn)程的 Binder 對象的本地代理钓试；這兩個(gè)類都繼承自 IBinder, 因而都具有跨進(jìn)程傳輸?shù)哪芰ψ昂冢粚?shí)際上，在跨越進(jìn)程的時(shí)候亚侠，Binder 驅(qū)動(dòng)會(huì)自動(dòng)完成這兩個(gè)對象的轉(zhuǎn)換曹体。

• Stub : AIDL 的時(shí)候，編譯工具會(huì)給我們生成一個(gè)名為 Stub 的靜態(tài)內(nèi)部類硝烂；這個(gè)類繼承了 Binder, 說明它是一個(gè) Binder 本地對象箕别，它實(shí)現(xiàn)了 IInterface 接口，表明它具有 Server 承諾給 Client 的能力滞谢；Stub 是一個(gè)抽象類串稀，具體的 IInterface 的相關(guān)實(shí)現(xiàn)需要開發(fā)者自己實(shí)現(xiàn)。

5.2 實(shí)現(xiàn)過程講解

一次跨進(jìn)程通信必然會(huì)涉及到兩個(gè)進(jìn)程狮杨，在這個(gè)例子中 RemoteService 作為服務(wù)端進(jìn)程母截，提供服務(wù)；ClientActivity 作為客戶端進(jìn)程橄教，使用 RemoteService 提供的服務(wù)清寇。如下圖：

image

那么服務(wù)端進(jìn)程具備什么樣的能力？能為客戶端提供什么樣的服務(wù)呢护蝶？還記得我們前面介紹過的 IInterface 嗎华烟，它代表的就是服務(wù)端進(jìn)程具體什么樣的能力。因此我們需要定義一個(gè) BookManager 接口持灰，BookManager 繼承自 IIterface盔夜，表明服務(wù)端具備什么樣的能力。

/**
 * 這個(gè)類用來定義服務(wù)端 RemoteService 具備什么樣的能力
 */
public interface BookManager extends IInterface {

    void addBook(Book book) throws RemoteException;
}

只定義服務(wù)端具備什么要的能力是不夠的堤魁，既然是跨進(jìn)程調(diào)用喂链，那么接下來我們得實(shí)現(xiàn)一個(gè)跨進(jìn)程調(diào)用對象 Stub。Stub 繼承 Binder, 說明它是一個(gè) Binder 本地對象妥泉；實(shí)現(xiàn) IInterface 接口椭微，表明具有 Server 承諾給 Client 的能力；Stub 是一個(gè)抽象類盲链，具體的 IInterface 的相關(guān)實(shí)現(xiàn)需要調(diào)用方自己實(shí)現(xiàn)赏表。

public abstract class Stub extends Binder implements BookManager {

    ...

    public static BookManager asInterface(IBinder binder) {
        if (binder == null)
            return null;
        IInterface iin = binder.queryLocalInterface(DESCRIPTOR);
        if (iin != null && iin instanceof BookManager)
            return (BookManager) iin;
        return new Proxy(binder);
    }

    ...

    @Override
    protected boolean onTransact(int code, Parcel data, Parcel reply, int flags) throws RemoteException {
        switch (code) {

            case INTERFACE_TRANSACTION:
                reply.writeString(DESCRIPTOR);
                return true;

            case TRANSAVTION_addBook:
                data.enforceInterface(DESCRIPTOR);
                Book arg0 = null;
                if (data.readInt() != 0) {
                    arg0 = Book.CREATOR.createFromParcel(data);
                }
                this.addBook(arg0);
                reply.writeNoException();
                return true;

        }
        return super.onTransact(code, data, reply, flags);
    }

    ...
}

Stub 類中我們重點(diǎn)介紹下 asInterface 和 onTransact检诗。

先說說 asInterface，當(dāng) Client 端在創(chuàng)建和服務(wù)端的連接瓢剿，調(diào)用 bindService 時(shí)需要?jiǎng)?chuàng)建一個(gè) ServiceConnection 對象作為入?yún)⒎昊拧Ｔ?ServiceConnection 的回調(diào)方法 onServiceConnected 中 會(huì)通過這個(gè) asInterface(IBinder binder) 拿到 BookManager 對象，這個(gè) IBinder 類型的入?yún)?binder 是驅(qū)動(dòng)傳給我們的间狂，正如你在代碼中看到的一樣攻泼，方法中會(huì)去調(diào)用 binder.queryLocalInterface() 去查找 Binder 本地對象，如果找到了就說明 Client 和 Server 在同一進(jìn)程鉴象，那么這個(gè) binder 本身就是 Binder 本地對象忙菠，可以直接使用。否則說明是 binder 是個(gè)遠(yuǎn)程對象纺弊，也就是 BinderProxy牛欢。因此需要我們創(chuàng)建一個(gè)代理對象 Proxy，通過這個(gè)代理對象來是實(shí)現(xiàn)遠(yuǎn)程訪問淆游。

接下來我們就要實(shí)現(xiàn)這個(gè)代理類 Proxy 了傍睹，既然是代理類自然需要實(shí)現(xiàn) BookManager 接口。

public class Proxy implements BookManager {

    ...

    public Proxy(IBinder remote) {
        this.remote = remote;
    }

    @Override
    public void addBook(Book book) throws RemoteException {

        Parcel data = Parcel.obtain();
        Parcel replay = Parcel.obtain();
        try {
            data.writeInterfaceToken(DESCRIPTOR);
            if (book != null) {
                data.writeInt(1);
                book.writeToParcel(data, 0);
            } else {
                data.writeInt(0);
            }
            remote.transact(Stub.TRANSAVTION_addBook, data, replay, 0);
            replay.readException();
        } finally {
            replay.recycle();
            data.recycle();
        }
    }

    ...
}

我們看看 addBook() 的實(shí)現(xiàn)犹菱；在 Stub 類中拾稳，addBook(Book book) 是一個(gè)抽象方法，Client 端需要繼承并實(shí)現(xiàn)它腊脱。

• 如果 Client 和 Server 在同一個(gè)進(jìn)程访得，那么直接就是調(diào)用這個(gè)方法。

• 如果是遠(yuǎn)程調(diào)用陕凹，Client 想要調(diào)用 Server 的方法就需要通過 Binder 代理來完成悍抑，也就是上面的 Proxy。

在 Proxy 中的 addBook() 方法中首先通過 Parcel 將數(shù)據(jù)序列化杜耙，然后調(diào)用 remote.transact()搜骡。正如前文所述 Proxy 是在 Stub 的 asInterface 中創(chuàng)建，能走到創(chuàng)建 Proxy 這一步就說明 Proxy 構(gòu)造函數(shù)的入?yún)⑹?BinderProxy泥技，即這里的 remote 是個(gè) BinderProxy 對象浆兰。

最終通過一系列的函數(shù)調(diào)用磕仅，Client 進(jìn)程通過系統(tǒng)調(diào)用陷入內(nèi)核態(tài)珊豹，Client 進(jìn)程中執(zhí)行 addBook() 的線程掛起等待返回；驅(qū)動(dòng)完成一系列的操作之后喚醒 Server 進(jìn)程榕订，調(diào)用 Server 進(jìn)程本地對象的 onTransact()店茶。最終又走到了 Stub 中的 onTransact() 中，onTransact() 根據(jù)函數(shù)編號(hào)調(diào)用相關(guān)函數(shù)（在 Stub 類中為 BookManager 接口中的每個(gè)函數(shù)中定義了一個(gè)編號(hào)劫恒，只不過上面的源碼中我們簡化掉了贩幻；在跨進(jìn)程調(diào)用的時(shí)候轿腺，不會(huì)傳遞函數(shù)而是傳遞編號(hào)來指明要調(diào)用哪個(gè)函數(shù)）；我們這個(gè)例子里面丛楚，調(diào)用了 Binder 本地對象的 addBook() 并將結(jié)果返回給驅(qū)動(dòng)族壳，驅(qū)動(dòng)喚醒 Client 進(jìn)程里剛剛掛起的線程并將結(jié)果返回。

這樣一次跨進(jìn)程調(diào)用就完成了趣些。

完整的代碼：https://github.com/BaronZ88/HelloBinder

最后建議大家在不借助 AIDL 的情況下手寫實(shí)現(xiàn) Client 和 Server 進(jìn)程的通信仿荆，加深對 Binder 通信過程的理解。

受個(gè)人能力水平限制坏平，文章中難免會(huì)有錯(cuò)誤拢操。如果大家發(fā)現(xiàn)文章不足之處，歡迎與我溝通交流舶替。