这个问题最早是由接电话重启的现象暴露出来的，当时看到异常信息是Native crash，栈如下：
问题的根本原因是binder driver的协议处理对于BC_FREE_BUFFER的处理没有考虑到同步binder call嵌套异步binder call的情况，导致协议处理紊乱，最终解决方案如下，将BC_FREE_BUFFER时move async transaction的操作，由当前线程的todo list更改为进程的todo list，保证嵌套binder call的情况下也能正确处理，并且达到负载均衡，提升吞吐量的目的：
<a href="https://android-review.googlesource.com/#/c/305049/">https://android-review.googlesource.com/#/c/305049/</a>
咋一看Native Crash的调用栈让人有点摸不着头脑，好好的binder thread怎么自己abort掉了？先看看对应的代码：
可以看到是getAndExecuteCommand();的返回值有问题，再继续看看里面影响返回值的地方：
有两个地方会影响这个返回值，分别是result = talkWithDriver();和result = executeCommand(cmd);
通过log和coredump确认是在result = executeCommand(cmd);里面出了问题，因为打debug log还提交了两个AOSP change修正一些原生打log时的问题，有兴趣的同学可以看一下：
<a href="https://android-review.googlesource.com/#/c/291187/">https://android-review.googlesource.com/#/c/291187/</a>
<a href="https://android-review.googlesource.com/#/c/294368/">https://android-review.googlesource.com/#/c/294368/</a>
具体出错时的cmd是BR_TRANSACTION_COMPLETE，这里引出第一个一疑问，为什么会从driver里面拿回来一个单独的BR_TRANSACTION_COMPLETE？
想要理解出错的场景，我们需要先知道binder call的协议及其执行流程：
1、binder协议分两种，命令协议（BinderDriverCommandProtocol）和返回协议（BinderDriverReturnProtocol）
我们先看一下这些协议的定义：
看了上面一堆的协议定义，让人有点害怕，不过不用担心，这次我们只讨论正常binder call的几个关键协议，其他初始化的，增加binder线程的，死亡通知的，对象生命周期管理的，错误相关的都先不讨论，另外需要说明一点，BinderDriverCommandProtocol的所有协议都是发给binder driver的，BinderDriverReturnProtocol 的所有协议都是binder driver发给交互线程的。
下面我们先切入一个正常同步binder call的执行流程：
然后再看一个正常的异步binder call的执行流程，异步binder call就是ONE WAY的，不需要等待reply：
相对于同步的binder call，异步的简单多了，接下来再看一下异步binder call触发同步binder call的执行流程，这个稍微复杂点：
看完这个图有些同学可能会问，时序图中每次TRANSACTION或者REPLY结束之后都有一个BC_FREE_BUFFER，它的作用是什么？
答案是每次的BR_TRANSACTION或者BR_REPLY binder driver都会为它们找一块内核缓冲区承载binder通信的数据，并通过更新页表的方式与之前mmap的内存地址对应上，所以接受BR_TRANSACTION或者BR_REPLY的线程需要在每次处理完之后告诉binder driver释放这块区域。
看完异步触发同步的流程之后我们再看一个正常的连续两个异步触发一个同步和一个异步的执行流程，看到这的同学不用害怕，后面不会再看更复杂的了：
有了上面的储备知识之后，我们就可以反推出问题时多一个BR_TRANSACTION_COMPLETED的的场景了，如下是最早的推论流程：
但是这个推论有一个问题，如何让server binder thread todo list里面先有一个异步的BR_TRANSACTION？
正常情况下异步的BR_TRANSACTION是不会直接放到binder thread的todo list里的，如果是实体对象（target_node）的第一个BR_TRANSACTION，会先放到proc的todo list里，如果是第二个或者更多，会放到target_node的async_todo list里，所以这个问题分析到这里感觉有些走不通了，但是直觉告诉我上面的场景分析是靠谱的，一定还有其他路径可能执行到上面的问题场景，接下来就继续分析binder driver的源码，苦读之后终于发现了新大陆，原来BC_FREE_BUFFER除了会释放内核缓冲区，还有一个作用就是将同一个实体对象（target_node）的其他异步transaction放入当前binder thread的todo list中，使其free buffer之后就可以从自己的todo list中获取到异步transaction而直接返回到用户空间执行，好了到这里我们在逻辑上就能完全解释通上面出问题的场景了：
这里对于同一个实体对象的连续异步transaction都绑定到了同一个处理线程，好处是连续异步transaction不会影响其他同步的transaction，减少一定的线程切换和唤醒，但这带来了一些潜在的问题，没有负载均衡，可能造成一个线程忙死，其他线程空闲，另外连续的异步transaction会降低后续同步transaction的吞吐量，除此之外还有一个最严重的问题就是无法处理同步嵌套异步的case。
有了上面的一系列理论基础和推论，接下来就通过添加一些debug log来验证和确认这个问题，debug log的change参考如下链接：
<a href="http://git.xiaomi.com:8660/#/c/57748/">http://git.xiaomi.com:8660/#/c/57748/</a>
通过debug log获取到在processPendingDerefs里析构BBinder对象，并发起同步binder call的调用栈：
processPendingDerefs过程中有向binder driver write BC_FREE_BUFFER，并且target_node->async_todo中有transaction等待处理，同时在processPendingDerefs中又发起同步的binder call来write BC_TRANSACTION，从而在处理BC_FREE_BUFFER的时候将target_node->async_todo中的transaction放入thread的todo中，如下是出问题之前free buffer的调用栈：
出问题时的调用栈和aborting log验证了前面的分析：
最终出问题的执行流程如下，这是上面流程图的一个演化版：