2. 整体架构分层
2.1 四层架构全景
Binder 跨进程通信并非 Android 系统中某个孤立的模块，而是一套从应用到内核的完整信任链条。整个架构按访问特权与抽象层级自上而下划分为四层：应用层、Framework 层、Native 层和Kernel 层。每一层只依赖其直接下层，并通过明确定义的接口向上提供服务。
核心原则：层间依赖单向向下，越上层越接近业务语义，越下层越接近硬件与进程管理。Binder 的稳定性和性能依赖这种严格的界限。
2.2 各层职责与边界
| 层级 | 核心职责 | 边界（对外暴露的典型对象/服务） | 依赖的下层 |
|---|---|---|---|
| 应用层 | 业务逻辑编排、UI 交互、跨进程服务调用 | Android 组件（Service、ContentProvider、Binder 服务端/客户端接口） | Framework 层的 ServiceManager、AIDL 生成的桩 |
| Framework 层 | 组件管理、权限仲裁、服务注册/发现、AIDL 桩代码 | android.os.Binder、android.os.IBinder、ServiceManager 代理 | Native 层的 libbinder（IPCThreadState、ProcessState） |
| Native 层 | 协议封装、线程池管理、Binder 事务（BC_/BR_ 命令）的序列化与分发 | libbinder 动态库、BpBinder / BBinder 虚基类 | Kernel 层的 Binder 驱动（设备节点 /dev/binder） |
| Kernel 层 | 进程间内存映射、数据拷贝、线程唤醒、引用计数管理 | /dev/binder 字符设备、binder_ioctl 系统调用 | 内存管理子系统、进程调度子系统 |
2.3 数据流与控制流
一次典型的跨进程调用（例如应用 A 调用应用 B 的远程方法）经过四层数据流动：
- 应用层 → Framework 层：通过 AIDL 接口生成的 Proxy 调用 transact()，将序列化后的 Parcel 数据交给 Framework 的 Binder 代理。
- Framework 层 → Native 层：Framework 的 android::BpBinder 将 Parcel 数据包装为 binder_transaction_data，并通过 IPCThreadState::talkWithDriver() 执行 writeTransaction。
- Native 层 → Kernel 层：通过 ioctl(fd, BINDER_WRITE_READ, &bwr) 将命令与数据传入内核驱动。
- Kernel 层内部处理：binder_ioctl 分配内核缓冲区，将数据从发送进程的用户空间拷贝到内核空间，再映射到接收进程的用户空间，并唤醒接收进程的等待线程。
- 向上回传：接收进程的 Native 层（IPCThreadState）读取回复数据，经过 Framework 层解包，最终交付给应用层的 Service 实现。
关键观察：数据在内核空间只拷贝一次（从发送端用户态 → 内核缓冲 → 接收端用户态），这是 Binder 性能优于传统 Socket 或管道（需多次拷贝）的核心原因。
2.4 信任链路与安全边界
每一层都承担不同的信任验证职责：
- Kernel 层：验证发送方的 PID/UID，确保进程标识真实不可伪造。
- Native 层：检查调用者的身份令牌（context manager 入口），防止未注册的服务被调用。
- Framework 层：基于 Android 权限系统（PermissionChecker）对接口调用做运行时权限校验。
- 应用层：由具体 Service 实现自定义的业务安全规则（如签名验证、用户身份识别）。
风险提示：如果 Kernel 层驱动存在漏洞（如 binder_ioctl 中的越界访问），下层信任根基将被破坏，上层所有安全措施失效。因此 Binder 驱动是 Android 安全加固的核心关注点。
2.5 四层依赖关系与边界图
2.6 选型权衡与设计决策
- 为什么不在 Framework 层直接调用驱动？ 避免 Java 调用直接陷入内核，降低移植性；Native 层提供 C++ 抽象，便于跨平台复用（如：Chrome 的 Mojo 借鉴类似思想）。
- 为什么需要四层而不是三层？ Framework 层与 Native 层分离使得系统服务可以绕过 Java 虚拟机（如 SurfaceFlinger、mediaserver），获得更低的延迟和更高的确定性。
- Kernel 层为何不直接提供 IPC 隧道？ Binder 驱动专门针对 Android 场景（异步、引用计数、匿名共享内存），如果放到用户态驱动，则无法保证进程间安全隔离并需要使用 netlink 等额外机制，复杂度反而增加。
2.7 落地步骤与验收标准
| 阶段 | 具体步骤 | 验收标准 |
|---|---|---|
| 1. 分层确认 | 梳理项目中所有 Binder 相关代码，按四层分类归档。 | 每个跨进程调用能清晰追溯到各层的入口/出口文件。 |
| 2. 边界接口冻结 | 定义每层对外暴露的 C++/Java 接口（如 BP_BINDER 基类、ServiceManager 代理）。 | 接口变更必须经架构评审，并触发自动化集成测试。 |
| 3. 依赖注入验证 | 确保 Native 层不直接引用 Framework 层的 Java 对象，Kernel 层不引用任何用户态符号。 | 编译工具链可检测循环依赖，静态分析通过。 |
| 4. 性能基线测量 | 以各层为基准，记录一次简单 IPC 调用的延迟分布。 | 各层处理耗时占比明确，总延迟不超过 500μs（典型值）。 |
2.8 常见风险与应对
- 层间泄漏：应用层直接调用 Native 层 libbinder 的底层函数（如 talkWithDriver）。
应对：在编译期通过头文件权限控制（仅 Framework/System 进程可引用 libbinder 内部 API）。 - 线程模型混乱：Native 层与 Framework 层各自管理线程池，如果配置不当导致死锁。
应对：规定 Native 层的 Binder 线程池数量与 Framework 层的线程池数量之和不超过设备 CPU 核数的 2 倍。 - 版本兼容性：Kernel 层 Binder 驱动接口（ioctl 命令码、binder_transaction_data 结构）在不同 Android 版本间可能扩展。
应对：Native 层必须使用版本协商机制（如检查驱动返回的 BINDER_FEATURE_ 标志）。
架构实践建议：在项目早期绘制完整的四层依赖关系图（包含每个 .aidl 文件、ServiceManager 注册路径、以及对应的 Native 端 BpBinder 指针），能显著降低后期调试“Binder Transaction Failed”问题的排查成本。