3. Binder驱动核心机制

Binder驱动是Android系统中进程间通信（IPC）的基石。本章深入剖析Binder驱动的三大核心机制：线程模型、通信流程与内存管理。理解这些机制是进行多平台移植适配的关键前提。

3.1 Binder线程模型与binder_thread

Binder驱动采用线程池模型来处理并发请求。每个参与Binder通信的进程，在用户空间维护一个线程池，而内核空间则通过 binder_thread 结构体来管理每个通信线程的状态。

3.1.1 binder_thread 核心数据结构

binder_thread 是驱动为每个调用 BINDER_IOCTL 的线程分配的内核对象，它记录了线程的等待队列、事务栈、状态标志等关键信息。

3.1.2 线程状态机与工作模式

Binder线程在 looper 字段中维护状态，驱动根据状态决定如何分发事务。主要状态包括：

• BINDER_LOOPER_STATE_REGISTERED：线程已注册到Binder线程池。
• BINDER_LOOPER_STATE_ENTERED：线程已进入Binder循环（调用 ioctl()）。
• BINDER_LOOPER_STATE_WAITING：线程正在等待新事务。
• BINDER_LOOPER_STATE_POLL：线程使用 epoll 机制等待。

3.1.3 Binder线程模型工作流程

下图展示了Binder线程模型的核心交互流程：

3.2 Binder进程间通信流程

Binder通信的核心协议由 BC_TRANSACTION（客户端发送）和 BR_TRANSACTION（驱动转发）这一对命令构成。理解这一来一回的完整路径，是掌握Binder通信的关键。

3.2.1 通信协议命令对

3.2.2 一次完整通信的六步流程

1. 客户端发送请求： 客户端线程填充 binder_transaction_data 结构体，通过 ioctl(fd, BINDER_WRITE_READ, ...) 下发 BC_TRANSACTION 命令。
2. 驱动查找目标： 驱动根据目标Handle在全局 binder_proc 红黑树中查找目标进程/线程。
3. 驱动分配事务： 驱动分配 binder_transaction 结构体，将数据从客户端用户空间拷贝到内核缓冲区。
4. 驱动唤醒目标： 驱动将 BR_TRANSACTION 命令放入目标线程的 todo 队列，并唤醒目标线程。
5. 服务端处理： 服务端线程从 ioctl() 返回，读取 BR_TRANSACTION，处理业务逻辑。
6. 回复与完成： 服务端发送 BC_REPLY，驱动将结果通过 BR_REPLY 返回给客户端。

3.2.3 通信流程SVG示意图

3.3 Binder内存管理机制 (binder_alloc)

Binder驱动通过 binder_alloc 结构体管理每个进程的Binder内存缓冲区。其核心设计是内存映射（mmap） + 内核缓冲区池，实现了高效的一次性数据拷贝。

3.3.1 binder_alloc 核心结构

struct binder_alloc {
    struct binder_proc *proc;       // 所属进程
    struct mutex mutex;             // 保护分配操作的互斥锁
    struct rb_root free_buffers;    // 空闲缓冲区红黑树
    struct rb_root allocated_buffers; // 已分配缓冲区红黑树
    size_t free_async_space;        // 剩余异步事务空间
    struct list_head buffers;       // 所有缓冲区链表
    unsigned long buffer_size;      // 映射的总大小
    void __iomem *buffer;           // 内核虚拟地址
    struct mm_struct *vma_vm_mm;    // 用户空间mm_struct
    unsigned long vma_start;        // 用户空间映射起始地址
    size_t vma_size;                // 用户空间映射大小
};

3.3.2 内存分配与释放策略

Binder内存管理采用最佳适应（Best-fit）算法，通过红黑树快速查找最合适的空闲块。

3.3.3 内存映射与数据拷贝流程

3.3.4 移植适配中的内存管理注意事项

3.3.5 缓冲区分配策略对比