前言
昨天正好有一个网友和我讨论一个问题，他给我看下面这个图，我说这个应该是Android 8.0以及之前版本的流程图。Android 9.0之后已经不是这样子了，Android 9.0之后版本的流程图应该是这样子的。
对比两幅图，大家可以明显的看到，第2步协议BR_TRANSACTION_COMPLETE，被推迟到了第5步。
Android 8.0和9.0代码对比
我们对比8.0和9.0的代码看看，首先先看看BR_TRANSACTION_COMPLETE是怎么来的。两者的代码基本一致，我们需要找到BINDER_WORK_TRANSACTION_COMPLETE是哪里发出来的?
//android 8.0
static int binder_thread_read(struct binder_proc *proc,
struct binder_thread *thread,
binder_uintptr_t binder_buffer, size_t size,
binder_size_t *consumed, int non_block)
{
....省略部分代码
case BINDER_WORK_TRANSACTION_COMPLETE: {
cmd = BR_TRANSACTION_COMPLETE;//这个就是8.0的BR_TRANSACTION_COMPLETE（第2步）
if (put_user(cmd, (uint32_t __user *)ptr))
return -EFAULT;
ptr += sizeof(uint32_t);
binder_stat_br(proc, thread, cmd);
list_del(&w->entry);
kfree(w);
binder_stats_deleted(BINDER_STAT_TRANSACTION_COMPLETE);
} break;
//android 9.0
static int binder_thread_read(struct binder_proc *proc,
struct binder_thread *thread,
binder_uintptr_t binder_buffer, size_t size,
binder_size_t *consumed, int non_block)
{
....省略部分代码
case BINDER_WORK_TRANSACTION_COMPLETE: {
binder_inner_proc_unlock(proc);//这是唯一的差别
cmd = BR_TRANSACTION_COMPLETE;//这个就是9.0的BR_TRANSACTION_COMPLETE（第5步）
if (put_user(cmd, (uint32_t __user *)ptr))
return -EFAULT;
ptr += sizeof(uint32_t);
binder_stat_br(proc, thread, cmd);
kfree(w);
binder_stats_deleted(BINDER_STAT_TRANSACTION_COMPLETE);
} break;
从下面代码可以发现，BINDER_WORK_TRANSACTION_COMPLETE发送的方式有点差异
8.0的代码：
因为在一次binder_ioctl_write_read中执行完binder_thread_write，就会执行binder_thread_read，所以BINDER_WORK_TRANSACTION_COMPLETE就会马上被读到，也就是会第二步就会立刻执行BR_TRANSACTION_COMPLETE。
//android 8.0 此代码运行在client端的binder_thread_write中
//发送给server端的BINDER_WORK_TRANSACTION，server会读到这个发起第3步到第5步
t->work.type = BINDER_WORK_TRANSACTION;
list_add_tail(&t->work.entry, target_list);
//发送给client端的BINDER_WORK_TRANSACTION_COMPLETE
tcomplete->type = BINDER_WORK_TRANSACTION_COMPLETE;
list_add_tail(&tcomplete->entry, &thread->todo);
//发现server端的进程休眠
if (target_wait)
wake_up_interruptible(target_wait);//唤醒server端的线程
return;
9.0的代码：
//android 9.0 此代码运行在client端的binder_thread_write中
tcomplete->type = BINDER_WORK_TRANSACTION_COMPLETE;
if (reply) {
...
//这是server端返回给client之后给自己发的BINDER_WORK_TRANSACTION_COMPLETE，也就是9.0图中第4步
binder_enqueue_thread_work(thread, tcomplete);
} else if (!(t->flags & TF_ONE_WAY)) {
...
/*
* Defer the TRANSACTION_COMPLETE, so we don't return to
* userspace immediately; this allows the target process to
* immediately start processing this transaction, reducing
* latency. We will then return the TRANSACTION_COMPLETE when
* the target replies (or there is an error).
*/
//这个代码就是和8.0中list_add_tail(&tcomplete->entry, &thread->todo)类似
//这是client端发送给server之后给自己发的BINDER_WORK_TRANSACTION_COMPLETE，也就是9.0图中第5步
binder_enqueue_deferred_thread_work_ilocked(thread, tcomplete);
}
我们先来翻译一下中间那段长长的注释：
/*
* 推迟TRANSACTION_COMPLETE，我们就不需要立刻返回到用户空间。
* 这样子就允许目标进程可以立刻的处理这次失误，减少延迟。
* 我们将会目标进程的回复之后再去返回TRANSACTION_COMPLETE
*/
而且我们可以发现9.0中第4步和第5步，虽然都是发送BINDER_WORK_TRANSACTION_COMPLETE，但是两者调用的方法不同，binder_enqueue_deferred_thread_work_ilocked比binder_enqueue_thread_work_ilocked少调用thread->process_todo = true；其实代码注释写很明白了，两个方法的区别，我就不翻译了。
/**
* Adds the work to the todo list of the thread. Doesn't set the process_todo
* flag, which means that (if it wasn't already set) the thread will go to
* sleep without handling this work when it calls read.
*/
static void
binder_enqueue_deferred_thread_work_ilocked(struct binder_thread *thread,
struct binder_work *work)
{
binder_enqueue_work_ilocked(work, &thread->todo);
}
/**
* Adds the work to the todo list of the thread, and enables processing
* of the todo queue.
*/
static void
binder_enqueue_thread_work_ilocked(struct binder_thread *thread,
struct binder_work *work)
{
binder_enqueue_work_ilocked(work, &thread->todo);
thread->process_todo = true;
}
简单小结
1.binder_enqueue_thread_work_ilocked中，因为执行thread->process_todo = true，就会让这次binder_ioctl_write_read中执行完binder_thread_write，立刻执行完binder_thread_read，也就是立刻执行BINDER_WORK_TRANSACTION_COMPLETE
2.binder_enqueue_deferred_thread_work_ilocked中，因为没有执行thread->process_todo = false，就会让这次binder_ioctl_write_read中执行完binder_thread_write，在binder_thread_read中休眠，延迟执行BINDER_WORK_TRANSACTION_COMPLETE。
没有执行thread->process_todo = true，为什么会导致如何binder_thread_read休眠？
从下面的代码也可以看的比较清楚了，thread->process_todo == false导致了binder_has_work_ilocked为false，从而导致了binder_wait_for_work中设置当前线程为可中断的状态，进入休眠。
static int binder_thread_read(struct binder_proc *proc,
struct binder_thread *thread,
binder_uintptr_t binder_buffer, size_t size,
binder_size_t *consumed, int non_block)
{
...
if (non_block) {
...
} else {
//休眠在这里, wait_for_proc_work为false
ret = binder_wait_for_work(thread, wait_for_proc_work);
}
...
}
static int binder_wait_for_work(struct binder_thread *thread,
bool do_proc_work)
{
...
for (;;) {
//设置线程状态为可中断状态
prepare_to_wait(&thread->wait, &wait, TASK_INTERRUPTIBLE);
//binder_has_work_ilocked是false，所以就会休眠了
if (binder_has_work_ilocked(thread, do_proc_work))
break;
...
schedule();//让出cpu，让当前线程休眠
...
}
...
return ret;
}
static bool binder_has_work_ilocked(struct binder_thread *thread,
bool do_proc_work)
{
//thread->process_todo是false，
//do_proc_work是false
//thread->looper_need_return是false，所以整体返回false。
return thread->process_todo ||
thread->looper_need_return ||
(do_proc_work &&
!binder_worklist_empty_ilocked(&thread->proc->todo));
}
以上就是9.0中如何把8.0的第2步推迟到9.0的第5步执行的方法。
思考：为什么Binder驱动要这样子改进？
我个人猜想有两个原因：
1.减少binder_ioctl_write_read的次数，从8.0的两次变成一次
因为每次binder_ioctl_write_read就是一次从用户空间和内核空间的上下文切换，这个切换是需要消耗cpu资源
2.让发起Binder通信的Client端进程中Binder服务端的binder_thread_read的优先处理
这句话是不是有点绕，其实一个进程，可能同时既是Binder调用的client，又是Binder调用的server端。
假设这个进程的两个线程：
线程1：作为client端要执行binder_thread_read
线程2：作为server端要执行binder_thread_read
因为在binder_thread_read中是有锁的，binder_inner_proc_lock(proc)，这个锁是每个进程一个锁proc。
如果按照8.0的设计，让线程1执行完释放锁，再去执行线程2，
如果按照9.0的设计，让线程1立刻休眠，释放锁，让线程2优先处理。
小结
1.Binder驱动9.0之后的改动比较大，很多锁都变化了，死亡通知的嵌套也改了，对于初学者来说，目前网上资料数据都是按照老的版本代码讲的，千万别搞错了，否则容易产生误会。
2.对于初学者，最好的还是看老的版本Binder驱动，把核心了解清楚了以后，再看android 9.0之后的源码，因为这个版本之后Binder驱动的代码注释非常完整，完全可以看注释学习。