日韩国产精品99成人不卡在线无毒|狠狠躁夜夜爽一级二级精品|亚洲日日噜噜孕妇中文字幕|日韩久草中文三级片

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

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

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

Binder 通信采用 C/S 架構(gòu)，從組件視角來說，包含 Client、 Server、 ServiceManager 以及 Binder 驅(qū)動，其中 ServiceManager 用于管理系統(tǒng)中的各種服務。

Binder 在 framework 層進行了封裝，通過 JNI 技術(shù)調(diào)用 Native（C/C++）層的 Binder 架構(gòu)。

Binder 在 Native 層以 ioctl 的方式與 Binder 驅(qū)動通訊。

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

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

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

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

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

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

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

先了解一些概念

用戶空間/內(nèi)核空間

詳細解釋可以參考 Kernel Space Definition； 簡單理解如下：

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

Kernel space 可以執(zhí)行任意命令，調(diào)用系統(tǒng)的一切資源； 

User space 只能執(zhí)行簡單的運算，不能直接調(diào)用系統(tǒng)資源，必須通過系統(tǒng)接口（又稱 system call），才能向內(nèi)核發(fā)出指令。

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

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

Kernel space can be accessed by user processes>

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

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

內(nèi)核模塊/驅(qū)動

通過系統(tǒng)調(diào)用，用戶空間可以訪問內(nèi)核空間，那么如果一個用戶空間想與另外一個用戶空間進行通信怎么辦呢？

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

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

在 Android 系統(tǒng)中，這個運行在內(nèi)核空間的，負責各個用戶進程通過 Binder 通信的內(nèi)核模塊叫做 Binder 驅(qū)動;

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

驅(qū)動就是操作硬件的接口，為了支持Binder通信過程，Binder 使用了一種“硬件”，因此這個模塊被稱之為驅(qū)動。

熟悉了上面這些概念，我們再來看下上面的圖，

用戶空間中 binder_open(), binder_mmap(), binder_ioctl() 這些方法通過 system call來調(diào)用內(nèi)核空間 Binder 驅(qū)動中的方法。

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

4. Binder 進程與線程

對于底層Binder驅(qū)動，通過 binder_procs 鏈表記錄所有創(chuàng)建的 binder_proc 結(jié)構(gòu)體，binder 驅(qū)動層的每一個 binder_proc 結(jié)構(gòu)體都與用戶空間的一個用于 binder 通信的進程一一對應，且每個進程有且只有一個 ProcessState 對象，這是通過單例模式來保證的。

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

Binder 線程池：

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

對于一個 Server 進程有一個最大 Binder 線程數(shù)限制，默認為16個 binder 線程，例如 Android 的 system_server 進程就存在16個線程。對于所有 Client 端進程的 binder 請求都是交由 Server 端進程的 binder 線程來處理的。

5. ServiceManager 啟動

了解了 Binder 驅(qū)動，怎么與 Binder 驅(qū)動進行通訊呢？那就是通過 ServiceManager，好多文章稱 ServiceManager 是 Binder 驅(qū)動的守護進程，大管家，其實 ServiceManager 的作用很簡單就是提供了查詢服務和注冊服務的功能。下面我們來看一下 ServiceManager 啟動的過程。

ServiceManager 分為 framework 層和 native 層，framework 層只是對 native 層進行了封裝方便調(diào)用，圖上展示的是 native 層的 ServiceManager 啟動過程。

ServiceManager 的啟動是系統(tǒng)在開機時，init 進程解析 init.rc 文件調(diào)用 service_manager.c 中的 main() 方法入口啟動的。 native 層有一個 binder.c 封裝了一些與 Binder 驅(qū)動交互的方法。

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

6. ServiceManager 注冊服務

注冊 MediaPlayerService 服務端，我們通過 ServiceManager 的 addService() 方法來注冊服務。

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

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

7. ServiceManager 獲取服務

獲取服務的過程與注冊類似，相反的過程。通過 ServiceManager 的 getService() 方法來注冊服務。

首先 ServiceManager 向 Binder 驅(qū)動發(fā)送 BC_TRANSACTION 命令攜帶 CHECK_SERVICE_TRANSACTION 命令，同時獲取服務的線程進入等待狀態(tài) waitForResponse()。

Binder 驅(qū)動收到請求命令向 ServiceManager 的發(fā)送 BC_TRANSACTION 查詢已注冊的服務，查詢到直接響應 BR_REPLY 喚醒等待的線程。若查詢不到將與 binder_procs 鏈表中的服務進行一次通訊再響應。

8. 進行一次完整通訊

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

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

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

總結(jié)

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