Native 层 Binder 框架：C++ 层的 BpBinder、BBinder、IPCThreadState 核心类

好，咱们今天来啃一块硬骨头——Native 层的 Binder 框架。说实话，很多做 Android 应用开发的朋友，可能一辈子都用不到这层。但如果你要做系统开发、做 Framework 定制，或者想真正理解 Binder 的底层原理，那这层是绕不过去的。

我个人习惯把 Binder 的 Native 层比作一个「翻译官」。Java 层的 Binder 调用，最终都要通过 JNI 走到这层，由它来跟内核的 Binder 驱动打交道。今天咱们就重点聊聊三个核心类：BpBinder、BBinder 和 IPCThreadState。

1. 先理清角色：BpBinder 和 BBinder 是什么？

说白了，BpBinder 是客户端代理，BBinder 是服务端实体。你想想看，客户端和服务端不在同一个进程里，怎么通信？客户端手里拿着的其实是一个「假」的对象——BpBinder，它负责把调用请求打包，通过 Binder 驱动发给真正的服务端。服务端那边，BBinder 负责接收请求，解包，然后调用真正的业务逻辑。

嗯，这里要注意：BpBinder 和 BBinder 都继承自 IBinder 接口。IBinder 定义了 transact() 这个核心方法，两边各自实现。

2. BpBinder：客户端的「传话筒」

BpBinder 的全称是 "Binder Proxy Binder"，名字有点绕，但功能很直接。它内部维护了一个 handle 值，这个 handle 是 Binder 驱动分配给客户端的整型标识，用来定位目标服务。

我在项目中遇到过一个问题：某个系统服务在客户端调用时偶尔会卡死，查了半天发现是 BpBinder 的 handle 被意外释放了，导致后续的 transact() 调用一直阻塞。嗯，从那以后我特别留意 handle 的生命周期管理。

来看看 BpBinder 的核心方法——transact()：

// frameworks/native/libs/binder/BpBinder.cpp
status_t BpBinder::transact(
    uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
    // 把调用交给 IPCThreadState 处理
    status_t status = IPCThreadState::self()->transact(
        mHandle, code, data, reply, flags);
    return status;
}

看到了吗？BpBinder 自己其实不干活，它就是个传话筒。真正的通信工作，它委托给了 IPCThreadState。这个设计很有意思——把通信逻辑集中到一个地方，方便管理。

3. BBinder：服务端的「守门员」

BBinder 这边，它的 transact() 实现就完全不一样了。它收到请求后，会调用 onTransact() 这个虚函数。子类（比如 JavaBBinder）通过重写 onTransact() 来实现具体的业务分发。

// frameworks/native/libs/binder/BBinder.cpp
status_t BBinder::transact(
    uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
    switch (code) {
        case PING_TRANSACTION:
            reply->writeInt32(PING_TRANSACTION);
            return NO_ERROR;
        default:
            return onTransact(code, data, reply, flags);
    }
}

status_t BBinder::onTransact(
    uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
    // 默认实现返回 UNKNOWN_TRANSACTION
    return UNKNOWN_TRANSACTION;
}

这里有个细节：BBinder 的 transact() 会先处理一些系统级的命令（比如 PING_TRANSACTION），其他的才交给 onTransact()。我曾经踩过一个坑——在自定义的 BBinder 子类里重写了 transact() 但忘了调用父类的实现，结果 PING_TRANSACTION 返回了错误，导致服务被误判为死掉。

4. IPCThreadState：真正的「通信兵」

好，前两个类都是「动嘴皮子」的，真正干活的其实是 IPCThreadState。它封装了与 Binder 驱动交互的所有细节——ioctl 调用、数据打包、线程管理等等。

IPCThreadState 使用 TLS（线程局部存储）来管理每个线程的实例。每个线程都有自己的 IPCThreadState，互不干扰。这个设计我特别喜欢——避免了锁竞争，性能好很多。

// frameworks/native/libs/binder/IPCThreadState.cpp
IPCThreadState* IPCThreadState::self()
{
    if (gHaveTLS) {
        // 从 TLS 中获取
        IPCThreadState* st = (IPCThreadState*)pthread_getspecific(gTLS);
        if (st) return st;
    }
    // 创建新实例并存入 TLS
    IPCThreadState* st = new IPCThreadState;
    pthread_setspecific(gTLS, st);
    return st;
}

它的核心方法 talkWithDriver() 负责执行 ioctl 调用：

status_t IPCThreadState::talkWithDriver(bool doReceive)
{
    // 构造 binder_write_read 结构体
    struct binder_write_read bwr;
    // ... 填充数据 ...
    
    // 执行 ioctl 系统调用
    status_t err = ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr);
    
    // ... 处理结果 ...
    return err;
}

你看，最终就是通过 ioctl 把数据传给 Binder 驱动。驱动负责在进程间拷贝数据，唤醒目标线程，等等。

5. 三者的协作流程

咱们用一个实际的例子串起来：假设 App 要调用系统服务（比如 ActivityManagerService）的某个方法。

1. App 端（客户端）：持有 BpBinder 对象，调用 transact()
2. BpBinder：把 handle、code、data 传给 IPCThreadState
3. IPCThreadState：通过 ioctl 发给 Binder 驱动
4. Binder 驱动：找到目标进程，把数据拷贝过去，唤醒服务端线程
5. 服务端 IPCThreadState：从 ioctl 返回，拿到请求数据
6. BBinder：调用 onTransact() 分发请求
7. 具体服务实现：执行真正的业务逻辑

这个流程，说白了就是「客户端代理 → 通信兵 → 驱动 → 通信兵 → 服务端实体」这么一条链。

6. 一张图看懂整体架构

我画了张图，把这三个类的关系和协作流程展示出来：

7. 几个关键设计点

聊完了三个类，我再补充几个设计上的亮点：

• 线程模型：IPCThreadState 是 per-thread 的，每个线程独立处理自己的 Binder 事务。这意味着 Binder 调用不会阻塞其他线程。
• 数据封装：Parcel 类负责序列化/反序列化数据。BpBinder 和 BBinder 都不直接操作原始字节，而是通过 Parcel 来读写。
• 引用计数：BpBinder 内部有强弱引用计数，防止在跨进程调用过程中被意外销毁。我见过因为引用计数管理不当导致的野指针崩溃，排查起来特别痛苦。

8. 总结一下

Native 层的 Binder 框架，核心就是这三个类：

类名	角色	核心职责
BpBinder	客户端代理	持有 handle，委托 IPCThreadState 发送请求
BBinder	服务端实体	接收请求，通过 onTransact() 分发
IPCThreadState	通信兵	执行 ioctl，与 Binder 驱动交互

这三者配合，构成了 Binder 在 Native 层的完整通信骨架。理解了它们，你就掌握了 Binder 框架的半壁江山。剩下的，就是 Java 层如何通过 JNI 调用这层，以及 Binder 驱动内部的数据结构了——那些咱们后面再聊。

---

公众号:蓝海资料掘金营，微信deep3321