Binder的實現是比較復雜的，想要完全弄明白是怎么一回事，并不是一件容易的事情。

這里面牽涉到好幾個層次，每一層都有一些模塊和機制需要理解。這部分內容預計會分為三篇文章來講解。本文是第一篇，首先會對整個Binder機制做一個架構性的講解，然后會將大部分精力用來講解Binder機制中最核心的部分：Binder驅動的實現。

Binder機制簡介

Binder源自Be Inc公司開發的OpenBinder框架，后來該框架轉移的Palm Inc，由Dianne Hackborn主導開發。OpenBinder的內核部分已經合入Linux Kernel 3.19。

Android Binder是在OpneBinder上的定制實現。原先的OpenBinder框架現在已經不再繼續開發，可以說Android上的Binder讓原先的OpneBinder得到了重生。

Binder是Android系統中大量使用的IPC（Inter-process communication，進程間通訊）機制。無論是應用程序對系統服務的請求，還是應用程序自身提供對外服務，都需要使用到Binder。

因此，Binder機制在Android系統中的地位非常重要，可以說，理解Binder是理解Android系統的絕對必要前提。

在Unix/Linux環境下，傳統的IPC機制包括：

• 管道
• 消息隊列
• 共享內存
• 信號量
• Socket

等。

由于篇幅所限，本文不會對這些IPC機制做講解，有興趣的讀者可以參閱《UNIX網絡編程 卷2：進程間通信》。

Android系統中對于傳統的IPC使用較少（但也有使用，例如：在請求Zygote fork進程的時候使用的是Socket IPC），大部分場景下使用的IPC都是Binder。

Binder相較于傳統IPC來說更適合于Android系統，具體原因的包括如下三點：

Binder本身是C/S架構的，這一點更符合Android系統的架構

性能上更有優勢：管道，消息隊列，Socket的通訊都需要兩次數據拷貝，而Binder只需要一次。要知道，對于系統底層的IPC形式，少一次數據拷貝，對整體性能的影響是非常之大的

安全性更好：傳統IPC形式，無法得到對方的身份標識（UID/GID)，而在使用Binder IPC時，這些身份標示是跟隨調用過程而自動傳遞的。Server端很容易就可以知道Client端的身份，非常便于做安全檢查

整體架構

Binder整體架構如下所示：

從圖中可以看出，Binder的實現分為這么幾層：

• Framework層
  • Java部分
  • JNI部分
  • C++部分
• 驅動層

驅動層位于Linux內核中，它提供了最底層的數據傳遞，對象標識，線程管理，調用過程控制等功能。驅動層是整個Binder機制的核心。

Framework層以驅動層為基礎，提供了應用開發的基礎設施。

Framework層既包含了C++部分的實現，也包含了Java部分的實現。為了能將C++的實現復用到Java端，中間通過JNI進行銜接。

開發者可以在Framework之上利用Binder提供的機制來進行具體的業務邏輯開發。其實不僅僅是第三方開發者，Android系統中本身也包含了很多系統服務都是基于Binder框架開發的。

既然是“進程間”通訊就至少牽涉到兩個進程，Binder框架是典型的C/S架構。在下文中，我們把服務的請求方稱之為Client，服務的實現方稱之為Server。

Client對于Server的請求會經由Binder框架由上至下傳遞到內核的Binder驅動中，請求中包含了Client將要調用的命令和參數。請求到了Binder驅動之后，在確定了服務的提供方之后，會再從下至上將請求傳遞給具體的服務。整個調用過程如下圖所示：

對網絡協議有所了解的讀者會發現，這個數據的傳遞過程和網絡協議是如此的相似。

初識ServiceManager

前面已經提到，使用Binder框架的既包括系統服務，也包括第三方應用。因此，在同一時刻，系統中會有大量的Server同時存在。那么，Client在請求Server的時候，是如果確定請求發送給哪一個Server的呢？

這個問題，就和我們現實生活中如何找到一個公司/商場，如何確定一個人/一輛車一樣，解決的方法就是：每個目標對象都需要一個唯一的標識。并且，需要有一個組織來管理這個唯一的標識。

而Binder框架中負責管理這個標識的就是ServiceManager。ServiceManager對于Binder Server的管理就好比車管所對于車牌號碼的的管理，派出所對于身份證號碼的管理：每個公開對外提供服務的Server都需要注冊到ServiceManager中（通過addService），注冊的時候需要指定一個唯一的id（這個id其實就是一個字符串）。

Client要對Server發出請求，就必須知道服務端的id。Client需要先根據Server的id通過ServerManager拿到Server的標示（通過getService），然后通過這個標示與Server進行通信。

整個過程如下圖所示：

如果上面這些介紹已經讓你一頭霧水，請不要過分擔心，下面會詳細講解這其中的細節。

下文會以自下而上的方式來講解Binder框架。自下而上未必是最好的方法，每個人的思考方式不一樣，如果你更喜歡自上而下的理解，你也按這樣的順序來閱讀。

對于大部分人來說，我們可能需要反復的查閱才能完全理解。

驅動層

源碼路徑（這部分代碼不在AOSP中，而是位于Linux內核代碼中）：

/kernel/drivers/android/binder.c /kernel/include/uapi/linux/android/binder.h

或者

/kernel/drivers/staging/android/binder.c /kernel/drivers/staging/android/uapi/binder.h

Binder機制的實現中，最核心的就是Binder驅動。 Binder是一個miscellaneous類型的驅動，本身不對應任何硬件，所有的操作都在軟件層。?binder_init函數負責Binder驅動的初始化工作，該函數中大部分代碼是在通過debugfs_create_dir和debugfs_create_file函數創建debugfs對應的文件。 如果內核在編譯時打開了debugfs，則通過adb shell連上設備之后，可以在設備的這個路徑找到debugfs對應的文件：/sys/kernel/debug。Binder驅動中創建的debug文件如下所示：

# ls -l /sys/kernel/debug/binder/ total 0 -r--r--r-- 1 root root 0 1970-01-01 00:00 failed_transaction_log drwxr-xr-x 2 root root 0 1970-05-09 01:19 proc -r--r--r-- 1 root root 0 1970-01-01 00:00 state -r--r--r-- 1 root root 0 1970-01-01 00:00 stats -r--r--r-- 1 root root 0 1970-01-01 00:00 transaction_log -r--r--r-- 1 root root 0 1970-01-01 00:00 transactions

這些文件其實都在內存中的，實時的反應了當前Binder的使用情況，在實際的開發過程中，這些信息可以幫忙分析問題。例如，可以通過查看/sys/kernel/debug/binder/proc目錄來確定哪些進程正在使用Binder，通過查看transaction_log和transactions文件來確定Binder通信的數據。

binder_init函數中最主要的工作其實下面這行：

ret = misc_register(&binder_miscdev);

該行代碼真正向內核中注冊了Binder設備。binder_miscdev的定義如下：

static struct miscdevice binder_miscdev = {.minor = MISC_DYNAMIC_MINOR,.name = "binder",.fops = &binder_fops };

這里指定了Binder設備的名稱是“binder”。這樣，在用戶空間便可以通過對/dev/binder文件進行操作來使用Binder。

binder_miscdev同時也指定了該設備的fops。fops是另外一個結構體，這個結構中包含了一系列的函數指針，其定義如下：

static const struct file_operations binder_fops = {.owner = THIS_MODULE,.poll = binder_poll,.unlocked_ioctl = binder_ioctl,.compat_ioctl = binder_ioctl,.mmap = binder_mmap,.open = binder_open,.flush = binder_flush,.release = binder_release, };

這里除了owner之外，每一個字段都是一個函數指針，這些函數指針對應了用戶空間在使用Binder設備時的操作。例如：binder_poll對應了poll系統調用的處理，binder_mmap對應了mmap系統調用的處理，其他類同。

這其中，有三個函數尤為重要，它們是：binder_open，binder_mmap和binder_ioctl。 這是因為，需要使用Binder的進程，幾乎總是先通過binder_open打開Binder設備，然后通過binder_mmap進行內存映射。

在這之后，通過binder_ioctl來進行實際的操作。Client對于Server端的請求，以及Server對于Client請求結果的返回，都是通過ioctl完成的。

這里提到的流程如下圖所示：

主要結構

Binder驅動中包含了很多的結構體。為了便于下文講解，這里我們先對這些結構體做一些介紹。

驅動中的結構體可以分為兩類：

一類是與用戶空間共用的，這些結構體在Binder通信協議過程中會用到。因此，這些結構體定義在binder.h中，包括：

結構體名稱說明

flat_binder_object	描述在Binder IPC中傳遞的對象，見下文
binder_write_read	存儲一次讀寫操作的數據
binder_version	存儲Binder的版本號
transaction_flags	描述事務的flag，例如是否是異步請求，是否支持fd
binder_transaction_data	存儲一次事務的數據
binder_ptr_cookie	包含了一個指針和一個cookie
binder_handle_cookie	包含了一個句柄和一個cookie
binder_pri_desc	暫未用到
binder_pri_ptr_cookie	暫未用到

這其中，binder_write_read和binder_transaction_data這兩個結構體最為重要，它們存儲了IPC調用過程中的數據。關于這一點，我們在下文中會講解。

Binder驅動中，還有一類結構體是僅僅Binder驅動內部實現過程中需要的，它們定義在binder.c中，包括：

結構體名稱說明

binder_node	描述Binder實體節點，即：對應了一個Server
binder_ref	描述對于Binder實體的引用
binder_buffer	描述Binder通信過程中存儲數據的Buffer
binder_proc	描述使用Binder的進程
binder_thread	描述使用Binder的線程
binder_work	描述通信過程中的一項任務
binder_transaction	描述一次事務的相關信息
binder_deferred_state	描述延遲任務
binder_ref_death	描述Binder實體死亡的信息
binder_transaction_log	debugfs日志
binder_transaction_log_entry	debugfs日志條目

這里需要讀者關注的結構體已經用加粗做了標注。

Binder協議

Binder協議可以分為控制協議和驅動協議兩類。

控制協議是進程通過ioctl(“/dev/binder”) 與Binder設備進行通訊的協議，該協議包含以下幾種命令：

命令說明參數類型

BINDER_WRITE_READ	讀寫操作，最常用的命令。IPC過程就是通過這個命令進行數據傳遞	binder_write_read
BINDER_SET_MAX_THREADS	設置進程支持的最大線程數量	size_t
BINDER_SET_CONTEXT_MGR	設置自身為ServiceManager	無
BINDER_THREAD_EXIT	通知驅動Binder線程退出	無
BINDER_VERSION	獲取Binder驅動的版本號	binder_version
BINDER_SET_IDLE_PRIORITY	暫未用到	-
BINDER_SET_IDLE_TIMEOUT	暫未用到	-

Binder的驅動協議描述了對于Binder驅動的具體使用過程。驅動協議又可以分為兩類：

• 一類是binder_driver_command_protocol，描述了進程發送給Binder驅動的命令
• 一類是binder_driver_return_protocol，描述了Binder驅動發送給進程的命令

binder_driver_command_protocol共包含17個命令，分別是：

命令說明參數類型

BC_TRANSACTION	Binder事務，即：Client對于Server的請求	binder_transaction_data
BC_REPLY	事務的應答，即：Server對于Client的回復	binder_transaction_data
BC_FREE_BUFFER	通知驅動釋放Buffer	binder_uintptr_t
BC_ACQUIRE	強引用計數+1	__u32
BC_RELEASE	強引用計數-1	__u32
BC_INCREFS	弱引用計數+1	__u32
BC_DECREFS	弱引用計數-1	__u32
BC_ACQUIRE_DONE	BR_ACQUIRE的回復	binder_ptr_cookie
BC_INCREFS_DONE	BR_INCREFS的回復	binder_ptr_cookie
BC_ENTER_LOOPER	通知驅動主線程ready	void
BC_REGISTER_LOOPER	通知驅動子線程ready	void
BC_EXIT_LOOPER	通知驅動線程已經退出	void
BC_REQUEST_DEATH_NOTIFICATION	請求接收死亡通知	binder_handle_cookie
BC_CLEAR_DEATH_NOTIFICATION	去除接收死亡通知	binder_handle_cookie
BC_DEAD_BINDER_DONE	已經處理完死亡通知	binder_uintptr_t
BC_ATTEMPT_ACQUIRE	暫未實現	-
BC_ACQUIRE_RESULT	暫未實現	-

binder_driver_return_protocol共包含18個命令，分別是：

返回類型說明參數類型

BR_OK	操作完成	void
BR_NOOP	操作完成	void
BR_ERROR	發生錯誤	__s32
BR_TRANSACTION	通知進程收到一次Binder請求（Server端）	binder_transaction_data
BR_REPLY	通知進程收到Binder請求的回復（Client）	binder_transaction_data
BR_TRANSACTION_COMPLETE	驅動對于接受請求的確認回復	void
BR_FAILED_REPLY	告知發送方通信目標不存在	void
BR_SPAWN_LOOPER	通知Binder進程創建一個新的線程	void
BR_ACQUIRE	強引用計數+1請求	binder_ptr_cookie
BR_RELEASE	強引用計數-1請求	binder_ptr_cookie
BR_INCREFS	弱引用計數+1請求	binder_ptr_cookie
BR_DECREFS	若引用計數-1請求	binder_ptr_cookie
BR_DEAD_BINDER	發送死亡通知	binder_uintptr_t
BR_CLEAR_DEATH_NOTIFICATION_DONE	清理死亡通知完成	binder_uintptr_t
BR_DEAD_REPLY	告知發送方對方已經死亡	void
BR_ACQUIRE_RESULT	暫未實現	-
BR_ATTEMPT_ACQUIRE	暫未實現	-
BR_FINISHED	暫未實現	-

單獨看上面的協議可能很難理解，這里我們以一次Binder請求過程來詳細看一下Binder協議是如何通信的，就比較好理解了。

這幅圖的說明如下：

• Binder是C/S架構的，通信過程牽涉到：Client，Server以及Binder驅動三個角色
• Client對于Server的請求以及Server對于Client回復都需要通過Binder驅動來中轉數據
• BC_XXX命令是進程發送給驅動的命令
• BR_XXX命令是驅動發送給進程的命令
• 整個通信過程由Binder驅動控制

這里再補充說明一下，通過上面的Binder協議的說明中我們看到，Binder協議的通信過程中，不僅僅是發送請求和接受數據這些命令。同時包括了對于引用計數的管理和對于死亡通知的管理（告知一方，通訊的另外一方已經死亡）等功能。

這些功能的通信過程和上面這幅圖是類似的：一方發送BC_XXX，然后由驅動控制通信過程，接著發送對應的BR_XXX命令給通信的另外一方。因為這種相似性，對于這些內容就不再贅述了。

在有了上面這些背景知識介紹之后，我們就可以進入到Binder驅動的內部實現中來一探究竟了。

PS：上面介紹的這些結構體和協議，因為內容較多，初次看完記不住是很正常的，在下文詳細講解的時候，回過頭來對照這些表格來理解是比較有幫助的。

打開Binder設備

任何進程在使用Binder之前，都需要先通過open("/dev/binder")打開Binder設備。上文已經提到，用戶空間的open系統調用對應了驅動中的binder_open函數。在這個函數，Binder驅動會為調用的進程做一些初始化工作。binder_open函數代碼如下所示：

static int binder_open(struct inode *nodp, struct file *filp) {struct binder_proc *proc;// 創建進程對應的binder_proc對象 proc = kzalloc(sizeof(*proc), GFP_KERNEL); if (proc == NULL)return -ENOMEM;get_task_struct(current);proc->tsk = current;// 初始化binder_proc INIT_LIST_HEAD(&proc->todo);init_waitqueue_head(&proc->wait);proc->default_priority = task_nice(current);// 鎖保護 binder_lock(__func__);binder_stats_created(BINDER_STAT_PROC);// 添加到全局列表binder_procs中 hlist_add_head(&proc->proc_node, &binder_procs);proc->pid = current->group_leader->pid;INIT_LIST_HEAD(&proc->delivered_death);filp->private_data = proc;binder_unlock(__func__);return 0; }

在Binder驅動中，通過binder_procs記錄了所有使用Binder的進程。每個初次打開Binder設備的進程都會被添加到這個列表中的。

另外，請讀者回顧一下上文介紹的Binder驅動中的幾個關鍵結構體：

• binder_proc
• binder_node
• binder_thread
• binder_ref
• binder_buffer

在實現過程中，為了便于查找，這些結構體互相之間都留有字段存儲關聯的結構。

下面這幅圖描述了這里說到的這些內容：

內存映射（mmap）

在打開Binder設備之后，進程還會通過mmap進行內存映射。mmap的作用有如下兩個：

• 申請一塊內存空間，用來接收Binder通信過程中的數據
• 對這塊內存進行地址映射，以便將來訪問

binder_mmap函數對應了mmap系統調用的處理，這個函數也是Binder驅動的精華所在（這里說的binder_mmap函數也包括其內部調用的binder_update_page_range函數，見下文）。

前文我們說到，使用Binder機制，數據只需要經歷一次拷貝就可以了，其原理就在這個函數中。

binder_mmap這個函數中，會申請一塊物理內存，然后在用戶空間和內核空間同時對應到這塊內存上。在這之后，當有Client要發送數據給Server的時候，只需一次，將Client發送過來的數據拷貝到Server端的內核空間指定的內存地址即可，由于這個內存地址在服務端已經同時映射到用戶空間，因此無需再做一次復制，Server即可直接訪問，整個過程如下圖所示：

這幅圖的說明如下：

Server在啟動之后，調用對/dev/binder設備調用mmap

內核中的binder_mmap函數進行對應的處理：申請一塊物理內存，然后在用戶空間和內核空間同時進行映射

Client通過BINDER_WRITE_READ命令發送請求，這個請求將先到驅動中，同時需要將數據從Client進程的用戶空間拷貝到內核空間

驅動通過BR_TRANSACTION通知Server有人發出請求，Server進行處理。由于這塊內存也在用戶空間進行了映射，因此Server進程的代碼可以直接訪問

了解原理之后，我們再來看一下Binder驅動的相關源碼。這段代碼有兩個函數：

• binder_mmap函數對應了mmap的系統調用的處理
• binder_update_page_range函數真正實現了內存分配和地址映射

static int binder_mmap(struct file *filp, struct vm_area_struct *vma) {int ret;struct vm_struct *area;struct binder_proc *proc = filp->private_data;const char *failure_string;struct binder_buffer *buffer;...// 在內核空間獲取一塊地址范圍 area = get_vm_area(vma->vm_end - vma->vm_start, VM_IOREMAP);if (area == NULL) {ret = -ENOMEM;failure_string = "get_vm_area";goto err_get_vm_area_failed;}proc->buffer = area->addr;// 記錄內核空間與用戶空間的地址偏移 proc->user_buffer_offset = vma->vm_start - (uintptr_t)proc->buffer;mutex_unlock(&binder_mmap_lock);...proc->pages = kzalloc(sizeof(proc->pages[0]) * ((vma->vm_end - vma->vm_start) / PAGE_SIZE), GFP_KERNEL);if (proc->pages == NULL) {ret = -ENOMEM;failure_string = "alloc page array";goto err_alloc_pages_failed;}proc->buffer_size = vma->vm_end - vma->vm_start;vma->vm_ops = &binder_vm_ops;vma->vm_private_data = proc;/* binder_update_page_range assumes preemption is disabled */preempt_disable();// 通過下面這個函數真正完成內存的申請和地址的映射 // 初次使用，先申請一個PAGE_SIZE大小的內存 ret = binder_update_page_range(proc, 1, proc->buffer, proc->buffer + PAGE_SIZE, vma);... }static int binder_update_page_range(struct binder_proc *proc, int allocate,void *start, void *end,struct vm_area_struct *vma) {void *page_addr;unsigned long user_page_addr;struct vm_struct tmp_area;struct page **page;struct mm_struct *mm;...for (page_addr = start; page_addr < end; page_addr += PAGE_SIZE) {int ret;struct page **page_array_ptr;page = &proc->pages[(page_addr - proc->buffer) / PAGE_SIZE];BUG_ON(*page);// 真正進行內存的分配 *page = alloc_page(GFP_KERNEL | __GFP_HIGHMEM | __GFP_ZERO);if (*page == NULL) {pr_err("%d: binder_alloc_buf failed for page at %p\n",proc->pid, page_addr);goto err_alloc_page_failed;}tmp_area.addr = page_addr;tmp_area.size = PAGE_SIZE + PAGE_SIZE /* guard page? */;page_array_ptr = page;// 在內核空間進行內存映射 ret = map_vm_area(&tmp_area, PAGE_KERNEL, &page_array_ptr);if (ret) {pr_err("%d: binder_alloc_buf failed to map page at %p in kernel\n",proc->pid, page_addr);goto err_map_kernel_failed;}user_page_addr =(uintptr_t)page_addr + proc->user_buffer_offset;// 在用戶空間進行內存映射 ret = vm_insert_page(vma, user_page_addr, page[0]);if (ret) {pr_err("%d: binder_alloc_buf failed to map page at %lx in userspace\n",proc->pid, user_page_addr);goto err_vm_insert_page_failed;}/* vm_insert_page does not seem to increment the refcount */}if (mm) {up_write(&mm->mmap_sem);mmput(mm);}preempt_disable();return 0; ...

在開發過程中，我們可以通過procfs看到進程映射的這塊內存空間：

將Android設備連接到電腦上之后，通過adb shell進入到終端

然后選擇一個使用了Binder的進程，例如system_server（這是系統中一個非常重要的進程，下一章我們會專門講解），通過?ps | grep system_server來確定進程號，例如是1889

通過?cat /proc/[pid]/maps | grep "/dev/binder"?過濾出這塊內存的地址

在我的Nexus 6P上，控制臺輸出如下：

angler:/ # ps | grep system_server system 1889 526 2353404 140016 SyS_epoll_ 72972eeaf4 S system_server angler:/ # cat /proc/1889/maps | grep "/dev/binder" 7294761000-729485f000 r--p 00000000 00:0c 12593 /dev/binder

PS：grep是通過通配符進行匹配過濾的命令，“|”是Unix上的管道命令。即將前一個命令的輸出給下一個命令作為輸入。如果這里我們不加“ | grep xxx”，那么將看到前一個命令的完整輸出。

內存的管理

上文中，我們看到binder_mmap的時候，會申請一個PAGE_SIZE(通常是4K)的內存。而實際使用過程中，一個PAGE_SIZE的大小通常是不夠的。

在驅動中，會根據實際的使用情況進行內存的分配。有內存的分配，當然也需要內存的釋放。這里我們就來看看Binder驅動中是如何進行內存的管理的。

首先，我們還是從一次IPC請求說起。

當一個Client想要對Server發出請求時，它首先將請求發送到Binder設備上，由Binder驅動根據請求的信息找到對應的目標節點，然后將請求數據傳遞過去。

進程通過ioctl系統調用來發出請求：ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr)

PS：這行代碼來自于Framework層的IPCThreadState類。在后文中，我們將看到，IPCThreadState類專門負責與驅動進行通信。

這里的mProcess->mDriverFD對應了打開Binder設備時的fd。BINDER_WRITE_READ對應了具體要做的操作碼，這個操作碼將由Binder驅動解析。bwr存儲了請求數據，其類型是binder_write_read。

binder_write_read其實是一個相對外層的數據結構，其內部會包含一個binder_transaction_data結構的數據。binder_transaction_data包含了發出請求者的標識，請求的目標對象以及請求所需要的參數。它們的關系如下圖所示：

binder_ioctl函數對應了ioctl系統調用的處理。這個函數的邏輯比較簡單，就是根據ioctl的命令來確定進一步處理的邏輯，具體如下:

• 如果命令是BINDER_WRITE_READ，并且
  • 如果 bwr.write_size > 0，則調用binder_thread_write
  • 如果 bwr.read_size > 0，則調用binder_thread_read
• 如果命令是BINDER_SET_MAX_THREADS，則設置進程的max_threads，即進程支持的最大線程數
• 如果命令是BINDER_SET_CONTEXT_MGR，則設置當前進程為ServiceManager，見下文
• 如果命令是BINDER_THREAD_EXIT，則調用binder_free_thread，釋放binder_thread
• 如果命令是BINDER_VERSION，則返回當前的Binder版本號

這其中，最關鍵的就是binder_thread_write方法。當Client請求Server的時候，便會發送一個BINDER_WRITE_READ命令，同時框架會將將實際的數據包裝好。此時，binder_transaction_data中的code將是BC_TRANSACTION，由此便會調用到binder_transaction方法，這個方法是對一次Binder事務的處理，這其中會調用binder_alloc_buf函數為此次事務申請一個緩存。這里提到到調用關系如下：

binder_update_page_range這個函數在上文中，我們已經看到過了。其作用就是：進行內存分配并且完成內存的映射。而binder_alloc_buf函數，正如其名稱那樣的：完成緩存的分配。

在驅動中，通過binder_buffer結構體描述緩存。一次Binder事務就會對應一個binder_buffer，其結構如下所示：

struct binder_buffer {struct list_head entry;struct rb_node rb_node;unsigned free:1;unsigned allow_user_free:1;unsigned async_transaction:1;unsigned debug_id:29;struct binder_transaction *transaction;struct binder_node *target_node;size_t data_size;size_t offsets_size;uint8_t data[0]; };

而在binder_proc（描述了使用Binder的進程）中，包含了幾個字段用來管理進程在Binder IPC過程中緩存，如下：

struct binder_proc {...struct list_head buffers; // 進程擁有的buffer列表 struct rb_root free_buffers; // 空閑buffer列表 struct rb_root allocated_buffers; // 已使用的buffer列表 size_t free_async_space; // 剩余的異步調用的空間 size_t buffer_size; // 緩存的上限 ... };

進程在mmap時，會設定支持的總緩存大小的上限（下文會講到）。而進程每當收到BC_TRANSACTION，就會判斷已使用緩存加本次申請的和有沒有超過上限。如果沒有，就考慮進行內存的分配。

進程的空閑緩存記錄在binder_proc的free_buffers中，這是一個以紅黑樹形式存儲的結構。每次嘗試分配緩存的時候，會從這里面按大小順序進行查找，找到最接近需要的一塊緩存。查找的邏輯如下：

while (n) {buffer = rb_entry(n, struct binder_buffer, rb_node);BUG_ON(!buffer->free);buffer_size = binder_buffer_size(proc, buffer);if (size < buffer_size) {best_fit = n;n = n->rb_left;} else if (size > buffer_size)n = n->rb_right;else {best_fit = n;break;} }

找到之后，還需要對binder_proc中的字段進行相應的更新：

rb_erase(best_fit, &proc->free_buffers); buffer->free = 0; binder_insert_allocated_buffer(proc, buffer); if (buffer_size != size) {struct binder_buffer *new_buffer = (void *)buffer->data + size;list_add(&new_buffer->entry, &buffer->entry);new_buffer->free = 1;binder_insert_free_buffer(proc, new_buffer); } binder_debug(BINDER_DEBUG_BUFFER_ALLOC,"%d: binder_alloc_buf size %zd got %p\n",proc->pid, size, buffer); buffer->data_size = data_size; buffer->offsets_size = offsets_size; buffer->async_transaction = is_async; if (is_async) {proc->free_async_space -= size + sizeof(struct binder_buffer);binder_debug(BINDER_DEBUG_BUFFER_ALLOC_ASYNC,"%d: binder_alloc_buf size %zd async free %zd\n",proc->pid, size, proc->free_async_space); }

下面我們再來看看內存的釋放。

BC_FREE_BUFFER命令是通知驅動進行內存的釋放，binder_free_buf函數是真正實現的邏輯，這個函數與binder_alloc_buf是剛好對應的。在這個函數中，所做的事情包括：

• 重新計算進程的空閑緩存大小
• 通過binder_update_page_range釋放內存
• 更新binder_proc的buffers，free_buffers，allocated_buffers字段

Binder中的“面向對象”

Binder機制淡化了進程的邊界，使得跨越進程也能夠調用到指定服務的方法，其原因是因為Binder機制在底層處理了在進程間的“對象”傳遞。

在Binder驅動中，并不是真的將對象在進程間來回序列化，而是通過特定的標識來進行對象的傳遞。Binder驅動中，通過flat_binder_object來描述需要跨越進程傳遞的對象。其定義如下：

struct flat_binder_object {__u32 type;__u32 flags;union {binder_uintptr_t binder; /* local object */__u32 handle; /* remote object */};binder_uintptr_t cookie; };

這其中，type有如下5種類型。

enum {BINDER_TYPE_BINDER = B_PACK_CHARS('s', 'b', '*', B_TYPE_LARGE),BINDER_TYPE_WEAK_BINDER = B_PACK_CHARS('w', 'b', '*', B_TYPE_LARGE),BINDER_TYPE_HANDLE = B_PACK_CHARS('s', 'h', '*', B_TYPE_LARGE),BINDER_TYPE_WEAK_HANDLE = B_PACK_CHARS('w', 'h', '*', B_TYPE_LARGE),BINDER_TYPE_FD = B_PACK_CHARS('f', 'd', '*', B_TYPE_LARGE), };

當對象傳遞到Binder驅動中的時候，由驅動來進行翻譯和解釋，然后傳遞到接收的進程。

例如當Server把Binder實體傳遞給Client時，在發送數據流中，flat_binder_object中的type是BINDER_TYPE_BINDER，同時binder字段指向Server進程用戶空間地址。但這個地址對于Client進程是沒有意義的（Linux中，每個進程的地址空間是互相隔離的），驅動必須對數據流中的flat_binder_object做相應的翻譯：將type該成BINDER_TYPE_HANDLE；為這個Binder在接收進程中創建位于內核中的引用并將引用號填入handle中。對于發生數據流中引用類型的Binder也要做同樣轉換。經過處理后接收進程從數據流中取得的Binder引用才是有效的，才可以將其填入數據包binder_transaction_data的target.handle域，向Binder實體發送請求。

由于每個請求和請求的返回都會經歷內核的翻譯，因此這個過程從進程的角度來看是完全透明的。進程完全不用感知這個過程，就好像對象真的在進程間來回傳遞一樣。

驅動層的線程管理

上文多次提到，Binder本身是C/S架構。由Server提供服務，被Client使用。既然是C/S架構，就可能存在多個Client會同時訪問Server的情況。 在這種情況下，如果Server只有一個線程處理響應，就會導致客戶端的請求可能需要排隊而導致響應過慢的現象發生。解決這個問題的方法就是引入多線程。

Binder機制的設計從最底層–驅動層，就考慮到了對于多線程的支持。具體內容如下：

• 使用Binder的進程在啟動之后，通過BINDER_SET_MAX_THREADS告知驅動其支持的最大線程數量
• 驅動會對線程進行管理。在binder_proc結構中，這些字段記錄了進程中線程的信息：max_threads，requested_threads，requested_threads_started，ready_threads
• binder_thread結構對應了Binder進程中的線程
• 驅動通過BR_SPAWN_LOOPER命令告知進程需要創建一個新的線程
• 進程通過BC_ENTER_LOOPER命令告知驅動其主線程已經ready
• 進程通過BC_REGISTER_LOOPER命令告知驅動其子線程（非主線程）已經ready
• 進程通過BC_EXIT_LOOPER命令告知驅動其線程將要退出
• 在線程退出之后，通過BINDER_THREAD_EXIT告知Binder驅動。驅動將對應的binder_thread對象銷毀

再聊ServiceManager

上文已經說過，每一個Binder Server在驅動中會有一個binder_node進行對應。同時，Binder驅動會負責在進程間傳遞服務對象，并負責底層的轉換。另外，我們也提到，每一個Binder服務都需要有一個唯一的名稱。由ServiceManager來管理這些服務的注冊和查找。

而實際上，為了便于使用，ServiceManager本身也實現為一個Server對象。任何進程在使用ServiceManager的時候，都需要先拿到指向它的標識。然后通過這個標識來使用ServiceManager。

這似乎形成了一個互相矛盾的現象：

通過ServiceManager我們才能拿到Server的標識

ServiceManager本身也是一個Server

解決這個矛盾的辦法其實也很簡單：Binder機制為ServiceManager預留了一個特殊的位置。這個位置是預先定好的，任何想要使用ServiceManager的進程只要通過這個特定的位置就可以訪問到ServiceManager了（而不用再通過ServiceManager的接口）。

在Binder驅動中，有一個全局的變量：

static struct binder_node *binder_context_mgr_node;

這個變量指向的就是ServiceManager。

當有進程通過ioctl并指定命令為BINDER_SET_CONTEXT_MGR的時候，驅動被認定這個進程是ServiceManager，binder_ioctl函數中對應的處理如下：

case BINDER_SET_CONTEXT_MGR:if (binder_context_mgr_node != NULL) {pr_err("BINDER_SET_CONTEXT_MGR already set\n");ret = -EBUSY;goto err;}ret = security_binder_set_context_mgr(proc->tsk);if (ret < 0)goto err;if (uid_valid(binder_context_mgr_uid)) {if (!uid_eq(binder_context_mgr_uid, current->cred->euid)) {pr_err("BINDER_SET_CONTEXT_MGR bad uid %d != %d\n",from_kuid(&init_user_ns, current->cred->euid),from_kuid(&init_user_ns, binder_context_mgr_uid)); ret = -EPERM;goto err;}} elsebinder_context_mgr_uid = current->cred->euid;binder_context_mgr_node = binder_new_node(proc, 0, 0);if (binder_context_mgr_node == NULL) {ret = -ENOMEM;goto err;}binder_context_mgr_node->local_weak_refs++;binder_context_mgr_node->local_strong_refs++;binder_context_mgr_node->has_strong_ref = 1;binder_context_mgr_node->has_weak_ref = 1;break;

ServiceManager應當要先于所有Binder Server之前啟動。在它啟動完成并告知Binder驅動之后，驅動便設定好了這個特定的節點。

在這之后，當有其他模塊想要使用ServerManager的時候，只要將請求指向ServiceManager所在的位置即可。

在Binder驅動中，通過handle = 0這個位置來訪問ServiceManager。例如，binder_transaction中，判斷如果target.handler為0，則認為這個請求是發送給ServiceManager的，相關代碼如下：

if (tr->target.handle) {struct binder_ref *ref;ref = binder_get_ref(proc, tr->target.handle, true);if (ref == NULL) {binder_user_error("%d:%d got transaction to invalid handle\n",proc->pid, thread->pid);return_error = BR_FAILED_REPLY;goto err_invalid_target_handle;}target_node = ref->node; } else {target_node = binder_context_mgr_node;if (target_node == NULL) {return_error = BR_DEAD_REPLY;goto err_no_context_mgr_node;} }

結束語

本篇文章中，我們對Binder機制做了整體架構和分層的介紹，也詳細講解了Binder機制中的驅動模塊。對于驅動之上的模塊，會在今后的文章中講解。

下一篇文章中，我們會詳細講解Android Binder機制的Framework層，敬請期待。

原文：http://qiangbo.space/2017-01-15/AndroidAnatomy_Binder_Driver/

總結

以上是生活随笔為你收集整理的理解Android Binder机制(1/3)：驱动篇的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。