理解Android Binder机制(1/3)：驱动篇
Binder的實現(xiàn)是比較復(fù)雜的，想要完全弄明白是怎么一回事，并不是一件容易的事情。
這里面牽涉到好幾個層次，每一層都有一些模塊和機(jī)制需要理解。這部分內(nèi)容預(yù)計會分為三篇文章來講解。本文是第一篇，首先會對整個Binder機(jī)制做一個架構(gòu)性的講解，然后會將大部分精力用來講解Binder機(jī)制中最核心的部分：Binder驅(qū)動的實現(xiàn)。
Binder機(jī)制簡介
Binder源自Be Inc公司開發(fā)的OpenBinder框架，后來該框架轉(zhuǎn)移的Palm Inc，由Dianne Hackborn主導(dǎo)開發(fā)。OpenBinder的內(nèi)核部分已經(jīng)合入Linux Kernel 3.19。
Android Binder是在OpneBinder上的定制實現(xiàn)。原先的OpenBinder框架現(xiàn)在已經(jīng)不再繼續(xù)開發(fā)，可以說Android上的Binder讓原先的OpneBinder得到了重生。
Binder是Android系統(tǒng)中大量使用的IPC（Inter-process communication，進(jìn)程間通訊）機(jī)制。無論是應(yīng)用程序?qū)ο到y(tǒng)服務(wù)的請求，還是應(yīng)用程序自身提供對外服務(wù)，都需要使用到Binder。
因此，Binder機(jī)制在Android系統(tǒng)中的地位非常重要，可以說，理解Binder是理解Android系統(tǒng)的絕對必要前提。
在Unix/Linux環(huán)境下，傳統(tǒng)的IPC機(jī)制包括：
- 管道
- 消息隊列
- 共享內(nèi)存
- 信號量
- Socket
等。
由于篇幅所限，本文不會對這些IPC機(jī)制做講解，有興趣的讀者可以參閱《UNIX網(wǎng)絡(luò)編程 卷2：進(jìn)程間通信》。
Android系統(tǒng)中對于傳統(tǒng)的IPC使用較少（但也有使用，例如：在請求Zygote fork進(jìn)程的時候使用的是Socket IPC），大部分場景下使用的IPC都是Binder。
Binder相較于傳統(tǒng)IPC來說更適合于Android系統(tǒng)，具體原因的包括如下三點：
整體架構(gòu)
Binder整體架構(gòu)如下所示：
從圖中可以看出，Binder的實現(xiàn)分為這么幾層：
- Framework層
- Java部分
- JNI部分
- C++部分
- 驅(qū)動層
驅(qū)動層位于Linux內(nèi)核中，它提供了最底層的數(shù)據(jù)傳遞，對象標(biāo)識，線程管理，調(diào)用過程控制等功能。驅(qū)動層是整個Binder機(jī)制的核心。
Framework層以驅(qū)動層為基礎(chǔ)，提供了應(yīng)用開發(fā)的基礎(chǔ)設(shè)施。
Framework層既包含了C++部分的實現(xiàn)，也包含了Java部分的實現(xiàn)。為了能將C++的實現(xiàn)復(fù)用到Java端，中間通過JNI進(jìn)行銜接。
開發(fā)者可以在Framework之上利用Binder提供的機(jī)制來進(jìn)行具體的業(yè)務(wù)邏輯開發(fā)。其實不僅僅是第三方開發(fā)者，Android系統(tǒng)中本身也包含了很多系統(tǒng)服務(wù)都是基于Binder框架開發(fā)的。
既然是“進(jìn)程間”通訊就至少牽涉到兩個進(jìn)程，Binder框架是典型的C/S架構(gòu)。在下文中，我們把服務(wù)的請求方稱之為Client，服務(wù)的實現(xiàn)方稱之為Server。
Client對于Server的請求會經(jīng)由Binder框架由上至下傳遞到內(nèi)核的Binder驅(qū)動中，請求中包含了Client將要調(diào)用的命令和參數(shù)。請求到了Binder驅(qū)動之后，在確定了服務(wù)的提供方之后，會再從下至上將請求傳遞給具體的服務(wù)。整個調(diào)用過程如下圖所示：
對網(wǎng)絡(luò)協(xié)議有所了解的讀者會發(fā)現(xiàn)，這個數(shù)據(jù)的傳遞過程和網(wǎng)絡(luò)協(xié)議是如此的相似。
初識ServiceManager
前面已經(jīng)提到，使用Binder框架的既包括系統(tǒng)服務(wù)，也包括第三方應(yīng)用。因此，在同一時刻，系統(tǒng)中會有大量的Server同時存在。那么，Client在請求Server的時候，是如果確定請求發(fā)送給哪一個Server的呢？
這個問題，就和我們現(xiàn)實生活中如何找到一個公司/商場，如何確定一個人/一輛車一樣，解決的方法就是：每個目標(biāo)對象都需要一個唯一的標(biāo)識。并且，需要有一個組織來管理這個唯一的標(biāo)識。
而Binder框架中負(fù)責(zé)管理這個標(biāo)識的就是ServiceManager。ServiceManager對于Binder Server的管理就好比車管所對于車牌號碼的的管理，派出所對于身份證號碼的管理：每個公開對外提供服務(wù)的Server都需要注冊到ServiceManager中（通過addService），注冊的時候需要指定一個唯一的id（這個id其實就是一個字符串）。
Client要對Server發(fā)出請求，就必須知道服務(wù)端的id。Client需要先根據(jù)Server的id通過ServerManager拿到Server的標(biāo)示（通過getService），然后通過這個標(biāo)示與Server進(jìn)行通信。
整個過程如下圖所示：
如果上面這些介紹已經(jīng)讓你一頭霧水，請不要過分擔(dān)心，下面會詳細(xì)講解這其中的細(xì)節(jié)。
下文會以自下而上的方式來講解Binder框架。自下而上未必是最好的方法，每個人的思考方式不一樣，如果你更喜歡自上而下的理解，你也按這樣的順序來閱讀。
對于大部分人來說，我們可能需要反復(fù)的查閱才能完全理解。
驅(qū)動層
源碼路徑（這部分代碼不在AOSP中，而是位于Linux內(nèi)核代碼中）：
/kernel/drivers/android/binder.c /kernel/include/uapi/linux/android/binder.h或者
/kernel/drivers/staging/android/binder.c /kernel/drivers/staging/android/uapi/binder.hBinder機(jī)制的實現(xiàn)中，最核心的就是Binder驅(qū)動。 Binder是一個miscellaneous類型的驅(qū)動，本身不對應(yīng)任何硬件，所有的操作都在軟件層。?binder_init函數(shù)負(fù)責(zé)Binder驅(qū)動的初始化工作，該函數(shù)中大部分代碼是在通過debugfs_create_dir和debugfs_create_file函數(shù)創(chuàng)建debugfs對應(yīng)的文件。 如果內(nèi)核在編譯時打開了debugfs，則通過adb shell連上設(shè)備之后，可以在設(shè)備的這個路徑找到debugfs對應(yīng)的文件：/sys/kernel/debug。Binder驅(qū)動中創(chuàng)建的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這些文件其實都在內(nèi)存中的，實時的反應(yīng)了當(dāng)前Binder的使用情況，在實際的開發(fā)過程中，這些信息可以幫忙分析問題。例如，可以通過查看/sys/kernel/debug/binder/proc目錄來確定哪些進(jìn)程正在使用Binder，通過查看transaction_log和transactions文件來確定Binder通信的數(shù)據(jù)。
binder_init函數(shù)中最主要的工作其實下面這行：
ret = misc_register(&binder_miscdev);
該行代碼真正向內(nèi)核中注冊了Binder設(shè)備。binder_miscdev的定義如下：
static struct miscdevice binder_miscdev = {.minor = MISC_DYNAMIC_MINOR,.name = "binder",.fops = &binder_fops };這里指定了Binder設(shè)備的名稱是“binder”。這樣，在用戶空間便可以通過對/dev/binder文件進(jìn)行操作來使用Binder。
binder_miscdev同時也指定了該設(shè)備的fops。fops是另外一個結(jié)構(gòu)體，這個結(jié)構(gòu)中包含了一系列的函數(shù)指針，其定義如下：
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之外，每一個字段都是一個函數(shù)指針，這些函數(shù)指針對應(yīng)了用戶空間在使用Binder設(shè)備時的操作。例如：binder_poll對應(yīng)了poll系統(tǒng)調(diào)用的處理，binder_mmap對應(yīng)了mmap系統(tǒng)調(diào)用的處理，其他類同。
這其中，有三個函數(shù)尤為重要，它們是：binder_open，binder_mmap和binder_ioctl。 這是因為，需要使用Binder的進(jìn)程，幾乎總是先通過binder_open打開Binder設(shè)備，然后通過binder_mmap進(jìn)行內(nèi)存映射。
在這之后，通過binder_ioctl來進(jìn)行實際的操作。Client對于Server端的請求，以及Server對于Client請求結(jié)果的返回，都是通過ioctl完成的。
這里提到的流程如下圖所示：
主要結(jié)構(gòu)
Binder驅(qū)動中包含了很多的結(jié)構(gòu)體。為了便于下文講解，這里我們先對這些結(jié)構(gòu)體做一些介紹。
驅(qū)動中的結(jié)構(gòu)體可以分為兩類：
一類是與用戶空間共用的，這些結(jié)構(gòu)體在Binder通信協(xié)議過程中會用到。因此，這些結(jié)構(gòu)體定義在binder.h中，包括：
| flat_binder_object | 描述在Binder IPC中傳遞的對象，見下文 |
| binder_write_read | 存儲一次讀寫操作的數(shù)據(jù) |
| binder_version | 存儲Binder的版本號 |
| transaction_flags | 描述事務(wù)的flag，例如是否是異步請求，是否支持fd |
| binder_transaction_data | 存儲一次事務(wù)的數(shù)據(jù) |
| binder_ptr_cookie | 包含了一個指針和一個cookie |
| binder_handle_cookie | 包含了一個句柄和一個cookie |
| binder_pri_desc | 暫未用到 |
| binder_pri_ptr_cookie | 暫未用到 |
這其中，binder_write_read和binder_transaction_data這兩個結(jié)構(gòu)體最為重要，它們存儲了IPC調(diào)用過程中的數(shù)據(jù)。關(guān)于這一點，我們在下文中會講解。
Binder驅(qū)動中，還有一類結(jié)構(gòu)體是僅僅Binder驅(qū)動內(nèi)部實現(xiàn)過程中需要的，它們定義在binder.c中，包括：
| binder_node | 描述Binder實體節(jié)點，即：對應(yīng)了一個Server |
| binder_ref | 描述對于Binder實體的引用 |
| binder_buffer | 描述Binder通信過程中存儲數(shù)據(jù)的Buffer |
| binder_proc | 描述使用Binder的進(jìn)程 |
| binder_thread | 描述使用Binder的線程 |
| binder_work | 描述通信過程中的一項任務(wù) |
| binder_transaction | 描述一次事務(wù)的相關(guān)信息 |
| binder_deferred_state | 描述延遲任務(wù) |
| binder_ref_death | 描述Binder實體死亡的信息 |
| binder_transaction_log | debugfs日志 |
| binder_transaction_log_entry | debugfs日志條目 |
這里需要讀者關(guān)注的結(jié)構(gòu)體已經(jīng)用加粗做了標(biāo)注。
Binder協(xié)議
Binder協(xié)議可以分為控制協(xié)議和驅(qū)動協(xié)議兩類。
控制協(xié)議是進(jìn)程通過ioctl(“/dev/binder”) 與Binder設(shè)備進(jìn)行通訊的協(xié)議，該協(xié)議包含以下幾種命令：
| BINDER_WRITE_READ | 讀寫操作，最常用的命令。IPC過程就是通過這個命令進(jìn)行數(shù)據(jù)傳遞 | binder_write_read |
| BINDER_SET_MAX_THREADS | 設(shè)置進(jìn)程支持的最大線程數(shù)量 | size_t |
| BINDER_SET_CONTEXT_MGR | 設(shè)置自身為ServiceManager | 無 |
| BINDER_THREAD_EXIT | 通知驅(qū)動Binder線程退出 | 無 |
| BINDER_VERSION | 獲取Binder驅(qū)動的版本號 | binder_version |
| BINDER_SET_IDLE_PRIORITY | 暫未用到 | - |
| BINDER_SET_IDLE_TIMEOUT | 暫未用到 | - |
Binder的驅(qū)動協(xié)議描述了對于Binder驅(qū)動的具體使用過程。驅(qū)動協(xié)議又可以分為兩類：
- 一類是binder_driver_command_protocol，描述了進(jìn)程發(fā)送給Binder驅(qū)動的命令
- 一類是binder_driver_return_protocol，描述了Binder驅(qū)動發(fā)送給進(jìn)程的命令
binder_driver_command_protocol共包含17個命令，分別是：
| BC_TRANSACTION | Binder事務(wù)，即：Client對于Server的請求 | binder_transaction_data |
| BC_REPLY | 事務(wù)的應(yīng)答，即：Server對于Client的回復(fù) | binder_transaction_data |
| BC_FREE_BUFFER | 通知驅(qū)動釋放Buffer | binder_uintptr_t |
| BC_ACQUIRE | 強(qiáng)引用計數(shù)+1 | __u32 |
| BC_RELEASE | 強(qiáng)引用計數(shù)-1 | __u32 |
| BC_INCREFS | 弱引用計數(shù)+1 | __u32 |
| BC_DECREFS | 弱引用計數(shù)-1 | __u32 |
| BC_ACQUIRE_DONE | BR_ACQUIRE的回復(fù) | binder_ptr_cookie |
| BC_INCREFS_DONE | BR_INCREFS的回復(fù) | binder_ptr_cookie |
| BC_ENTER_LOOPER | 通知驅(qū)動主線程ready | void |
| BC_REGISTER_LOOPER | 通知驅(qū)動子線程ready | void |
| BC_EXIT_LOOPER | 通知驅(qū)動線程已經(jīng)退出 | void |
| BC_REQUEST_DEATH_NOTIFICATION | 請求接收死亡通知 | binder_handle_cookie |
| BC_CLEAR_DEATH_NOTIFICATION | 去除接收死亡通知 | binder_handle_cookie |
| BC_DEAD_BINDER_DONE | 已經(jīng)處理完死亡通知 | binder_uintptr_t |
| BC_ATTEMPT_ACQUIRE | 暫未實現(xiàn) | - |
| BC_ACQUIRE_RESULT | 暫未實現(xiàn) | - |
binder_driver_return_protocol共包含18個命令，分別是：
| BR_OK | 操作完成 | void |
| BR_NOOP | 操作完成 | void |
| BR_ERROR | 發(fā)生錯誤 | __s32 |
| BR_TRANSACTION | 通知進(jìn)程收到一次Binder請求（Server端） | binder_transaction_data |
| BR_REPLY | 通知進(jìn)程收到Binder請求的回復(fù)（Client） | binder_transaction_data |
| BR_TRANSACTION_COMPLETE | 驅(qū)動對于接受請求的確認(rèn)回復(fù) | void |
| BR_FAILED_REPLY | 告知發(fā)送方通信目標(biāo)不存在 | void |
| BR_SPAWN_LOOPER | 通知Binder進(jìn)程創(chuàng)建一個新的線程 | void |
| BR_ACQUIRE | 強(qiáng)引用計數(shù)+1請求 | binder_ptr_cookie |
| BR_RELEASE | 強(qiáng)引用計數(shù)-1請求 | binder_ptr_cookie |
| BR_INCREFS | 弱引用計數(shù)+1請求 | binder_ptr_cookie |
| BR_DECREFS | 若引用計數(shù)-1請求 | binder_ptr_cookie |
| BR_DEAD_BINDER | 發(fā)送死亡通知 | binder_uintptr_t |
| BR_CLEAR_DEATH_NOTIFICATION_DONE | 清理死亡通知完成 | binder_uintptr_t |
| BR_DEAD_REPLY | 告知發(fā)送方對方已經(jīng)死亡 | void |
| BR_ACQUIRE_RESULT | 暫未實現(xiàn) | - |
| BR_ATTEMPT_ACQUIRE | 暫未實現(xiàn) | - |
| BR_FINISHED | 暫未實現(xiàn) | - |
單獨看上面的協(xié)議可能很難理解，這里我們以一次Binder請求過程來詳細(xì)看一下Binder協(xié)議是如何通信的，就比較好理解了。
這幅圖的說明如下：
- Binder是C/S架構(gòu)的，通信過程牽涉到：Client，Server以及Binder驅(qū)動三個角色
- Client對于Server的請求以及Server對于Client回復(fù)都需要通過Binder驅(qū)動來中轉(zhuǎn)數(shù)據(jù)
- BC_XXX命令是進(jìn)程發(fā)送給驅(qū)動的命令
- BR_XXX命令是驅(qū)動發(fā)送給進(jìn)程的命令
- 整個通信過程由Binder驅(qū)動控制
這里再補(bǔ)充說明一下，通過上面的Binder協(xié)議的說明中我們看到，Binder協(xié)議的通信過程中，不僅僅是發(fā)送請求和接受數(shù)據(jù)這些命令。同時包括了對于引用計數(shù)的管理和對于死亡通知的管理（告知一方，通訊的另外一方已經(jīng)死亡）等功能。
這些功能的通信過程和上面這幅圖是類似的：一方發(fā)送BC_XXX，然后由驅(qū)動控制通信過程，接著發(fā)送對應(yīng)的BR_XXX命令給通信的另外一方。因為這種相似性，對于這些內(nèi)容就不再贅述了。
在有了上面這些背景知識介紹之后，我們就可以進(jìn)入到Binder驅(qū)動的內(nèi)部實現(xiàn)中來一探究竟了。
PS：上面介紹的這些結(jié)構(gòu)體和協(xié)議，因為內(nèi)容較多，初次看完記不住是很正常的，在下文詳細(xì)講解的時候，回過頭來對照這些表格來理解是比較有幫助的。
打開Binder設(shè)備
任何進(jìn)程在使用Binder之前，都需要先通過open("/dev/binder")打開Binder設(shè)備。上文已經(jīng)提到，用戶空間的open系統(tǒng)調(diào)用對應(yīng)了驅(qū)動中的binder_open函數(shù)。在這個函數(shù)，Binder驅(qū)動會為調(diào)用的進(jìn)程做一些初始化工作。binder_open函數(shù)代碼如下所示：
static int binder_open(struct inode *nodp, struct file *filp) {struct binder_proc *proc;// 創(chuàng)建進(jìn)程對應(yīng)的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);// 鎖保護(hù) 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驅(qū)動中，通過binder_procs記錄了所有使用Binder的進(jìn)程。每個初次打開Binder設(shè)備的進(jìn)程都會被添加到這個列表中的。
另外，請讀者回顧一下上文介紹的Binder驅(qū)動中的幾個關(guān)鍵結(jié)構(gòu)體：
- binder_proc
- binder_node
- binder_thread
- binder_ref
- binder_buffer
在實現(xiàn)過程中，為了便于查找，這些結(jié)構(gòu)體互相之間都留有字段存儲關(guān)聯(lián)的結(jié)構(gòu)。
下面這幅圖描述了這里說到的這些內(nèi)容：
內(nèi)存映射（mmap）
在打開Binder設(shè)備之后，進(jìn)程還會通過mmap進(jìn)行內(nèi)存映射。mmap的作用有如下兩個：
- 申請一塊內(nèi)存空間，用來接收Binder通信過程中的數(shù)據(jù)
- 對這塊內(nèi)存進(jìn)行地址映射，以便將來訪問
binder_mmap函數(shù)對應(yīng)了mmap系統(tǒng)調(diào)用的處理，這個函數(shù)也是Binder驅(qū)動的精華所在（這里說的binder_mmap函數(shù)也包括其內(nèi)部調(diào)用的binder_update_page_range函數(shù)，見下文）。
前文我們說到，使用Binder機(jī)制，數(shù)據(jù)只需要經(jīng)歷一次拷貝就可以了，其原理就在這個函數(shù)中。
binder_mmap這個函數(shù)中，會申請一塊物理內(nèi)存，然后在用戶空間和內(nèi)核空間同時對應(yīng)到這塊內(nèi)存上。在這之后，當(dāng)有Client要發(fā)送數(shù)據(jù)給Server的時候，只需一次，將Client發(fā)送過來的數(shù)據(jù)拷貝到Server端的內(nèi)核空間指定的內(nèi)存地址即可，由于這個內(nèi)存地址在服務(wù)端已經(jīng)同時映射到用戶空間，因此無需再做一次復(fù)制，Server即可直接訪問，整個過程如下圖所示：
這幅圖的說明如下：
了解原理之后，我們再來看一下Binder驅(qū)動的相關(guān)源碼。這段代碼有兩個函數(shù)：
- binder_mmap函數(shù)對應(yīng)了mmap的系統(tǒng)調(diào)用的處理
- binder_update_page_range函數(shù)真正實現(xiàn)了內(nèi)存分配和地址映射
在開發(fā)過程中，我們可以通過procfs看到進(jìn)程映射的這塊內(nèi)存空間：
在我的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/binderPS：grep是通過通配符進(jìn)行匹配過濾的命令，“|”是Unix上的管道命令。即將前一個命令的輸出給下一個命令作為輸入。如果這里我們不加“ | grep xxx”，那么將看到前一個命令的完整輸出。
內(nèi)存的管理
上文中，我們看到binder_mmap的時候，會申請一個PAGE_SIZE(通常是4K)的內(nèi)存。而實際使用過程中，一個PAGE_SIZE的大小通常是不夠的。
在驅(qū)動中，會根據(jù)實際的使用情況進(jìn)行內(nèi)存的分配。有內(nèi)存的分配，當(dāng)然也需要內(nèi)存的釋放。這里我們就來看看Binder驅(qū)動中是如何進(jìn)行內(nèi)存的管理的。
首先，我們還是從一次IPC請求說起。
當(dāng)一個Client想要對Server發(fā)出請求時，它首先將請求發(fā)送到Binder設(shè)備上，由Binder驅(qū)動根據(jù)請求的信息找到對應(yīng)的目標(biāo)節(jié)點，然后將請求數(shù)據(jù)傳遞過去。
進(jìn)程通過ioctl系統(tǒng)調(diào)用來發(fā)出請求：ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr)
PS：這行代碼來自于Framework層的IPCThreadState類。在后文中，我們將看到，IPCThreadState類專門負(fù)責(zé)與驅(qū)動進(jìn)行通信。
這里的mProcess->mDriverFD對應(yīng)了打開Binder設(shè)備時的fd。BINDER_WRITE_READ對應(yīng)了具體要做的操作碼，這個操作碼將由Binder驅(qū)動解析。bwr存儲了請求數(shù)據(jù)，其類型是binder_write_read。
binder_write_read其實是一個相對外層的數(shù)據(jù)結(jié)構(gòu)，其內(nèi)部會包含一個binder_transaction_data結(jié)構(gòu)的數(shù)據(jù)。binder_transaction_data包含了發(fā)出請求者的標(biāo)識，請求的目標(biāo)對象以及請求所需要的參數(shù)。它們的關(guān)系如下圖所示：
binder_ioctl函數(shù)對應(yīng)了ioctl系統(tǒng)調(diào)用的處理。這個函數(shù)的邏輯比較簡單，就是根據(jù)ioctl的命令來確定進(jìn)一步處理的邏輯，具體如下:
- 如果命令是BINDER_WRITE_READ，并且
- 如果 bwr.write_size > 0，則調(diào)用binder_thread_write
- 如果 bwr.read_size > 0，則調(diào)用binder_thread_read
- 如果命令是BINDER_SET_MAX_THREADS，則設(shè)置進(jìn)程的max_threads，即進(jìn)程支持的最大線程數(shù)
- 如果命令是BINDER_SET_CONTEXT_MGR，則設(shè)置當(dāng)前進(jìn)程為ServiceManager，見下文
- 如果命令是BINDER_THREAD_EXIT，則調(diào)用binder_free_thread，釋放binder_thread
- 如果命令是BINDER_VERSION，則返回當(dāng)前的Binder版本號
這其中，最關(guān)鍵的就是binder_thread_write方法。當(dāng)Client請求Server的時候，便會發(fā)送一個BINDER_WRITE_READ命令，同時框架會將將實際的數(shù)據(jù)包裝好。此時，binder_transaction_data中的code將是BC_TRANSACTION，由此便會調(diào)用到binder_transaction方法，這個方法是對一次Binder事務(wù)的處理，這其中會調(diào)用binder_alloc_buf函數(shù)為此次事務(wù)申請一個緩存。這里提到到調(diào)用關(guān)系如下：
binder_update_page_range這個函數(shù)在上文中，我們已經(jīng)看到過了。其作用就是：進(jìn)行內(nèi)存分配并且完成內(nèi)存的映射。而binder_alloc_buf函數(shù)，正如其名稱那樣的：完成緩存的分配。
在驅(qū)動中，通過binder_buffer結(jié)構(gòu)體描述緩存。一次Binder事務(wù)就會對應(yīng)一個binder_buffer，其結(jié)構(gòu)如下所示：
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的進(jìn)程）中，包含了幾個字段用來管理進(jìn)程在Binder IPC過程中緩存，如下：
struct binder_proc {...struct list_head buffers; // 進(jìn)程擁有的buffer列表 struct rb_root free_buffers; // 空閑buffer列表 struct rb_root allocated_buffers; // 已使用的buffer列表 size_t free_async_space; // 剩余的異步調(diào)用的空間 size_t buffer_size; // 緩存的上限 ... };進(jìn)程在mmap時，會設(shè)定支持的總緩存大小的上限（下文會講到）。而進(jìn)程每當(dāng)收到BC_TRANSACTION，就會判斷已使用緩存加本次申請的和有沒有超過上限。如果沒有，就考慮進(jìn)行內(nèi)存的分配。
進(jìn)程的空閑緩存記錄在binder_proc的free_buffers中，這是一個以紅黑樹形式存儲的結(jié)構(gòu)。每次嘗試分配緩存的時候，會從這里面按大小順序進(jìn)行查找，找到最接近需要的一塊緩存。查找的邏輯如下：
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中的字段進(jìn)行相應(yīng)的更新：
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); }下面我們再來看看內(nèi)存的釋放。
BC_FREE_BUFFER命令是通知驅(qū)動進(jìn)行內(nèi)存的釋放，binder_free_buf函數(shù)是真正實現(xiàn)的邏輯，這個函數(shù)與binder_alloc_buf是剛好對應(yīng)的。在這個函數(shù)中，所做的事情包括：
- 重新計算進(jìn)程的空閑緩存大小
- 通過binder_update_page_range釋放內(nèi)存
- 更新binder_proc的buffers，free_buffers，allocated_buffers字段
Binder中的“面向?qū)ο蟆?/h2>
Binder機(jī)制淡化了進(jìn)程的邊界，使得跨越進(jìn)程也能夠調(diào)用到指定服務(wù)的方法，其原因是因為Binder機(jī)制在底層處理了在進(jìn)程間的“對象”傳遞。
在Binder驅(qū)動中，并不是真的將對象在進(jìn)程間來回序列化，而是通過特定的標(biāo)識來進(jìn)行對象的傳遞。Binder驅(qū)動中，通過flat_binder_object來描述需要跨越進(jìn)程傳遞的對象。其定義如下：
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), };當(dāng)對象傳遞到Binder驅(qū)動中的時候，由驅(qū)動來進(jìn)行翻譯和解釋，然后傳遞到接收的進(jìn)程。
例如當(dāng)Server把Binder實體傳遞給Client時，在發(fā)送數(shù)據(jù)流中，flat_binder_object中的type是BINDER_TYPE_BINDER，同時binder字段指向Server進(jìn)程用戶空間地址。但這個地址對于Client進(jìn)程是沒有意義的（Linux中，每個進(jìn)程的地址空間是互相隔離的），驅(qū)動必須對數(shù)據(jù)流中的flat_binder_object做相應(yīng)的翻譯：將type該成BINDER_TYPE_HANDLE；為這個Binder在接收進(jìn)程中創(chuàng)建位于內(nèi)核中的引用并將引用號填入handle中。對于發(fā)生數(shù)據(jù)流中引用類型的Binder也要做同樣轉(zhuǎn)換。經(jīng)過處理后接收進(jìn)程從數(shù)據(jù)流中取得的Binder引用才是有效的，才可以將其填入數(shù)據(jù)包binder_transaction_data的target.handle域，向Binder實體發(fā)送請求。
由于每個請求和請求的返回都會經(jīng)歷內(nèi)核的翻譯，因此這個過程從進(jìn)程的角度來看是完全透明的。進(jìn)程完全不用感知這個過程，就好像對象真的在進(jìn)程間來回傳遞一樣。
驅(qū)動層的線程管理
上文多次提到，Binder本身是C/S架構(gòu)。由Server提供服務(wù)，被Client使用。既然是C/S架構(gòu)，就可能存在多個Client會同時訪問Server的情況。 在這種情況下，如果Server只有一個線程處理響應(yīng)，就會導(dǎo)致客戶端的請求可能需要排隊而導(dǎo)致響應(yīng)過慢的現(xiàn)象發(fā)生。解決這個問題的方法就是引入多線程。
Binder機(jī)制的設(shè)計從最底層–驅(qū)動層，就考慮到了對于多線程的支持。具體內(nèi)容如下：
- 使用Binder的進(jìn)程在啟動之后，通過BINDER_SET_MAX_THREADS告知驅(qū)動其支持的最大線程數(shù)量
- 驅(qū)動會對線程進(jìn)行管理。在binder_proc結(jié)構(gòu)中，這些字段記錄了進(jìn)程中線程的信息：max_threads，requested_threads，requested_threads_started，ready_threads
- binder_thread結(jié)構(gòu)對應(yīng)了Binder進(jìn)程中的線程
- 驅(qū)動通過BR_SPAWN_LOOPER命令告知進(jìn)程需要創(chuàng)建一個新的線程
- 進(jìn)程通過BC_ENTER_LOOPER命令告知驅(qū)動其主線程已經(jīng)ready
- 進(jìn)程通過BC_REGISTER_LOOPER命令告知驅(qū)動其子線程（非主線程）已經(jīng)ready
- 進(jìn)程通過BC_EXIT_LOOPER命令告知驅(qū)動其線程將要退出
- 在線程退出之后，通過BINDER_THREAD_EXIT告知Binder驅(qū)動。驅(qū)動將對應(yīng)的binder_thread對象銷毀
再聊ServiceManager
上文已經(jīng)說過，每一個Binder Server在驅(qū)動中會有一個binder_node進(jìn)行對應(yīng)。同時，Binder驅(qū)動會負(fù)責(zé)在進(jìn)程間傳遞服務(wù)對象，并負(fù)責(zé)底層的轉(zhuǎn)換。另外，我們也提到，每一個Binder服務(wù)都需要有一個唯一的名稱。由ServiceManager來管理這些服務(wù)的注冊和查找。
而實際上，為了便于使用，ServiceManager本身也實現(xiàn)為一個Server對象。任何進(jìn)程在使用ServiceManager的時候，都需要先拿到指向它的標(biāo)識。然后通過這個標(biāo)識來使用ServiceManager。
這似乎形成了一個互相矛盾的現(xiàn)象：
解決這個矛盾的辦法其實也很簡單：Binder機(jī)制為ServiceManager預(yù)留了一個特殊的位置。這個位置是預(yù)先定好的，任何想要使用ServiceManager的進(jìn)程只要通過這個特定的位置就可以訪問到ServiceManager了（而不用再通過ServiceManager的接口）。
在Binder驅(qū)動中，有一個全局的變量：
static struct binder_node *binder_context_mgr_node;這個變量指向的就是ServiceManager。
當(dāng)有進(jìn)程通過ioctl并指定命令為BINDER_SET_CONTEXT_MGR的時候，驅(qū)動被認(rèn)定這個進(jìn)程是ServiceManager，binder_ioctl函數(shù)中對應(yīng)的處理如下：
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應(yīng)當(dāng)要先于所有Binder Server之前啟動。在它啟動完成并告知Binder驅(qū)動之后，驅(qū)動便設(shè)定好了這個特定的節(jié)點。
在這之后，當(dāng)有其他模塊想要使用ServerManager的時候，只要將請求指向ServiceManager所在的位置即可。
在Binder驅(qū)動中，通過handle = 0這個位置來訪問ServiceManager。例如，binder_transaction中，判斷如果target.handler為0，則認(rèn)為這個請求是發(fā)送給ServiceManager的，相關(guān)代碼如下：
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;} }結(jié)束語
本篇文章中，我們對Binder機(jī)制做了整體架構(gòu)和分層的介紹，也詳細(xì)講解了Binder機(jī)制中的驅(qū)動模塊。對于驅(qū)動之上的模塊，會在今后的文章中講解。
下一篇文章中，我們會詳細(xì)講解Android Binder機(jī)制的Framework層，敬請期待。
原文：http://qiangbo.space/2017-01-15/AndroidAnatomy_Binder_Driver/
總結(jié)
以上是生活随笔為你收集整理的理解Android Binder机制(1/3)：驱动篇的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Android系统中的进程管理：内存的回
- 下一篇： 理解Android Binder机制(3