3. 系统服务管理层：ServiceManager 职责、服务注册与发现、Binder 通信模型
3.1 模块边界与分层结构
系统服务管理层是 Android Framework 的中枢神经系统，ServiceManager（简称 SM）作为全局服务注册表运行在独立的 servicemanager 进程中。它的边界清晰：用户空间包含客户端（App/SystemServer）与服务端（各类系统服务），内核空间提供 Binder 驱动作为消息传递底层。SM 本身不提供具体业务功能，只负责服务名到 Binder 引用的映射。
| 层次 | 组件 | 职责 | 通信方式 |
|---|---|---|---|
| 应用框架层 | Client（App/SystemServer） | 调用服务接口 | Binder IPC |
| 服务管理层 | ServiceManager | 注册、查询、管理 Binder 引用 | Binder（特殊句柄 0） |
| 系统服务层 | Server（AMS/WMS/etc.） | 提供具体功能 | Binder IPC |
| 内核层 | Binder Driver | 线程管理、内存映射、事务转发 | 内核 ioctl |
3.2 组件职责与数据流
ServiceManager 核心职责有三：
- 服务注册：Server 进程通过 Binder 驱动向 SM 发送
ADD_SERVICE_TRANSACTION，SM 维护名字 → Binder 引用（flat_binder_object）的哈希表。 - 服务发现：Client 发送
CHECK_SERVICE_TRANSACTION或GET_SERVICE_TRANSACTION，SM 返回对应的 Binder 引用或空。 - 引用管理：当 Server 死亡时，Binder 驱动发送
BR_DEAD_BINDER，SM 清除对应记录。
控制流遵循严格顺序：Server 先注册 → SM 确认 → Client 查询 → 拿到引用后建立直接 Binder 连接，后续通信不再经过 SM。
信任链路关键点： SM 只接收来自
SYSTEM 或特权 UID 的注册请求；普通 App 只能查询。这一控制是在 Binder 驱动层通过 security_ops 执行的，与 SM 自身权限检查构成双重信任。
3.3 Binder 通信模型核心
Binder 采用 C/S 架构，但特殊性在于：
- 使用 BC(内核空间) 和 BR(用户空间) 协议指令对。
- 数据传输通过 mmap 共享内存 实现零拷贝（一次拷贝），内核态只做指针传递。
- 每个 Binder 线程在调用
IPCThreadState::joinThreadPool()后进入 loop，等待驱动发回 BR_TRANSACTION。
一次典型 IPC 调用（Client → Server）的数据流：
- Client 调用
transact()→ 写入parcel→ 调用ioctl(fd, BINDER_WRITE_READ, &bwr)。 - Binder 驱动根据目标句柄找到 Server 的
binder_node，将事务插入目标进程的 todo 队列。 - Server 的
IPCThreadState从驱动读取BR_TRANSACTION→ 解包 Parcel → 调用目标函数 → 返回BR_REPLY。 - Client 收到
BR_REPLY后取出返回数据。
风险点： ServiceManager 是单点，若被 kill 或 OOM，所有新服务注册失败，但已建立连接的 IPC 不影响（因为引用在 Client/Server 本地缓存）。另一个风险是恶意服务伪装：需配合 seccomp 和 SELinux 确保只有授权进程能注册系统服务。
3.4 选型权衡与落地步骤
| 方案 | 优势 | 劣势 | Binder 方案对比 |
|---|---|---|---|
| Socket + 自定义协议 | 跨平台、容易调试 | 无零拷贝、需自行处理字节序 | Binder 性能更好，但绑定 Linux |
| 共享内存 + 信号量 | 极低延迟 | 代码复杂、难以动态发现服务 | Binder 兼顾易用性与性能 |
| Binder | 内置引用计数、死亡通知、权限控制 | 不可跨设备、学习曲线陡峭 | Android 默认首选 |
落地步骤（以新增系统服务为例）：
- 定义 AIDL 接口 → 编译生成 Binder 桩。
- Server 端实现 Stub，在
system_init()或SystemServer.startOtherServices()中调用ServiceManager.addService("myservice", newImpl)。 - Client 端：
ServiceManager.getService("myservice")→ 强转 Stub.asInterface。 - 配置 SELinux 策略：允许目标进程的 domain 对 servicemanager 进行 service_manager:add。
- 测试验收：通过
dumpsys查看服务列表，模拟 Server 死亡验证自动注销。
3.5 验收标准
- 服务注册后 1s 内可被查询到。
- 并发查询 1000 次不丢引用。
- Server 异常退出后，Client 能收到死亡回调（
linkToDeath）。 - 未授权进程注册系统服务返回
PERMISSION_DENIED。 - Binder 事务大小超过 1MB 时触发
FAILED_TRANSACTION，需保证系统服务事务不超过 800KB。