Binder机制与实现原理解析

你过来啊你
0 阅读9分钟

Android 中的 Binder 机制是其核心的进程间通信 (IPC) 框架，它是整个系统运行的基础，几乎所有系统服务（如 ActivityManagerService, WindowManagerService, PackageManagerService）以及应用与系统、应用与应用之间的交互都依赖 Binder。理解 Binder 对于深入掌握 Android 系统至关重要。

Binder 机制的核心目标与解决的问题

  1. 高性能： 传统的 Linux IPC（如管道、消息队列、共享内存、Socket）在进程间传递大数据时，往往需要多次数据拷贝（尤其是涉及内核空间和用户空间切换时），效率低下。Binder 设计目标是最小化数据拷贝次数，通常只需要一次拷贝。
  2. 安全性： 传统的 IPC 缺乏完善的进程身份鉴别机制。Binder 基于 OpenBinder 的设计，内置了调用方 UID/PID 的传递和校验能力，为系统提供了可靠的进程身份认证基础，是实现 Android 权限模型的关键。
  3. 易用性： 提供类似本地方法调用的编程模型（基于代理模式），开发者使用 AIDL 等工具可以相对方便地定义跨进程接口，隐藏了底层 IPC 的复杂性。
  4. 引用管理： 提供跨进程对象的引用计数和死亡通知机制，使得进程可以管理对远程对象的引用，并在对象所在进程终止时得到通知。

Binder 机制的核心组件

  1. Binder 驱动 (binder.c)：

    • 位于 Linux 内核层，是整个机制的核心引擎。
    • 作为一个字符设备驱动 (/dev/binder)，为上层提供 open(), mmap(), ioctl(), poll(), close() 等操作接口。
    • 负责：
      • 创建和管理 Binder 实体对象 (binder_node)：代表服务提供者（Server）。
      • 创建和管理 Binder 引用对象 (binder_ref)：代表客户端对远程服务的引用。
      • 管理 Binder 线程池 (binder_thread)：处理跨进程调用请求。
      • 实现进程间数据传递：核心是 mmap() 和 copy_from_user()/copy_to_user() 的巧妙结合。
      • 维护线程等待队列：处理同步调用阻塞。
      • 管理引用计数和死亡通知。
      • 处理传输协议：解析和处理 BINDER_WRITE_READ 等 ioctl 命令携带的数据包。

  2. ServiceManager：

    • 一个特殊的守护进程（servicemanager），它是 Binder 机制的核心系统服务。
    • 充当实名 Binder 服务的注册表或服务目录。
    • 它本身也是一个 Binder 服务（具有固定的句柄 0）。
    • 服务提供者 (Server) 向 ServiceManager 注册其 Binder 实体（服务）和一个字符串名称（如 "activity"）。
    • 客户端 (Client) 通过向 ServiceManager 查询服务名称来获取该服务的 Binder 引用（代理对象句柄）。
    • 提供 addService(), getService(), checkService(), listServices() 等接口。

  3. Binder 库 (libbinder / libbinder_ndk)：

    • 位于 Native 层 (C++)，提供供 C++ 使用的 Binder API。
    • 定义了核心类：
      • IBinder：所有 Binder 对象的基类接口。
      • BBinder：Binder 实体对象的基类。服务提供者需要继承 BBinder 并实现 onTransact() 方法来处理收到的调用请求。
      • BpBinder：Binder 代理对象的基类。它持有指向远程服务的句柄 (handle)。客户端通过它发起跨进程调用。
      • BpInterface：模板类，用于方便地生成代理对象，继承自 BpBinder 并实现特定的服务接口（由 AIDL 生成）。
      • ProcessState：管理进程的 Binder 资源（如打开驱动、映射内存、线程池）。
      • IPCThreadState：管理当前线程的 Binder 状态（执行 transact() 调用、读取/写入事务数据、处理传入请求）。

  4. Java Binder Framework (android.os)：

    • 位于 Framework 层 (Java)，提供供 Java 使用的 Binder API。底层通过 JNI 调用 libbinder。
    • 核心类：
      • IBinder：Java 层的 Binder 对象接口，对应 Native IBinder。
      • Binder：Java 层的 Binder 实体对象基类，对应 Native BBinder。服务端继承此类实现 onTransact()。
      • Stub (AIDL 生成)：通常继承自 Binder 并实现服务接口，是服务端的骨架 (Skeleton)。
      • Proxy (AIDL 生成)：实现服务接口，内部持有 IBinder 引用（通常是 BpBinder 的 Java 封装），是客户端的代理。
      • Parcel：用于打包和解包跨进程传输的数据（基本类型、对象、Binder 引用、文件描述符等）。
      • ServiceManager (Java)：提供访问 Native ServiceManager 服务的接口 (getService, addService 等)。

  5. AIDL (Android Interface Definition Language)：

    • 一种 IDL 语言，用于定义跨进程通信的接口。
    • 开发者编写 .aidl 文件，描述服务提供的方法签名。
    • aidl 工具会自动生成对应的 Java 代码：
      • 接口 (IInterface): 定义了服务契约。
      • Stub 类 (extends Binder implements IInterface)：服务端需要继承此类并实现抽象方法。它处理 onTransact() 并将调用分发给具体的服务实现。
      • Proxy 类 (implements IInterface)：客户端使用此类。它的方法实现将参数打包成 Parcel，通过持有的 IBinder 引用 (mRemote) 调用 transact() 方法发起 IPC，并解包返回值。

Binder IPC 的核心实现原理（一次拷贝）

这是 Binder 性能优越的关键所在，主要依赖于内核驱动层的 mmap() 和精心设计的数据结构：

  1. 内存映射 (mmap)：

    • 当服务端进程启动并准备提供 Binder 服务时，它的 ProcessState 会打开 /dev/binder 设备并调用 mmap()。
    • mmap(size) 请求在内核的 Binder 驱动中分配一块大小为 size (通常为 1M) 的内核虚拟内存区域。
    • 驱动会同时在服务端进程的用户空间创建一块大小相同的映射区域。这样，内核的这块内存区域与服务端进程的用户空间内存区域就映射到了同一块物理内存页。
    • 客户端进程在通过 Binder 与这个服务端通信时，它的 ProcessState 也会打开 /dev/binder 并执行 mmap()。虽然每个进程映射的用户空间地址不同，但驱动会确保所有进程（包括内核）映射的这块 Binder 内存都指向相同的物理内存页。这块物理内存由驱动管理。

  2. 数据传输过程：

    • 发送方 (Client)：
      1. 客户端调用代理对象 (Proxy/BpBinder) 的方法。
      2. 代理对象将方法参数序列化（打包）到一个 Parcel 对象中。
      3. 代理对象调用 IBinder.transact(code, data, reply, flags)。data 就是打包好的 Parcel。
      4. 底层 (IPCThreadState) 准备一个 binder_transaction_data 结构体 (tr)。
        • tr.target.handle：目标服务的句柄。
        • tr.code：要调用的方法码。
        • tr.data_size / tr.data.ptr.buffer：指向 Parcel 中数据缓冲区的指针和大小。
        • tr.offsets_size / tr.data.ptr.offsets：指向 Parcel 中 Binder 对象偏移量数组的指针和大小（用于传递 IBinder 引用或文件描述符）。
      5. 通过 ioctl(BINDER_WRITE_READ, &bwr) 命令将 tr 结构体（包含指向用户空间 Parcel 缓冲区的指针）发送给 Binder 驱动。
    • Binder 驱动：
      1. 接收 ioctl 请求，解析 bwr 和其中的 tr。
      2. 根据 tr.target.handle 找到对应的目标服务端进程和线程。
      3. 关键的一次拷贝：
        • 驱动需要将 tr 结构体和 tr.data.ptr.buffer 指向的用户空间数据（即 Parcel 中的参数数据）传递给服务端。
        • 驱动不是直接将数据拷贝到服务端的用户空间，而是： a. 在步骤1中 mmap 建立的、所有进程共享的内核 Binder 内存区域里分配一块空间 (target_buffer)。 b. 使用 copy_from_user() 将发送方用户空间 (Parcel 缓冲区) 的数据拷贝到这块共享的内核内存 target_buffer 中。这是唯一一次完整的数据拷贝。 c. 更新 tr 结构体中的 data.ptr.buffer 指针，使其指向目标服务端进程映射的用户空间地址所对应的、内核共享内存 target_buffer 的位置。（因为共享内存在内核和所有进程用户空间的映射关系驱动都清楚，所以它能计算出这个指针在目标进程用户空间的等效地址）。
      4. 将更新后的 tr 结构体放入目标服务端线程的待处理事务队列。
      5. 唤醒可能正在等待的服务端线程。
    • 接收方 (Server)：
      1. 服务端线程（通常由线程池中的 IPCThreadState 管理）在 talkWithDriver() 或阻塞在 ioctl(BINDER_WRITE_READ) 上等待请求。
      2. 被驱动唤醒后，从 ioctl 返回的 bwr 中读取到驱动放入的 tr 结构体。
      3. tr.data.ptr.buffer 指针现在指向的是该服务端进程用户空间映射的、对应内核共享内存 target_buffer 的地址。这意味着服务端进程可以直接通过这个用户空间指针访问到驱动刚刚拷贝进来的参数数据，不需要再次拷贝。
      4. 服务端 BBinder 对象的 onTransact(code, data, reply) 方法被调用。这里的 data (Parcel) 就是直接基于指向共享内存的指针构造的，可以高效地反序列化数据。
      5. 服务端执行实际的方法逻辑。
      6. 如果需要返回结果，将结果写入 reply (Parcel)。reply 的数据会通过类似的机制（可能涉及一次拷贝回内核共享内存，再由驱动传递给客户端）返回给客户端。

核心优势总结（一次拷贝）

  • 发送方将数据从自己的用户空间拷贝到内核管理的共享内存（一次拷贝）。
  • 接收方通过 mmap 建立的映射，直接访问这块内核共享内存（零拷贝）。
  • 避免了传统 IPC（如 Socket）中常见的两次拷贝（发送方用户空间 -> 内核缓冲区 -> 接收方用户空间）。

其他重要机制

  1. 引用计数与死亡通知：

    • 当客户端持有一个远程服务的代理对象 (BpBinder) 时，驱动会维护一个对该服务实体 (BBinder) 的强引用计数。
    • 当所有客户端都释放引用（代理对象被回收）时，驱动会通知服务端实体，服务端实体可以执行清理工作。
    • 客户端可以通过 linkToDeath() 注册一个死亡通知 Recipient。当服务端进程意外终止时，驱动会通知所有持有该服务引用的客户端，触发 binderDied() 回调，客户端可以处理连接断开。

  2. 线程池管理：

    • 服务端进程通过 ProcessState 启动一个 Binder 线程池（默认最大 15 个线程）。
    • 驱动负责将客户端请求分发给服务端线程池中的空闲线程。
    • 线程池机制避免了为每个请求创建新线程的开销，提高了并发处理能力。

总结

Binder 机制是 Android 系统的 IPC 基石，它通过在内核驱动层设计共享内存映射 (mmap) 和精心的事务传递协议，实现了高性能（一次拷贝）、高安全性（内置身份认证） 和易用性（类似本地调用的代理模式） 的进程间通信。ServiceManager 作为服务的注册中心，AIDL 简化了接口定义，libbinder 和 Java Framework 提供了丰富的 API。理解 Binder 驱动、mmap、binder_transaction_data、BBinder/BpBinder 以及一次拷贝原理是掌握 Android 系统底层运行机制的关键。

avatar
文章
阅读
粉丝