📚 课程目录第2章 Binder通信模型

2. Binder通信模型：Client-Server模型、ServiceManager注册与获取、Binder节点与引用

Binder IPC 的核心通信模型基于经典的 Client-Server 架构，并引入一个特殊的系统服务——ServiceManager，作为所有服务的“电话簿”。理解这三者之间的关系以及内核中的节点与引用机制，是掌握 Binder 故障排查的基础。

2.1 Client-Server 通信模型

在 Binder 模型中，服务端（Server）提供服务，客户端（Client）使用服务。两者运行在不同的进程空间，通过 Binder 驱动进行透明的跨进程调用。

Server：创建一个 Binder 实体（节点），注册到 ServiceManager，等待 Client 请求。
Client：通过 ServiceManager 获取 Server 的代理（引用），发起远程调用。
Binder Driver：内核模块，负责跨进程数据拷贝、线程管理、节点与引用维护。

    关键点：Client 和 Server 不直接通信，所有数据都经过 Binder 驱动。驱动在内核空间完成一次数据拷贝，实现高性能 IPC。

2.2 ServiceManager：服务的注册与获取

ServiceManager 是一个特殊的 Binder 服务，其句柄（Handle）固定为 0。所有服务在启动时都需要向 ServiceManager 注册，客户端则通过它查询服务。

2.2.1 服务注册流程

Server 创建 Binder 实体：调用 Binder::onCreate() 或 IServiceManager::addService()。
Server 向 ServiceManager 发送注册请求：携带服务名称和 Binder 引用。
ServiceManager 记录服务：将服务名称与 Binder 引用存入内部列表。
ServiceManager 返回成功：Server 注册完成。

2.2.2 服务获取流程

Client 调用 getService()：传入服务名称。
Client 向 ServiceManager 发送查询请求：句柄为 0。
ServiceManager 查找服务：根据名称在列表中查找。
ServiceManager 返回 Binder 引用：Client 获得代理对象，即可发起调用。

故障排查提示：如果 Client 获取服务失败，首先检查 ServiceManager 是否存活（ps -A | grep servicemanager），然后确认服务是否已成功注册（lsservice 命令）。

2.3 Binder 节点与引用

Binder 驱动在内核中维护两个核心数据结构：Binder 节点（Node）和Binder 引用（Ref）。它们是理解 Binder 生命周期和故障的关键。

概念	内核数据结构	说明	生命周期
Binder 节点 (Node)	`struct binder_node`	代表一个 Binder 服务实体，由 Server 进程创建。每个 Server 只有一个节点。	Server 进程退出或显式销毁时释放。
Binder 引用 (Ref)	`struct binder_ref`	代表 Client 对某个 Binder 节点的引用。每个 Client 可以持有多个引用。	Client 进程退出或显式释放时减少引用计数。
句柄 (Handle)	`uint32_t`	Client 侧用来标识 Binder 引用的整数 ID。句柄 0 固定指向 ServiceManager。	与 Binder 引用绑定，引用释放后句柄失效。

常见故障：如果 Server 进程异常退出，但 Client 仍持有该 Server 的 Binder 引用，此时 Client 发起调用会收到 DEAD_BINDER 异常。内核会通过 binder_node 的死亡通知机制通知所有持有引用的 Client。

2.4 关键数据结构对比

以下表格对比了用户空间与内核空间的关键数据结构，帮助理解 Binder 通信的底层实现。

层次	数据结构	作用	对应内核对象
用户空间 (Client)	`BpBinder`	代理对象，封装了句柄操作	`binder_ref`
用户空间 (Server)	`BBinder`	实体对象，处理远程请求	`binder_node`
内核空间	`binder_proc`	每个进程对应一个，管理该进程的节点和引用	进程上下文
内核空间	`binder_transaction`	事务结构，记录一次 IPC 调用的完整信息	临时对象

    故障排查要点：
    如果 binder_node 引用计数不为 0 但 Server 已退出，说明存在悬空引用，需要检查 Client 的死亡通知处理。
如果 binder_ref 数量异常增长，可能存在句柄泄漏，需要检查 Client 是否及时释放 Binder 引用。
通过 /sys/kernel/debug/binder/proc 可以查看每个进程的节点和引用信息。