最近在學(xué)習 Binder 機制，在網(wǎng)上查閱了大量的資料，也看了老羅的 Binder 系列的博客和 Innost 的深入理解 Binder 系列的博客，都是從底層開(kāi)始講的，全是 C 代碼，雖然之前學(xué)過(guò) C 和 C++，然而各種函數之間花式跳轉，看的我都懷疑人生。毫不夸張的講每看一遍都是新的內容，跟沒(méi)看過(guò)一樣。后來(lái)又看到了 Gityuan 的博客看到了一些圖解仿佛發(fā)現了新大陸。

Binder 是 Android 系統中進(jìn)程間通訊（IPC）的一種方式，也是 Android 系統中最重要的特性之一。Android 中的四大組件 Activity，Service，Broadcast，ContentProvider，不同的 App 等都運行在不同的進(jìn)程中，它是這些進(jìn)程間通訊的橋梁。正如其名“粘合劑”一樣，它把系統中各個(gè)組件粘合到了一起，是各個(gè)組件的橋梁。

理解 Binder 對于理解整個(gè) Android 系統有著(zhù)非常重要的作用，如果對 Binder 不了解，就很難對 Android 系統機制有更深入的理解。

Binder 通信采用 C/S 架構，從組件視角來(lái)說(shuō)，包含 Client、 Server、 ServiceManager 以及 Binder 驅動(dòng)，其中 ServiceManager 用于管理系統中的各種服務(wù)。

Binder 在 framework 層進(jìn)行了封裝，通過(guò) JNI 技術(shù)調用 Native（C/C++）層的 Binder 架構。

Binder 在 Native 層以 ioctl 的方式與 Binder 驅動(dòng)通訊。

1. 首先需要注冊服務(wù)端，只有注冊了服務(wù)端，客戶(hù)端才有通訊的目標，服務(wù)端通過(guò) ServiceManager 注冊服務(wù)，注冊的過(guò)程就是向 Binder 驅動(dòng)的全局鏈表 binder_procs 中插入服務(wù)端的信息（binder_proc 結構體，每個(gè) binder_proc 結構體中都有 todo 任務(wù)隊列），然后向 ServiceManager 的 svcinfo 列表中緩存一下注冊的服務(wù)。

2. 有了服務(wù)端，客戶(hù)端就可以跟服務(wù)端通訊了，通訊之前需要先獲取到服務(wù)，拿到服務(wù)的代理，也可以理解為引用。比如下面的代碼：

//獲取WindowManager服務(wù)引用WindowManager wm = (WindowManager)getSystemService(getApplication().WINDOW_SERVICE);

獲取服務(wù)端的方式就是通過(guò) ServiceManager 向 svcinfo 列表中查詢(xún)一下返回服務(wù)端的代理，svcinfo 列表就是所有已注冊服務(wù)的通訊錄，保存了所有注冊的服務(wù)信息。

3. 有了服務(wù)端的引用我們就可以向服務(wù)端發(fā)送請求了，通過(guò) BinderProxy 將我們的請求參數發(fā)送給 ServiceManager，通過(guò)共享內存的方式使用內核方法 copy_from_user() 將我們的參數先拷貝到內核空間，這時(shí)我們的客戶(hù)端進(jìn)入等待狀態(tài)，然后 Binder 驅動(dòng)向服務(wù)端的 todo 隊列里面插入一條事務(wù)，執行完之后把執行結果通過(guò) copy_to_user() 將內核的結果拷貝到用戶(hù)空間（這里只是執行了拷貝命令，并沒(méi)有拷貝數據，binder只進(jìn)行一次拷貝），喚醒等待的客戶(hù)端并把結果響應回來(lái)，這樣就完成了一次通訊。

怎么樣是不是很簡(jiǎn)單，以上就是 Binder 機制的主要通訊方式，下面我們來(lái)看看具體實(shí)現。

我們先來(lái)了解下用戶(hù)空間與內核空間是怎么交互的。

先了解一些概念

用戶(hù)空間/內核空間

詳細解釋可以參考 Kernel Space Definition； 簡(jiǎn)單理解如下：

Kernel space 是 Linux 內核的運行空間，User space 是用戶(hù)程序的運行空間。為了安全，它們是隔離的，即使用戶(hù)的程序崩潰了，內核也不受影響。

Kernel space 可以執行任意命令，調用系統的一切資源； 

User space 只能執行簡(jiǎn)單的運算，不能直接調用系統資源，必須通過(guò)系統接口（又稱(chēng) system call），才能向內核發(fā)出指令。

系統調用/內核態(tài)/用戶(hù)態(tài)

雖然從邏輯上抽離出用戶(hù)空間和內核空間；但是不可避免的的是，總有那么一些用戶(hù)空間需要訪(fǎng)問(wèn)內核的資源；比如應用程序訪(fǎng)問(wèn)文件，網(wǎng)絡(luò )是很常見(jiàn)的事情，怎么辦呢？

Kernel space can be accessed by user processes>

用戶(hù)空間訪(fǎng)問(wèn)內核空間的唯一方式就是系統調用；通過(guò)這個(gè)統一入口接口，所有的資源訪(fǎng)問(wèn)都是在內核的控制下執行，以免導致對用戶(hù)程序對系統資源的越權訪(fǎng)問(wèn)，從而保障了系統的安全和穩定。用戶(hù)軟件良莠不齊，要是它們亂搞把系統玩壞了怎么辦？因此對于某些特權操作必須交給安全可靠的內核來(lái)執行。

當一個(gè)任務(wù)（進(jìn)程）執行系統調用而陷入內核代碼中執行時(shí)，我們就稱(chēng)進(jìn)程處于內核運行態(tài)（或簡(jiǎn)稱(chēng)為內核態(tài)）此時(shí)處理器處于特權級最高的（0級）內核代碼中執行。當進(jìn)程在執行用戶(hù)自己的代碼時(shí)，則稱(chēng)其處于用戶(hù)運行態(tài)（用戶(hù)態(tài)）。即此時(shí)處理器在特權級最低的（3級）用戶(hù)代碼中運行。處理器在特權等級高的時(shí)候才能執行那些特權CPU指令。

內核模塊/驅動(dòng)

通過(guò)系統調用，用戶(hù)空間可以訪(fǎng)問(wèn)內核空間，那么如果一個(gè)用戶(hù)空間想與另外一個(gè)用戶(hù)空間進(jìn)行通信怎么辦呢？

很自然想到的是讓操作系統內核添加支持；傳統的 Linux 通信機制，比如 Socket，管道等都是內核支持的；但是 Binder 并不是 Linux 內核的一部分，它是怎么做到訪(fǎng)問(wèn)內核空間的呢？ 

Linux 的動(dòng)態(tài)可加載內核模塊（Loadable Kernel Module，LKM）機制解決了這個(gè)問(wèn)題；模塊是具有獨立功能的程序，它可以被單獨編譯，但不能獨立運行。它在運行時(shí)被鏈接到內核作為內核的一部分在內核空間運行。這樣，Android系統可以通過(guò)添加一個(gè)內核模塊運行在內核空間，用戶(hù)進(jìn)程之間的通過(guò)這個(gè)模塊作為橋梁，就可以完成通信了。

在 Android 系統中，這個(gè)運行在內核空間的，負責各個(gè)用戶(hù)進(jìn)程通過(guò) Binder 通信的內核模塊叫做 Binder 驅動(dòng);

驅動(dòng)程序一般指的是設備驅動(dòng)程序（Device Driver），是一種可以使計算機和設備通信的特殊程序。相當于硬件的接口，操作系統只有通過(guò)這個(gè)接口，才能控制硬件設備的工作；

驅動(dòng)就是操作硬件的接口，為了支持Binder通信過(guò)程，Binder 使用了一種“硬件”，因此這個(gè)模塊被稱(chēng)之為驅動(dòng)。

熟悉了上面這些概念，我們再來(lái)看下上面的圖，

用戶(hù)空間中 binder_open(), binder_mmap(), binder_ioctl() 這些方法通過(guò) system call來(lái)調用內核空間 Binder 驅動(dòng)中的方法。

內核空間與用戶(hù)空間共享內存通過(guò) copy_from_user(), copy_to_user() 內核方法來(lái)完成用戶(hù)空間與內核空間內存的數據傳輸。Binder驅動(dòng)中有一個(gè)全局的 binder_procs 鏈表保存了服務(wù)端的進(jìn)程信息。

4. Binder 進(jìn)程與線(xiàn)程

對于底層Binder驅動(dòng)，通過(guò) binder_procs 鏈表記錄所有創(chuàng )建的 binder_proc 結構體，binder 驅動(dòng)層的每一個(gè) binder_proc 結構體都與用戶(hù)空間的一個(gè)用于 binder 通信的進(jìn)程一一對應，且每個(gè)進(jìn)程有且只有一個(gè) ProcessState 對象，這是通過(guò)單例模式來(lái)保證的。

在每個(gè)進(jìn)程中可以有很多個(gè)線(xiàn)程，每個(gè)線(xiàn)程對應一個(gè) IPCThreadState 對象，IPCThreadState 對象也是單例模式，即一個(gè)線(xiàn)程對應一個(gè) IPCThreadState 對象，在 Binder 驅動(dòng)層也有與之相對應的結構，那就是 Binder_thread 結構體。在 binder_proc 結構體中通過(guò)成員變量 rb_root threads，來(lái)記錄當前進(jìn)程內所有的 binder_thread。

Binder 線(xiàn)程池：

每個(gè) Server 進(jìn)程在啟動(dòng)時(shí)創(chuàng )建一個(gè) binder 線(xiàn)程池，并向其中注冊一個(gè) Binder 線(xiàn)程；之后 Server 進(jìn)程也可以向 binder 線(xiàn)程池注冊新的線(xiàn)程，或者 Binder 驅動(dòng)在探測到?jīng)]有空閑 binder 線(xiàn)程時(shí)主動(dòng)向 Server 進(jìn)程注冊新的的 binder 線(xiàn)程。

對于一個(gè) Server 進(jìn)程有一個(gè)最大 Binder 線(xiàn)程數限制，默認為16個(gè) binder 線(xiàn)程，例如 Android 的 system_server 進(jìn)程就存在16個(gè)線(xiàn)程。對于所有 Client 端進(jìn)程的 binder 請求都是交由 Server 端進(jìn)程的 binder 線(xiàn)程來(lái)處理的。

5. ServiceManager 啟動(dòng)

了解了 Binder 驅動(dòng)，怎么與 Binder 驅動(dòng)進(jìn)行通訊呢？那就是通過(guò) ServiceManager，好多文章稱(chēng) ServiceManager 是 Binder 驅動(dòng)的守護進(jìn)程，大管家，其實(shí) ServiceManager 的作用很簡(jiǎn)單就是提供了查詢(xún)服務(wù)和注冊服務(wù)的功能。下面我們來(lái)看一下 ServiceManager 啟動(dòng)的過(guò)程。

ServiceManager 分為 framework 層和 native 層，framework 層只是對 native 層進(jìn)行了封裝方便調用，圖上展示的是 native 層的 ServiceManager 啟動(dòng)過(guò)程。

ServiceManager 的啟動(dòng)是系統在開(kāi)機時(shí)，init 進(jìn)程解析 init.rc 文件調用 service_manager.c 中的 main() 方法入口啟動(dòng)的。 native 層有一個(gè) binder.c 封裝了一些與 Binder 驅動(dòng)交互的方法。

ServiceManager 的啟動(dòng)分為三步，首先打開(kāi)驅動(dòng)創(chuàng )建全局鏈表 binder_procs，然后將自己當前進(jìn)程信息保存到 binder_procs 鏈表，最后開(kāi)啟 loop 不斷的處理共享內存中的數據，并處理 BR_xxx 命令（ioctl 的命令，BR 可以理解為 binder reply 驅動(dòng)處理完的響應）。

6. ServiceManager 注冊服務(wù)

注冊 MediaPlayerService 服務(wù)端，我們通過(guò) ServiceManager 的 addService() 方法來(lái)注冊服務(wù)。

首先 ServiceManager 向 Binder 驅動(dòng)發(fā)送 BC_TRANSACTION 命令（ioctl 的命令，BC 可以理解為 binder client 客戶(hù)端發(fā)過(guò)來(lái)的請求命令）攜帶 ADD_SERVICE_TRANSACTION 命令，同時(shí)注冊服務(wù)的線(xiàn)程進(jìn)入等待狀態(tài) waitForResponse()。 Binder 驅動(dòng)收到請求命令向 ServiceManager 的 todo 隊列里面添加一條注冊服務(wù)的事務(wù)。事務(wù)的任務(wù)就是創(chuàng )建服務(wù)端進(jìn)程 binder_node 信息并插入到 binder_procs 鏈表中。

事務(wù)處理完之后發(fā)送 BR_TRANSACTION 命令，ServiceManager 收到命令后向 svcinfo 列表中添加已經(jīng)注冊的服務(wù)。最后發(fā)送 BR_REPLY 命令喚醒等待的線(xiàn)程，通知注冊成功。

7. ServiceManager 獲取服務(wù)

獲取服務(wù)的過(guò)程與注冊類(lèi)似，相反的過(guò)程。通過(guò) ServiceManager 的 getService() 方法來(lái)注冊服務(wù)。

首先 ServiceManager 向 Binder 驅動(dòng)發(fā)送 BC_TRANSACTION 命令攜帶 CHECK_SERVICE_TRANSACTION 命令，同時(shí)獲取服務(wù)的線(xiàn)程進(jìn)入等待狀態(tài) waitForResponse()。

Binder 驅動(dòng)收到請求命令向 ServiceManager 的發(fā)送 BC_TRANSACTION 查詢(xún)已注冊的服務(wù)，查詢(xún)到直接響應 BR_REPLY 喚醒等待的線(xiàn)程。若查詢(xún)不到將與 binder_procs 鏈表中的服務(wù)進(jìn)行一次通訊再響應。

8. 進(jìn)行一次完整通訊

我們在使用 Binder 時(shí)基本都是調用 framework 層封裝好的方法，AIDL 就是 framework 層提供的傻瓜式是使用方式。假設服務(wù)已經(jīng)注冊完，我們來(lái)看看客戶(hù)端怎么執行服務(wù)端的方法。

首先我們通過(guò) ServiceManager 獲取到服務(wù)端的 BinderProxy 代理對象，通過(guò)調用 BinderProxy 將參數，方法標識（例如：TRANSACTION_test，AIDL中自動(dòng)生成）傳給 ServiceManager，同時(shí)客戶(hù)端線(xiàn)程進(jìn)入等待狀態(tài)。

ServiceManager 將用戶(hù)空間的參數等請求數據復制到內核空間，并向服務(wù)端插入一條執行執行方法的事務(wù)。事務(wù)執行完通知 ServiceManager 將執行結果從內核空間復制到用戶(hù)空間，并喚醒等待的線(xiàn)程，響應結果，通訊結束。

總結

好了，這里只是從實(shí)現邏輯上簡(jiǎn)單介紹了下 Binder 機制的工作原理，想要深入理解 Binder 機制，還得自己下功夫，看源碼，盡管這個(gè)過(guò)程很痛苦。一遍看不懂就再來(lái)一遍，說(shuō)實(shí)話(huà)本人理解能力比較差，跟著(zhù)博客思路看了不下十遍。努力總會(huì )有收獲，好好欣賞 native 層各方法之間花式跳轉的魅力吧。最后你將發(fā)現新世界的大門(mén)在向你敞開(kāi)。