1. Binder 同步调用机制解析
Binder 是 Android 中进程间通信（IPC）的核心机制，其同步调用模式在驱动层实现了一套完整的请求-应答流程。理解同步调用的交互流程、等待与唤醒机制以及阻塞对性能的影响，是掌握“同步转异步”的基础。
1.1 同步调用核心流程
一次完整的 Binder 同步调用涉及三个参与者：客户端进程、Binder 驱动、服务端进程。调用流程如下：
- 客户端通过 Binder 代理（Proxy）发起
transact()调用，将请求数据写入parcel。 - 驱动接收请求后，在调用线程的
task_struct中记录等待状态，并将请求数据拷贝到服务端进程的接收缓冲区。 - 驱动唤醒服务端中等待处理请求的线程（通过 Binder 线程池）。
- 服务端处理请求，将回复数据写回驱动，同时设置
reply标识。 - 驱动将回复数据拷贝回客户端进程空间，并唤醒客户端中阻塞的调用线程。
- 客户端调用线程由 TASK_INTERRUPTIBLE 恢复为 TASK_RUNNING，获取回复数据后返回。
关键数据结构： Binder 驱动内部使用
struct binder_transaction 描述一次事务，使用 binder_thread 和 binder_proc 管理进程/线程的等待队列。
1.2 等待与唤醒机制
驱动层通过 binder_wait_for_work() 实现线程的挂起和恢复。核心逻辑如下表所示：
| 阶段 | 驱动动作 | 线程状态 |
|---|---|---|
| 发起请求后 | 将当前线程加入 proc->waiting_threads 队列，循环检查是否有事务完成 | TASK_INTERRUPTIBLE |
| 服务端提交回复 | 驱动找到等待的客户端线程，将其从等待队列移除，设置事务结果 | TASK_RUNNING |
| 回复返回后 | 清除等待标记，准备处理下一次调用 | 正常运行 |
注意： 同步调用期间，客户端线程完全挂起，无法处理同一进程中其他 Binder 请求或主线程消息循环。若该线程是 UI 线程，将直接引发 ANR（Application Not Responding）。
1.3 同步阻塞对性能的影响
- 线程资源占用： 每个同步调用独占一个客户端线程直到返回，线程池容量有限，高并发下易导致线程耗尽。
- 上下文切换开销： 单次同步调用产生至少 2 次系统调用（ioctl BC_TRANSACTION + ioctl BC_REPLY），驱动内部涉及多次链表操作和睡眠/唤醒，CPU 开销不可忽视。
- 响应时延放大： 如果服务端处理耗时 5ms，客户端线程在此期间完全阻塞；若服务端被更优先的任务抢占，阻塞时间可能达到几十毫秒。
- 优先级翻转风险： 低优先级服务端进程若被抢占，可能导致高优先级客户端线程长时间等待。
性能指标参考： 在一次典型的跨进程简单 Binder 同步调用（数据量小于 128 字节）中，纯 IPC 耗时约 30~80 μs（视 CPU 频率和调度延迟）。其中驱动处理占 50% 以上，上下文切换约占 20%。
1.4 关键代码路径
驱动侧核心函数为 driver/android/binder.c 中的 binder_thread_read() 和 binder_transaction()。客户端调用栈简化如下：
// 客户端 Binder 代理调用
status = remote->transact(TRANSACTION, data, &reply, 0);
// ↓ 进入内核
ioctl(fd, BINDER_WRITE_READ, &bwr);
// ↓ 驱动入口
binder_ioctl()
binder_ioctl_write_read()
binder_transaction() // 发送请求，唤醒服务端
binder_thread_read() // 阻塞等待回复
binder_wait_for_work() // 线程休眠
分析建议： 使用
systrace 或 perfetto 抓取 Binder 同步调用时，可观察 CPU 调度片段中 Binder transaction 及其等待时长，验证阻塞对线程的影响。