3. Binder通信流程：Client-Server通信模型、Binder事务（Transaction）的完整生命周期

Binder IPC 的核心是 Client-Server 通信模型，所有跨进程数据交换均封装为 Binder 事务（Transaction）。理解事务的完整生命周期——从发起、内核路由、数据拷贝到唤醒返回——是分析通信延迟与内核调度关联的基础。

3.1 Client-Server 通信模型

Binder 采用 C/S 架构，但与传统 Socket 不同，Binder 通过 Binder 驱动 在内核态完成数据路由与线程管理，无需用户态守护进程。模型中包含三个核心角色：

3.2 Binder 事务（Transaction）的完整生命周期

一次 Binder IPC 调用从 Client 发起请求到 Server 返回结果，经历 6 个关键阶段。每个阶段都可能成为延迟瓶颈，且与内核调度参数紧密相关。

3.2.1 事务生命周期阶段总览

3.3 事务数据结构与内核对象

Binder 驱动内部使用 binder_transaction 结构体表示一次事务，关键字段如下：

// kernel/drivers/android/binder.c (简化结构)
struct binder_transaction {
    struct binder_work        work;           // 工作队列节点
    struct binder_thread      *from;          // 发起线程
    struct binder_proc        *to_proc;       // 目标进程
    struct binder_thread      *to_thread;     // 目标线程（可能为 NULL）
    struct binder_transaction *from_parent;   // 嵌套事务父指针
    struct binder_buffer      *buffer;        // 数据缓冲区
    unsigned int              code;           // 事务码（如 TRANSACTION/REPLY）
    unsigned int              flags;          // 标志位（如 TF_ONE_WAY）
    struct binder_priority    priority;       // 事务优先级（继承自 Client）
    struct list_head          node;           // 链表节点
};

3.4 同步事务 vs 异步事务

Binder 事务分为 同步（TF_ONE_WAY = 0） 和 异步（TF_ONE_WAY = 1） 两种模式，其生命周期差异显著：

3.5 Binder 线程池与事务分发

每个 Server 进程在初始化时会创建 Binder 线程池，默认最大线程数为 16（由 /proc/sys/vm/binder_max_threads 控制）。驱动在分发事务时遵循以下规则：

1. 优先选择空闲线程： 如果 Server 进程有处于空闲状态的 Binder 线程，驱动直接将事务分配给该线程。
2. 创建新线程： 如果没有空闲线程且线程数未达上限，驱动通过 wake_up_process() 唤醒一个正在等待的线程，或触发内核创建新线程。
3. 排队等待： 如果所有线程都在忙，事务进入进程级 todo 队列，等待某个线程完成当前任务后取出处理。

3.6 事务延迟的关键测量点

在实际性能分析中，我们通常关注以下 4 个时间戳 来定位延迟瓶颈：

• T1：Client 调用 ioctl() 前 —— 记录用户态发起时间
• T2：驱动完成数据拷贝后 —— 记录内核态处理完成时间
• T3：Server 线程开始执行 onTransact() —— 记录业务处理开始时间
• T4：Client 收到回复后 —— 记录用户态返回时间

通过 T2 - T1 可评估驱动处理延迟（路由 + 拷贝），T3 - T2 可评估 调度唤醒延迟（本课程核心），T4 - T3 可评估业务处理时间。