3. Binder通信模型
理解Binder性能与阻塞问题，第一步不是看trace，而是把Binder通信模型中的四个角色摆正位置。很多“调用卡住”“线程池打满”“服务找不到”的问题，本质上是没有分清Client、Server、ServiceManager、Binder驱动各自负责什么、数据在哪一段流动、阻塞发生在哪一层。本节用一次完整的跨进程调用，把四者关系和调用链路串起来。
一、四个角色的职责边界
Binder不是简单的“客户端调服务端”，而是一个由内核驱动中转的C/S架构。四个角色的分工如下：
- Client（客户端）：发起调用的进程。它持有Server的Binder代理对象（BpBinder/Proxy），调用代理方法时，数据被封装成Parcel，通过ioctl交给Binder驱动。
- Server（服务端）：提供实际功能的进程。它把本地Binder实体（BBinder/Stub）注册到驱动，并启动Binder线程池，等待驱动投递请求。
- ServiceManager（服务管理器）：全局的“电话簿”，本身也是一个特殊的Server。它维护“服务名 → Binder句柄”的映射，负责服务的注册与查询。
- Binder驱动：位于内核态的中枢。它管理Binder节点、句柄、引用计数、线程池和事务队列，是Client与Server之间唯一的数据通道。
关键认知：Client和Server之间没有直接通道。所有跨进程数据都必须经过Binder驱动，驱动负责把Client的“句柄”翻译成Server的“实体”，并完成线程调度与唤醒。
二、四者关系与一次完整调用流程
下面这张图展示了四个角色的位置关系，以及一次getService加一次业务调用的完整数据流。注意箭头方向：Client先向ServiceManager查询，拿到句柄后再向Server发起业务调用，两次都经过Binder驱动。
把流程拆成可观察的步骤，便于后续定位阻塞点：
- 服务注册：Server启动时调用
addService，请求经驱动转发给ServiceManager，ServiceManager记录“服务名→句柄”。 - 服务查询：Client调用
getService，同样经驱动向ServiceManager查询，拿到目标服务的Binder句柄。 - 业务调用：Client用句柄构造Parcel，通过
ioctl(BINDER_WRITE_READ)把事务交给驱动。 - 驱动转发：驱动根据句柄找到Server的Binder节点，把事务放入其队列，并唤醒一个空闲Binder线程。
- 服务执行：Server的Binder线程从队列取出事务，调用
onTransact执行实际逻辑。 - 结果回传：返回值写入reply Parcel，经驱动回传给Client，Client线程被唤醒并继续执行。
三、关键参数与观察点
排查Binder问题时，下面这些参数和日志点是高频入口。它们分别对应四者关系中的不同环节：
| 观察对象 | 关键参数/命令 | 对应环节 | 异常含义 |
|---|---|---|---|
| Client | BpBinder::transact 耗时 |
发起事务 | 耗时高说明驱动或Server侧慢 |
| Binder驱动 | /sys/kernel/debug/binder/stats |
事务队列/线程 | 队列积压、线程耗尽 |
| Server | Binder线程数、onTransact耗时 |
服务执行 | 线程池打满导致新请求排队 |
| ServiceManager | service list |
注册/查询 | 服务未注册或查询超时 |
四、案例与常见误区
某应用调用系统服务时出现ANR，trace显示主线程卡在BpBinder::transact。按四者模型逐层排查：Client侧确实在等驱动返回；驱动stats显示目标Server的事务队列有积压；进一步看Server的Binder线程全部处于onTransact中，且其中一个线程在等一把应用层锁。结论是Server线程池被慢业务占满，新请求只能排队，Client主线程因此被拖住。这个案例说明：Client的阻塞，根因往往在Server或驱动侧。
常见误区一：认为Client和Server直接通信。实际上两者不共享内存，所有数据都经驱动拷贝与转发，驱动是唯一通道。
常见误区二：把ServiceManager当成普通服务。它本身也依赖Binder驱动，且在系统启动早期就已就绪，查询失败要先确认它是否可用。
常见误区三：只盯Client线程。Binder是同步调用，Client等待期间不消耗CPU，真正的问题常在Server线程池或驱动队列。
常见误区二：把ServiceManager当成普通服务。它本身也依赖Binder驱动，且在系统启动早期就已就绪，查询失败要先确认它是否可用。
常见误区三：只盯Client线程。Binder是同步调用，Client等待期间不消耗CPU，真正的问题常在Server线程池或驱动队列。
复盘方法：遇到Binder阻塞，按“Client发起 → 驱动队列 → Server线程 → 返回路径”四段拆解，分别用trace、binder stats、线程栈和日志验证。先确认卡在哪一段，再判断是线程不足、锁竞争、事务过大还是服务未注册，避免一上来就盲目加线程或改超时。
掌握四者关系后，后续分析Binder线程池、事务大小限制、oneway调用和死锁时，都能回到这张模型图上定位：数据从哪来、经过谁、卡在哪、由谁唤醒。这是Binder性能诊断的基础坐标系。