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物體進行通信

標籤：Android

上一篇：Android-ServiceManager

下一篇：13.Android-ListView使用、BaseAdapter/ArrayAdapter/SimpleAdapter配接器使用