前言

昨天正好有一个网友和我讨论一个问题，他给我看下面这个图，我说这个应该是Android 8.0以及之前版本的流程图。

Android 8.0以及之前的版本

Android 9.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资源

Android 9.0

Android 8.0

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驱动的代码注释非常完整，完全可以看注释学习。

[022]Android 9.0中Binder Driver改进点