Android Binder實現淺析-Binder驅動

簡介

Android是如何實現跨進程通訊的，你們熟悉的Binder是什麼，怎麼設計的，進程間的數據如何發送接收的。本文將以及解析，並對Binder驅動實現、Native層實現、Java層實現三塊作一個總結分析。

Binder學習思路

1. Binder與傳統IPC的區別
2. Binder驅動的內部設計、數據結構
3. Binder驅動與應用程序進程（C/S）之間的通訊過程
4. Android應用程序經過Binder驅動進行通訊的流程
5. Android開發人員如何使用Binder通訊（AIDL、Java層架構）

基礎知識理解

1. Unix內核和應用程序進程所使用的物理內存是分開的，內核使用1G的物理內存，其餘應用程序有各自的3G物理內存（32位操做系統）
2. 由於內核和應用程序的物理內存是分開的，因此二者之間傳遞數據須要進行數據拷貝
3. 內存映射（mmap）能夠將兩個虛擬內存地址空間（不一樣進程）映射到同一物理內存段上。實現多進程（或者內核與進程）之間公用一塊內存，減小數據拷貝次數
4. Unix驅動程序是一個運行在內核態（使用內核對應的物理內存）的程序
5. Binder也是一種IPC的實現方式，其與傳統的Unix IPC有必定的差異（使用了mmap）

理解Binder驅動的存在

由於要實現跨進程通訊，那麼，數據是如何傳輸的，怎麼組織的。兩個進程之間是如何知道對方的標識（引用）的，這一系列問題，都由Binder驅動解決，每一個進程須要爲其餘進程提供服務（API調用），都須要向Binder驅動註冊，其餘進程才能知道本身的數據傳向哪裏。這裏你們先忽略ServiceManager的特殊身份。只討論Binder驅動的以爲定位便可。

這樣看來，其實Binder驅動就是一個多個進程之間的中樞神經，支撐起了Android中進程間通訊，它內部的設計，與應用程序進程中的業務，不存在任何耦合關係，只負責實現進程間數據通訊。能夠用以下圖來理解Binder驅動與應用程序進程之間的關係。

固然，Android裏的Binder架構應該還有ServiceManager這個系統服務。

ServiceManager的存在

ServiceManager下文簡稱SM，是一個Android操做系統提供的一個系統進程。那麼爲何要單獨提他呢，由於這個進程裏，記錄了全部Binder實體（提供服務的Binder實現對象）的信息。

也就是說，SM是用來給應用程序查找其餘應用程序的數據中心與校驗中心，保障進程間通訊的安全新，合法性。

SM是系統服務，在系統啓動後，SM便啓動，並執行如下事情：

1. 打開Binder驅動
2. 將本身註冊爲Binder驅動的大管家（其餘進程根據引用編號0能夠找到SM對應的Binder實體）
3. 進入循環，不斷從Binder驅動中讀取消息（無消息被阻塞）
4. 讀取到消息以後處理消息
5. 不斷循環，永不退出

SM處理的消息類型有：

1. 註冊Binder實體對象的
2. 查詢Binder實體對象，以引用編號的形式放回給查詢進程

註冊Binder實體信息到SM的時候，請求數據中須要寫到Binder實體的描述信息，以後進行查詢的時候就是根據描述信息來獲取到對應的Binder應用編號。

到這裏，咱們能夠看出，其實整個Binder架構就是一個Client，Server，DNS的結構，固然Binder驅動就扮演了一個路由器的角色。

這個結構的前提，就是DNS須要提早註冊。也就是說SM進程須要第一個註冊到Binder驅動中，並且，Client和Server都知道SM的引用編號（0），可以直接經過SM獲取其餘進程提供的Binder引用編號

Binder驅動啓動過程

打開

1. 每一個須要經過Binder通訊的進程都須要打開/dev/binder驅動一次（至多一次）
2. 打開Binder驅動以後，內核會調用驅動程序的binder_open方法，該方法內部將會建立binder_proc結構體，內存存儲了進程信息以及UID信息。

內存映射

1. 使用mmap對/dev/binder進行內存映射操做
2. 在mmap調用以後，內核會會調用驅動程序的binder_mmap方法，該方法內部會爲進程建立binder_buffer結構體，也就是爲進程建立緩衝區，用於接收數據。而且這塊內和緩衝區對應有兩個虛擬內存地址區間，一個是內核的虛擬空間，一個是進程用戶空間的虛擬空間。此塊緩衝區是一個只讀的區域，防止用戶空間對其進行修改。

動做執行者

對於應用程序進程來講，打開驅動和內存映射動做由Native類ProcessState完成，該類爲單利，在構造方法中進行，先打開，再執行內存映射。

Binder與共享內存之間的區別

爲何與共享內存進行對比（性能），是由於共享內存管是unix中最快的一種IPC機制。

共享內存爲何快，是由於共享內存至關因而將兩個進程的虛擬地址空間指向了一塊物理內存，兩個進程對該內存區域的修改，可以直接反應到對方進程中，也就是不須要對數據進行拷貝。

前面說到，Binder是經過mmap來實現的，理論上，mmap也可讓兩個進程映射到同一段物理內存區域（文件）上。可是Binder沒有這樣實現，若是這樣的話，和共享內存就同樣了。那Binder又是如何實現的呢。

首先，Binder有驅動程序，全部數據傳輸和接收，都是經過Binder驅動來操做的。這就帶來一個問題，Binder驅動是運行在內核態的，那麼數據在使用Binder驅動傳輸時，是須要在內核內存空間與用戶內存空間進行拷貝操做的。

試想下，A進程與B進程進行通訊，A進程給B進程發送數據data，按照上面的分析，數據data須要先從A進程的用戶空間拷貝到Binder驅動的內核空間，再經過Binder驅動寫入到（具體實現後面說）B進程的Binder驅動內核空間，最後從Binder驅動再拷貝的B進程的用戶空間。如此一來，數據進行了兩次拷貝。

其實，Binder驅動內部並不須要兩次數據的拷貝，緣由在於Binder將內核內存空間與用戶內存空間進行了內存映射操做，具體以下圖

首先，咱們從數據接收進程看，內核與用戶內存空間，經過mmap映射到了同一塊物理內存上。也就是說對該塊物理內存的修改，將會提現到數據接收進程的用戶空間和內核空間。

再看數據發送進程，左邊的數據發送進程，只是將內核的內存空間映射到了物理內存上。

接着，當數據發送進程須要向數據接收進程傳遞數據時，數據只須要從數據發送進程的用戶內存空間拷貝到數據發送進程的內核內存空間，此時，由於數據發送進程的內核內存空間與物理內存進行了映射，而數據接收進程的用戶內存空間與內核內存空間同時都映射到了同一塊物理內存上，因此這次拷貝，直接將數據發送進程的用戶空間數據，拷貝到了數據接收進程的用戶內存空間。

經過上面的分析，也就能理解，爲何說Binder傳輸數據時須要拷貝1次數據，共享內存不須要拷貝數據

Binder的實現架構

完成對Binder跨進程通訊底層IPC實現分析以後，須要思考，Android如何讓兩個進程創建聯繫（如何找到通訊進程），那就須要一個系統進程，全部應用程序都知道它，並能聯繫到它，從這個系統進程那邊，可以查找到（經過Service名字符串）須要通信的進程。

最終，Android採用了Client、Server、ServiceManager的實現架構，其中Client須要從ServiceManager中找到Server，而後Client與Server之間便可進行通訊

那麼什麼進程可以在ServiceManager中註冊呢，就是在Android操做系統中註冊過（APP清單文件中的Service）的那部分服務才能註冊，到這，也就能理解Android爲何採用這種架構模式了，在安全上又進一步約束。

Binder驅動

首先要知道Binder驅動是運行在內核態下，內核態的內存是全部進程共享的。

任務一：存儲全部進程的Binder信息（引用編號，Server端的虛擬內存地址）

任務二：進程間數據傳遞

Binder是什麼

Binder是什麼，須要從多方面解釋，不一樣環境中，其表明的是不同的東西。

Binder在Server中的表述

Binder在Server中表明的是具體的實現，簡稱Binder實體

Binder在Client中的表述

Binder的具體實現應該是在Server進程，也就是說Client進程是沒法拿到該實現對象的地址信息的。
那麼Binder在Client中表明的僅僅是一個引用（驅動給的）編號，Client可以經過該編號向遠端Server發送數據。

Binder在驅動中的表述

驅動，是Binder架構在最核心的一部分，驅動須要作的事情不少

1. 全部Server端的Binder實體，須要在驅動中註冊
2. Client端獲取Binder時，須要爲Client建立Binder引用，並把引用編號信息記錄在驅動中
3. 維護各個Client中的引用於Binder實體之間的映射關係
4. 經過引用編號找到對應實體
5. 建立Server端的Binder實體
6. etc…

Binder實體（Server端）在驅動中的表述
Binder實體須要在驅動中進行註冊，註冊時，驅動須要在內核中爲Binder實體建立一個結構體binder_node
該結構體中存儲的主要數據爲

Server端Binder實體對象的內存地址

Server端Binder實體在全部實體鏈表中的節點結構體

說明：每一個Server進程都對應有一個鏈表，用來存儲全部的Binder實體節點，以Binder實體對象的內存地址爲索引進行查找。

Binder引用（Client端）在驅動中的表述

Binder引用在驅動中以binder_ref結構體的形式存在。改結構體中存儲的主要數據爲：

• Binder實體在驅動中的結構體引用
• Binder實體在驅動中的引用號（編號）
• Binder引用在進程鏈表中的節點（以編號以及實體地址爲索引的兩個鏈表節點）

說明：每一個Client進程都對應有兩個鏈表，一個是以Binder實體在驅動中的結構體地址爲索引創建的鏈表，一個是以Binder實體在驅動中的引用號爲索引簡歷的鏈表。

Binder在傳輸數據中的表述

雖然Binder實體和Binder引用都在驅動中有不一樣的結構體來標識，可是Client和Server在於Binder進行通訊時，並非經過傳遞這兩個結構體來表明不一樣的Binder的，而是經過另外一個統一的結構體flat_binder_object來表明本次通訊對應的Binder。

既然使用的是同一個結構體，那麼這個結構體中應該有的內容：

• Binder類型（實體，引用）
• Binder實體的內存地址（類型爲實體時用）
• Binder應用的編號（類型爲引用時用）

其中Binder類型有如下幾種：

• BINDER_TYPE_BINDER：表示傳遞的是Binder實體，而且指向該實體的引用都是強類型；
• BINDER_TYPE_WEAK_BINDER：表示傳遞的是Binder實體，而且指向該實體的引用都是弱類型；
• BINDER_TYPE_HANDLE：表示傳遞的是Binder強類型的引用
• BINDER_TYPE_WEAK_HANDLE：表示傳遞的是Binder弱類型的引用
• BINDER_TYPE_FD：表示傳遞的是文件形式的Binder

那麼flat_binder_object裏的內容填充方式具體是怎樣的呢，好比Server將Binder傳遞給Client，Server發送的flat_binder_object，類型應該是BINDER_TYPE_BINDER，此時，驅動將會在內核中爲Server進程建立對應的binder_node結構，而且將flat_binder_object中的Binder實體的內存地址保存起來。接着驅動須要在內核中爲Client進程建立一個binder_ref結構，由於Server穿過來的Binder實體的內存地址在Client進程是無效的，因此驅動須要爲Client進程建立一個Binder對應的引用編號，並將此編號存入binder_ref結構中。同時，須要將flat_binder_object中的類型改爲BINDER_TYPE_HANDLE，以及存儲引用編號。

當Client須要使用Server傳遞過來的Binder的時候，向驅動傳遞的數據包中，就須要用到Binder的引用編號，驅動將會對引用編號進行校驗，這樣就能在安全性上獲得保障。

Binder表述總結

當一個Server進程建立了一個Binder實體，以後，這個實體在各個環境中的表述狀況爲

1. Server進程中的Binder稱爲Binder實體，其應該要繼承BBinder類（Native類）
2. 其在Binder驅動中，以binder_node表述
3. 當Server進程的Binder服務須要被Client進程所使用時，Binder驅動會建立一個binder_ref結構體，這也就是Server中建立的Binder實體在Client進程中的表述（存儲引用編號）
4. 在Client的用戶空間中，須要建立一個Binder代理類，該類繼承BpBinder類，Client進程經過該代理類與Server端的Binder實體進行通訊