3. 通信模型
3.1 系统边界与分层结构
Binder 的通信模型在 用户空间 与 内核空间 之间划出了清晰的系统边界。所有业务进程（Client / Server）运行在用户空间，而跨进程的数据路由、权限校验全部由内核空间的 Binder 驱动 完成。从逻辑分层看，整个模型可分为四层：
- 应用层 — Client 进程与 Server 进程，负责业务逻辑的发起与实现。
- 服务代理层 — Proxy（代理）与 Stub（桩），负责接口语义的转换、参数序列化与反序列化。
- 传输层 — Binder 驱动，承担数据拷贝、线程等待唤醒、权限校验等核心机制。
- 命名层 — ServiceManager，维护服务名称到 Binder 引用的映射，提供注册与发现能力。
这四层共同构成了 Binder 的 定位—连接—传输—调用 完整链路，任何跨进程调用都必须依次穿透这些边界。
3.2 组件职责
六个核心组件在通信模型中承担高度内聚的职责，下表从 所在空间、核心职责 和 关键约束 三个维度进行对比。
| 组件 | 所在空间 | 核心职责 | 关键约束 |
|---|---|---|---|
| Client 进程 | 用户空间 | 发起服务调用，持有 Proxy 引用 | 无需知晓 Server 物理地址 |
| Proxy 代理 | 用户空间 | 将接口调用转为 Binder 事务（参数封装） | 必须与 Stub 接口保持严格对称 |
| Binder 驱动 | 内核空间 | 数据路由、权限校验、线程迁移 | 全局唯一传输通道，单点瓶颈 |
| Stub 桩 | 用户空间 | 反序列化请求，调用 Server 实际方法 | 线程安全，需处理并发调用 |
| Server 进程 | 用户空间 | 实现服务接口的业务逻辑 | 推荐无状态设计，便于扩展 |
| ServiceManager | 用户空间 | 维护服务注册表，提供名称解析 | 全局唯一引用，启动顺序要求 |
边界职责分离原则： Proxy 只做接口转换，不包含业务逻辑；Stub 只做请求分发，不实现服务；Server 只关注业务，不感知 IPC 细节。这一原则保证了各组件可独立演化与测试。
3.3 数据流 / 控制流 / 信任链路
数据流
数据在通信模型中沿 Client → Proxy → Binder 驱动 → Stub → Server 方向流动，服务器响应沿相同路径返回。关键特征：
- 零拷贝路径 — Binder 驱动通过内存映射（mmap）在进程间共享数据，避免两次用户态/内核态拷贝。
- 序列化契约 — Proxy 与 Stub 使用预定义的 事务码（transaction code） 和 数据布局，保证两端解码一致。
控制流
控制流遵循 同步请求‑响应 模式（默认），也可通过 oneway 标记切换为异步。控制流的关键节点：
- 等待队列 — Client 线程在 Binder 驱动中挂起，直到 Server 回应。
- 唤醒链 — Binder 驱动收到 Stub 的回复后，根据事务 ID 唤醒对应的 Client 线程。
- 超时与重试 — 驱动层默认无重试，超时由上层 Proxy 或应用层处理。
信任链路
信任链路建立在 内核级身份校验 和 ServiceManager 准入控制 之上：
- UID / PID 校验 — Binder 驱动自动提取调用方的 UID 和 PID，注入到事务头中，Server 端 Stub 可据此做鉴权。
- ServiceManager 查询限制 — 只有已注册的 Server 才能对外提供服务，Client 只能通过名称查询获取引用。
- 不可伪造路径 — 所有跨进程数据必须经过 Binder 驱动，用户空间无法直接篡改内核维护的 UID / PID。
信任风险： 如果 Binder 驱动被恶意模块劫持，整个信任链将失效。因此内核空间的驱动完整性是安全基座，必须通过内核签名机制保护。
3.4 选型权衡
Client‑Server 模型 + 代理/桩模式并非唯一 IPC 方案，下表从六个维度与广播模型、共享内存模型对比：
| 维度 | Client‑Server + 代理/桩 | 广播模型 | 共享内存模型 |
|---|---|---|---|
| 耦合度 | 低 — 接口契约驱动 | 低 — 事件驱动 | 高 — 需同步数据布局 |
| 可扩展性 | 高 — 新增服务只需注册 | 中 — 广播风暴风险 | 低 — 内存竞争随进程数增长 |
| 安全性 | 高 — 内核强制校验 | 低 — 任何进程可订阅 | 中 — 依赖信号量等辅助机制 |
| 实时性 | 中 — 有序列化/反序列化开销 | 高 — 无等待广播 | 高 — 直接内存访问 |
| 资源消耗 | 低 — 按需创建线程 | 高 — 广播时唤醒大量进程 | 中 — 需维护共享内存区 |
| 使用复杂度 | 中 — 需定义接口并生成桩 | 低 — 订阅/发布简单 | 高 — 需处理竞态条件 |
选型建议： 对于 Android 系统内的跨进程服务调用（如 ActivityManager、WindowManager），Binder 的 C/S + 代理/桩模式是唯一官方方案。但在进程间批量数据共享场景（如音视频帧传递），共享内存或管道模式可能更优。
3.5 风险点
通信模型的架构设计并非无懈可击，以下风险点需要在落地时重点关注：
- ServiceManager 单点故障 — 若 ServiceManager 崩溃，所有服务注册与发现将中断。通过 启动优先级保证 和 看门狗监控 缓解。
- 代理/桩接口漂移 — 如果 Client 和 Server 的接口定义版本不一致，运行时将出现事务码不匹配。必须通过 接口版本号校验 和 AIDL 向后兼容 规则控制。
- Binder 驱动瓶颈 — 所有跨进程通信都经过同一驱动节点，高并发时可能成为性能瓶颈。可通过 Binder 线程池扩容 和 事务优先级 缓解。
- 死锁与递归调用 — Server 在处理请求时反向调用 Client 或另一个 Server，容易引发线程死锁。设计时应 禁止在 Binder 回调中同步调用阻塞服务。
- 权限泄露 — 若 Server 未校验 UID，可能导致未授权 Client 访问敏感服务。必须在 Stub 入口统一添加 权限检查守卫。
3.6 落地步骤
在 Android 系统或类 Android 平台上实施该通信模型，建议按以下 6 个步骤推进：
- 定义服务接口 — 使用 AIDL 或手动定义接口方法、参数类型和事务码，保证 Proxy/Stub 双方契约一致。
- 生成代理与桩代码 — 通过工具自动生成 Proxy 和 Stub 实现，或手动编写满足接口规范的封装类。
- 实现 Server 服务 — 编写继承 Stub 的服务类，实现接口中的业务方法；配置 Binder 线程池大小（默认 16）。
- 注册服务到 ServiceManager — Server 进程启动后调用
ServiceManager.addService()将名称与 Binder 引用绑定。 - Client 获取服务引用 — Client 调用
ServiceManager.getService()根据名称获取 Binder 引用，并转换为 Proxy 对象。 - 集成测试与权限绑定 — 编写跨进程调用测试用例，验证数据正确性；在 Stub 中添加 UID/PID 校验，确保信任链路闭合。
落地检查点： 每完成一步，需要验证接口兼容性（第1步）、线程安全性（第2&3步）、注册成功率（第4步）、引用有效性（第5步）和权限拦截的正确性（第6步）。
3.7 验收标准
通信模型是否成功落地，以下 5 条验收标准必须全部满足：
| 验收项 | 合格指标 | 验证方式 |
|---|---|---|
| 跨进程调用正确性 | 连续 10,000 次调用无数据错乱 | 自动化测试 + 数据比对 |
| 服务发现成功率 | Client 在 Server 注册后 1s 内获取引用 | 时间戳采样 |
| 权限拦截有效性 | 未授权调用 100% 被拒绝 | 注入非法 UID 测试 |
| 并发处理稳定性 | 10 个 Client 同时调用，无崩溃或死锁 | 压力测试 + 堆栈分析 |
| 接口兼容性 | Proxy/Stub 版本号匹配，异常版本可感知 | 版本号检查 + 降级测试 |
验收优先级： 第一优先级为保证 跨进程调用正确性 和 权限拦截有效性，这是通信模型的信任基石；性能优化可在后续迭代中持续进行。