Binder通讯类图实战：一张图看懂跨进程调用与线程流转

Binder 系列第一篇把对象模型过了一遍，很多朋友看完表示逻辑链是清楚了，可一旦面对日志、堆栈和内核调试节点，还是分不清哪条消息在哪个端点之间流动。这一篇我干脆把重心放到通讯类图上，目标很直接：把一次跨进程调用画成一张带方向、带序号、带线程信息的图，让排查问题变成“看图找缺口”。

标题里的“通讯类图”，更准确的叫法是 UML Communication Diagram，早期也叫协作图。它和时序图一样能表达消息顺序，但更强调对象之间的结构关系，也会用编号表达先后。Binder 恰恰是多进程、多线程、多代理对象层层嵌套的机制，静态类图很难讲清楚“谁主动、谁被动、消息从哪根线程进去、又从哪根线程出来”，而通讯类图可以做到这一点。文章不会逐个念头文件，先从角色划分开始，最后落到一套可以照着画的实操方法。如果你是做系统服务开发、跨进程接口封装，或者正在被死锁、ANR、TransactionTooLargeException 折磨，这篇应该能帮你把碎片知识串起来。

1. 为什么建议先画通讯类图而不是类图

1.1 静态类图只能回答“有什么”，回答不了“怎么跑”

刚接触 Binder 的时候，大多数人第一件事是去搜类图，把 IBinder、BinderProxy、BBinder、Binder 这些类之间的关系画成继承树，觉得只要掌握了谁继承谁，就能理解 IPC。这种思路不能算错，但实战价值非常有限。静态类图描述的是编译期的结构关系，它回答的是“BinderProxy 持有一个 BpBinder”“JavaBBinder 继承自 BBinder”这类问题，可一旦运行起来，Binder 的真正难点全在动态过程里。

举个具体例子：同一个 Binder 实体，在客户端进程里表现为一个 handle，在服务端进程里表现为一个节点的引用，这两个“数字身份”之间怎么完成映射？一个调用线程发起 transact 之后，为什么有时候阻塞、有时候立刻返回？服务端收到消息时，到底是谁在调用 onTransact，是发起线程还是另一根 Binder 线程？这些问题在静态类图里根本找不到答案，因为答案存在于消息的流向、线程的睡醒状态和驱动内部的队列里。

所以我的建议很简单：先画通讯类图。把每个参与对象画成一个框，把对象之间的调用画成一条带箭头的线，按发生顺序标上 1、2、3，这样一次跨进程调用的全貌就出来了。不是为了画给别人看，是为了逼自己回答“这条调用到底经过谁”。

1.2 通讯类图比时序图更适合 Binder 的复杂场景

有人会问，那用时序图不也行吗？时序图确实更常见，画一根垂直的“生命线”，从上往下表示时间顺序，逻辑上更线性。但 Binder 场景有个麻烦：参与对象通常跨越两个用户态进程、一个内核态驱动，还可能涉及多个 Binder 线程。如果全用时序图，生命线一拉就是十几根，箭头交叉起来非常乱，而且进程边界和线程边界很难在一张图上表达清楚。

通讯类图则不同。它不强调严格的时间轴，而是把对象像节点一样平铺在图纸上，再用带序号的箭头表示消息的先后。这样一来，进程边界可以用一条粗虚线画出来，线程信息可以写在对象名后面，驱动处理可以画成中间的一个“路由节点”。你看图的时候，第一个注意到的是消息从哪个进程跨到哪个进程，而不是在长条生命线上找对应的时间点。

举一个典型调用为例，我画出来大概是这种感觉：

[调用进程:CallingThread] | | 1：XXServiceProxy.setFoo(data) v [调用进程:BinderProxy] | | 2：BinderProxy.transact(code, parcel) v [调用进程:NativeBpBinder] | | 3：IPCThreadState -> BC_TRANSACTION v [内核Driver路由] | | 4：BR_TRANSACTION 唤醒服务线程 v [服务进程:JavaBBinder::onTransact] | | 5：调用 Stub 业务方法 v [服务进程:具体服务实现]

这张图并不复杂，但信息量很大：谁触发的、消息顺序是什么、什么时候跨了进程、最终由哪根线程处理，一眼看全。后面讲细节的时候，我会反复回到这种画法。

2. 通讯类图里少不了的五个固定角色

2.1 客户端代理：BinderProxy 与 BpBinder 的关系

在 Java 层，客户端拿到的一个远程接口一般都实现了 IInterface 接口，内部持有一个 BinderProxy 对象，也就是 mRemote。这个 BinderProxy 并不是真正的远程对象，它只是客户端本地的一个代理壳。在 Native 层，真正干活的是 BpBinder，它保存着一个整数句柄 handle，这个 handle 相当于驱动为“某个远程 Binder 实体”在当前进程里分配的索引号。

画通讯类图的时候，我通常会把 BinderProxy 和 BpBinder 画在同一个进程框里，但标记成两个对象。原因是它们中间还隔着一层转换：BinderProxy 负责接收 Java 层的 Parcel 和 code，再转交给 BpBinder；BpBinder 不关心业务方法名，它只负责走 transact 流程。这个职责划分很重要，否则排错的时候你会困惑：到底是代理对象坏了，还是底层句柄失效了？

另一个容易忽略的点是 handle 是“进程相关”的。同一个 Binder 实体，在进程 A 里对应的可能是 handle 0x12，在进程 B 里对应的可能是 handle 0x35。所以画图时，如果你要把 handle 标在 BpBinder 旁边，必须同时标注是哪个进程的视角，否则别人看图会以为 handle 全局唯一，这个误解在分析抓取到的 binder 日志时非常致命。

2.2 线程上的关键桥梁：ProcessState 与 IPCThreadState

很多人看 Binder 源码时有一个疑问：JNI 层明明有 BinderProxy，为什么底层还要绕一圈 ProcessState 和 IPCThreadState？原因很简单，驱动不认 Java 对象，只认文件描述符和一块内存映射区域。ProcessState 负责在进程启动时打开 Binder 设备节点，做一次 mmap，把内核分配的缓冲区映射到用户空间；而 IPCThreadState 则是线程级别的状态保存者，每个线程自己维护一份，专门负责向驱动写 BC_命令、读取 BR_命令。

画通讯类图的时候，这两个对象不能省。它们是用户态和内核态之间的“海关”，所有请求数据和返回数据都要从它们手里过。

我还想强调一个实操经验：IPCThreadState 是线程局部存储的，同一个进程里的不同线程各自持有独立实例。也就是说，消息从客户端哪个线程发出去，返回消息通常也会回到那个线程。如果服务端处理很慢，客户端发起线程就会一直在 waitForResponse 里等着。这个“线程绑定”特性是理解 Binder 卡顿和死锁的基础，后面第 4 部分会专门展开。

2.3 驱动侧角色：binder_node、binder_ref 与 binder_proc

驱动内部其实维护了一张庞大的映射表，通讯类图里不需要把所有内部对象都画出来，但至少要画出三个概念：binder_node、binder_ref 和 binder_proc。

binder_node 是“某个进程内部已经注册的 Binder 实体”在内核中的节点。当一个进程创建一个 Binder 对象并注册到驱动时，内核就会为它分配一个 node。binder_ref 则是“另一个进程对某个 node 的引用”，每种引用都关联着一个句柄 handle。binder_proc 代表一个进程自身的驱动上下文，它挂接着这个进程所有的线程、节点和引用信息。

在通讯类图里，我习惯把驱动画成一个整体阴影节点，名字叫“Driver: route”，然后在连接线上标注“根据 ref 找到目标 node”。这样可以避免把内核内部关系画得过于复杂，同时保留最关键的信息：消息不是直接从一个 BinderProxy 跳到另一个 JavaBBinder 的，中间必须经过驱动查表、搬运数据这一步。

2.4 服务端核心：BBinder、JavaBBinder 与 Stub

服务端的情况和客户端对称。Java 层里，接口的 Stub 类通常继承自 Binder，而 Binder 内部又持有 Native 层的 BBinder 派生对象。具体到 Android 的 JNI 实现，是一个叫 JavaBBinder 的 Native 对象，它把 Native 层的 Binder 消息转回 Java 层的 onTransact 方法。

通讯类图上，服务端的主干是：驱动把事务投递给某根空闲的 Binder 线程，这根线程执行 BBinder::transact，内部再分发到 JavaBBinder::onTransact，最后由 Stub 的静态方法根据 code 找到对应业务方法。务必记住，服务端执行业务方法的线程并不是客户端那个线程，而是服务端进程 Binder 线程池里被驱动随机选中/唤醒的一根线程。这一点画图时我会用不同的线程标签来区分，避免产生“客户端和服务端共用一根线程”的错误直觉。

2.5 双向通信里容易漏掉的 Callback 代理角色

前面四个角色是同步调用场景的主角，但真实系统里还有大量回调场景，比如上层注册一个 IPC 回调对象，系统服务在合适的时机反向调用。这时代理关系会反转：系统服务变成发起方，而客户端变成了被调用方。

用通讯类图表达这个场景时，你会看到一条从服务端指向客户端进程的箭头。很多新手画的回调图里没有这条反向箭头，所以看日志时总觉得“服务端明明调了方法，为什么没反应”。原因就是回调对象也是一个 Binder 实体，需要客户端先把它注册到系统服务里，服务端才持有它的代理。画图时如果把回调注册那一笔漏掉，整个环就断了。

3. 以一次普通调用为线索，画通完整通讯类图

3.1 第一步：客户端手里先要有一个“可调用目标”

在 Java 层，调用远程接口的第一步是先持有 IInterface 的子类代理。这个代理通常通过 系统服务查询 得到，查询本质也是一次 Binder 调用。查询返回的 IBinder 对象在本地被包装成 BinderProxy，最终变成一个具体的 Proxy 类，比如某个接口的 Stub.asInterface 返回结果。

画这一阶段时，我会先把“调用者线程”作为第一个对象框，然后画它持有的 Proxy 对象，并标注 Proxy 内部的 mRemote 指向 BinderProxy。这里有个小误区：有些图把“ServiceManager 查询”画成一个独立对象，误以为每次调用都要经过 ServiceManager。实际上 ServiceManager 只负责第一次“寻址”，拿到 Binder 句柄之后就退出链路了，后续调用直接走驱动转发，不再经过 ServiceManager。所以安装工具类图时，查询阶段用虚线表示即可，表示“只发生一次，不参与后续事务”。

3.2 第二步：把业务方法转换成 BC_TRANSACTION

调用方法最终会走向 BinderProxy.transact()，接着是 Native BpBinder::transact()，然后进入 IPCThreadState::transact()。这里最重要的动作是 writeTransactionData()，它会填写一个 binder_transaction_data 结构，包括目标句柄、方法 code、数据 Parcel 的内存地址，以及标志位 flags。

同步调用时，IPCThreadState 接着调用 waitForResponse()，把自己阻塞起来等待驱动的回复。如果 flags 里有 TF_ONE_WAY，那就不等回复，直接返回。很多时候系统服务的代码看起来像同步，但实际误传了 oneway，导致调用方没有拿到结果，这类问题不画图很难发现。

代码简写示意一下这个阶段的核心结构：

// 简化示意，真实实现还包含更多异常处理 status_t IPCThreadState::transact( int32_t handle, uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags) { writeTransactionData(BC_TRANSACTION, flags, handle, code, data, nullptr); if ((flags & TF_ONE_WAY) != 0) { waitForResponse(nullptr); return NO_ERROR; } return waitForResponse(reply); }

这段代码最值得在通讯类图上注意的是“写数据”和“等数据”分离。客户端线程先向驱动写入 BC_TRANSACTION，然后阻塞在 read 侧等待 BR_REPLY。任何一条消息要经过驱动，都必须先经过这一写一等。

3.3 第三步：驱动根据引用找到服务端并唤醒线程

binder_transaction_data 写入驱动后，内核开始查表。首先是拿到句柄对应的 binder_ref，再通过 ref 找到指向的 binder_node，接着找到 node 所属的进程（binder_proc），最后把事务挂到目标进程的待处理队列里。

这个过程中，驱动还需要挑选一根服务端线程来处理事务。正常情况下，服务端进程在启动时会通过 ProcessState 启动一组 Binder 线程池，这些线程都在 binder_read() 里等待。驱动从中找出一个空闲的 Binder 线程，把事务投递给它，然后唤醒它。服务端线程醒来后会读到一个 BR_TRANSACTION 命令，随即执行到 BBinder 的 onTransact。

画图时我会在驱动节点和目标进程之间加一条箭头，标注“BR_TRANSACTION”。然后画两根线程：一根是被唤醒前的“沉睡 Binder 线程”，一根是唤醒后正在执行 onTransact 的“活跃 Binder 线程”。这样就能清楚解释为什么服务端方法的调用栈顶端往往是 IPCThreadState::getAndExecuteCommand，而不是客户端的调用栈。

3.4 第四步：同步返回路径与 oneway 的特殊分支

服务端处理完业务后，onTransact 会返回一个状态码。如果事务不是 oneway，服务端线程会构造一个 reply Parcel，并且向驱动发送 BR_REPLY/BC_REPLY 相关逻辑，最终驱动把 reply 数据搬回客户端客户端发起线程。客户端线程从 waitForResponse 中醒过来，拿到返回数据，一次完整的事务才算结束。

这张“服务端回程”在通讯类图上很容易画漏。很多人画 Binder 调用图，只画客户端到服务端的箭头，不画服务端回客户端的箭头，结果排查超时问题时总是盯着请求方向，忽略 reply 方向可能阻塞或丢失的情况。同步调用一定是两条箭头：去程和回程，二者缺一不可。

oneway 则是另一条分支。它的特点是客户端发完就结束了，不等待回执，所以服务端也不能传回常规 reply。通讯类图里遇到 oneway，我会把回程箭头直接去掉，并用一条灰色虚线表示“无回复”。需要注意，即使 oneway 调用在驱动内部也会构造一个事务对象，服务端如果处理慢，依旧可能堆积 pending 事务，并不是说 oneway 就一定安全。

4. 通讯类图在问题排查中的实际用法

4.1 在通讯类图上找到死锁环

Binder 死锁是系统服务开发里最隐蔽的一类问题，靠肉眼读线程 dump 往往不如靠一张通讯类图直接。举个例子，客户端线程 A 持有一个业务锁 L1，接着在锁内发起 Binder 同步调用，等待服务端返回；服务端线程 B 也持有另一把锁 L2，处理调用时需要反向调用客户端的一个回调接口，而这个回调最终又需要获取锁 L1。结果就是 A 等 B 的回复，B 等 A 的锁，形成一个跨进程的环。

在通讯类图上，你可以把两条调用链画出来：一条是从 A 发到服务端的实线箭头，另一条是服务端返回到客户端的箭头。当这两条箭头形成一个环形路径，并且你确认每个节点都在同步等待时，就能基本判定为 Binder 死锁。再配合线程 dump 里显示的“waiting on binder transaction”状态，定位就会非常快。

排查技巧上，我习惯给每个对象框标注线程 tid。两个调用如果发生在同一根线程上，就不可能形成真正的并行死锁环，而只有跨线程、跨进程形成的环，才是重点怀疑对象。

4.2 TransactionTooLargeException 的本质是“搬运能力不足”

关于 Binder 事务的缓冲区大小，最常见的就是 TransactionTooLargeException。很多人以为是服务端没处理好异常，实际上在通讯类图里它清清楚楚是“发起消息这条边的问题”。

Binder 驱动在进程初始化时会通过 mmap 映射一块内存，常规配置下总容量约 1MB，但这并不意味着你可以一次传 1MB。因为驱动在传输时，同一个缓冲区还要兼顾一些元数据和引用对象，实际能塞进一个 Parcel 的数据量远小于整个映射区。经验上，单个 Binder 事务数据一旦超过约 300KB 到 500KB，就已经开始逼近危险线，接近或超过 1MB 几乎必然触发 TooLarge 异常。

画图的时候，我会在客户端发起那条箭头上标记“data size”，再在驱动节点旁标“buffer limit”。如果箭头上的数据量明显大于限制，问题位置一目了然，根本不需要去服务端堆栈里翻。这类问题常见的解决办法有三个：把大对象拆分成多次调用、改用文件描述符传共享内存、或者用匿名共享内存配合传 memfd 句柄，让接收方按需读取。

下面这个表格是我排障时常用的判断依据：

4.3 回调泄漏：通讯图里的反向箭头没有及时擦除

回调场景的排查是另一个重灾区。客户端把 Callback 注册给系统服务后，系统服务内部会持有这个 Callback 对应的 Binder 代理。从客户端的角度来看，系统服务持有了一个“远程 Binder 实体”的引用，这会阻止客户端释放相应的 Binder 节点。

在通讯类图上，这个关系是一条从服务端指向客户端的长期箭头。如果逻辑设计上没有对应的“反注册”调用，那么这条箭头永远不会消失，客户端进程对应的 Binder 节点和内核引用也就不会被回收。时间长了，系统服务里缓存了无数回调引用，内存和线程量同步上涨，最终表现就是进程越来越大。

排查回调泄漏时，我一般会先画一张带生命周期的通讯类图，在回调箭头两端分别标注“注册”和“反注册”动作。如果图上只有注册没有反注册，那就找到了问题点。编码习惯上，建议注册时保存对应的 unbind 回调引用，并在组件销毁时显式清理，不要依赖进程退出自动回收。

5. 画 Binder 通讯类图的一些实操建议

5.1 一套我自己常用的绘图约定

画 Binder 通讯类图没有什么国际标准，但一套稳定的符号约定可以让你少踩很多坑。我平时用的规则很简单：矩形表示对象或代理，粗虚线框表示进程边界，箭头直线表示用户态直接调用，穿过驱动节点的线表示经驱动转发。消息顺序用数字标在箭头上，线程信息直接写在对象名里。

一个典型节点的写法类似这样：

[ClientProcess / UIThread / tid=101]

这样一张图就算画完，别人也能快速知道这条消息来自哪个进程的哪根线程。对多线程并发场景，我还习惯用颜色区分“正在等待”和“正在执行”，但这个看个人喜好，不用强求。关键是信息维度齐全。

5.2 用调试信息反推并验证通讯类图

画出来的图如果不验证，那就只是想象图。Binder 驱动提供了一些调试接口，可以导出每个进程的 binder 状态，包括线程列表、节点引用、事务队列等信息。通过解析这些数据，你可以验证自己画的消息路径是否符合实际。

举个例子，如果客户端报卡顿，你可以在调试节点里看客户端对应进程的 Binder 线程状态，查它的最后一次 transaction 是否仍处于等待回复状态；再看服务端进程的目标线程，确认它是否已经处理完该事务。如果客户端一直等待、服务端却没有新事务，那说明消息可能根本没有送达，值得检查句柄或引用关系。反过来，如果服务端线程正卡在另一个回调上，那问题范围就转到了回调链路。

把调试信息里读到的“进程状态”和“线程状态”回到图上，图就不再是静态结构，而是一个能反映系统运行瞬间的“状态快照”。

5.3 画图时最容易犯的几个错误

第一个错误，是把 Binder 实体和进程画成同一个概念。Binder 实体是进程里的一个对象，不是整个进程。通讯类图里箭头不能直接画成“进程 A -> 进程 B”，而必须落到对象级，比如“BpBinder -> JavaBBinder”。否则丢掉了代理和实体的对应关系，后续排查无法定位。

第二个错误，是忽略了线程标签。Binder 的高并发特性决定了同一时间点上可能有多条事务并行，如果不标注线程，图上的箭头顺序可能很乱，很容易把不同线程的消息当成同一根线程上的调用来分析。

第三个错误，是漏画 oneway 的语义。同步调用有回程，异步调用没有，两种语义在通讯类图上必须明确区分。否则有人看到一条没有返回箭头的路径，会以为数据丢了，实际只是本来就没有回包。

这几个坑我都踩过。尤其是第一类，刚开始画图时总喜欢把两个进程之间画一条粗箭头，后来发现这种图对事务大小、句柄映射和线程唤醒这些关键细节完全没有解释力，才改成对象级建模。

写在后面

到现在，一张 Binder 通讯类图应该包括客户端代理、线程边界、驱动路由、服务端 Stub、回调反向链路、消息序号和线程标签这几大要素。我自己坚持的习惯是，任何一个跨进程接口，不管多简单，都先花十几分钟把图补全，再用调试信息验证箭头方向和线程状态。很多隐藏 Bug 的出现，往往不是因为代码写错，而是因为你心里少画了一条箭头。把这条箭头补上，问题通常也就浮出水面了。