📚 课程目录第4章 ServiceManager概述

4. ServiceManager概述

在Android的Binder进程间通信体系中，ServiceManager是一个极其特殊且关键的角色。它既不是普通的系统服务，也不是简单的工具进程，而是整个Binder名字服务（Name Service）的守护者。如果把Binder驱动比作内核中的“通信总线”，那么ServiceManager就是这条总线上的“电话总机”——所有服务在启动时都要到这里登记自己的名字，所有客户端在使用服务前都要先到这里查询名字对应的Binder句柄。没有ServiceManager，Android的C/S通信架构将无法建立稳定的寻址基础。

一、ServiceManager的核心作用

ServiceManager的本质是一个服务注册与查询中心。它维护一张全局的服务名到Binder引用的映射表，对外提供两个最核心的接口：addService()用于服务注册，getService()用于服务查询。任何系统服务（如ActivityManagerService、PackageManagerService、WindowManagerService）在启动后，都必须通过Binder驱动向ServiceManager注册自己的名字；而客户端进程需要访问某个服务时，则先向ServiceManager查询该名字，拿到Binder代理对象后再发起真正的跨进程调用。

从数据结构角度看，ServiceManager内部维护的是一个svc_list链表，每个节点保存服务名称字符串和对应的Binder实体引用。当客户端查询时，ServiceManager通过Binder驱动将服务端的Binder节点转换为客户端可用的代理句柄，从而完成跨进程引用的传递。

ServiceManager解决的是Binder通信中的“寻址问题”：客户端不知道目标服务在哪个进程、哪个线程，只知道服务名。ServiceManager把“名字”翻译成“Binder句柄”，让跨进程调用成为可能。

二、启动时机：Android系统启动链中的关键一环

ServiceManager的启动时机非常早，它由init进程在解析init.rc时启动，早于Zygote和SystemServer。典型启动顺序如下：

Linux内核启动，加载Binder驱动，创建/dev/binder设备节点。
init进程启动，解析init.rc，执行service servicemanager /system/bin/servicemanager。
ServiceManager进程启动，打开Binder驱动，调用BINDER_SET_CONTEXT_MGR将自己注册为Binder上下文管理者（Context Manager）。
ServiceManager进入binder_loop()，等待其他进程的注册与查询请求。
Zygote启动，SystemServer启动，各系统服务依次向ServiceManager注册。

这里最关键的一步是BINDER_SET_CONTEXT_MGR。Binder驱动内部有一个全局变量binder_context_mgr_node，专门保存ServiceManager的Binder节点。任何进程只要知道“0号句柄”代表ServiceManager，就能与它通信。这个0号句柄是Binder协议中唯一固定的、不需要查询就能使用的特殊句柄。

// ServiceManager启动时的关键调用（简化）
int main() {
    int fd = open("/dev/binder", O_RDWR);
    // 将自己设置为Binder上下文管理者
    ioctl(fd, BINDER_SET_CONTEXT_MGR, 0);
    // 进入循环，处理addService/getService请求
    binder_loop(fd, svcmgr_handler);
    return 0;
}

三、进程角色：既是服务端，也是“服务的服务”

ServiceManager本身也是一个Binder服务端，但它服务的对象不是普通应用，而是其他系统服务。它扮演着双重角色：

作为Binder服务端：它拥有自己的Binder节点，监听来自其他进程的ADD_SERVICE、GET_SERVICE、CHECK_SERVICE等事务请求。
作为名字服务提供者：它不处理业务逻辑，只负责名字与句柄的映射，是“服务的服务”。

从权限角度看，ServiceManager对注册操作有严格限制。普通应用无法随意注册系统级服务名，只有具有相应权限的进程才能调用addService()。这保证了系统服务名的唯一性和安全性。

四、在Binder体系中的核心地位

ServiceManager在Binder体系中的地位可以用“一个中心、两条路径”来概括。一个中心是指它是所有Binder服务的名字中心；两条路径是指服务注册路径和服务查询路径。下图展示了ServiceManager与Binder驱动、服务端、客户端之间的结构关系：

从图中可以清晰看到，ServiceManager位于Binder驱动之上、系统服务与客户端之间。它不直接参与业务数据的传输，只负责“牵线搭桥”。一旦客户端拿到了Binder代理，后续的跨进程调用就由Binder驱动直接完成，ServiceManager不再介入。这种设计既保证了寻址的集中管理，又避免了中心节点成为通信瓶颈。

五、常见误区与复盘要点

误区一：认为ServiceManager是普通系统服务。实际上它比普通系统服务启动更早，且由init直接启动，不依赖SystemServer。它注册的是“上下文管理者”，而不是普通服务名。

误区二：认为所有Binder通信都要经过ServiceManager。只有“第一次按名字查找服务”需要经过ServiceManager。拿到Binder代理后，客户端与服务端直接通过Binder驱动通信，ServiceManager不再参与。

误区三：忽略0号句柄的特殊性。0号句柄是Binder协议中唯一固定的句柄，专门指向ServiceManager。其他服务句柄都是动态分配的，必须通过ServiceManager查询获得。

复盘时可以用一张清单来检查对ServiceManager的理解是否到位：

检查项	关键结论	常见错误
启动者	init进程解析init.rc启动	误认为是Zygote或SystemServer启动
启动时机	早于Zygote和SystemServer	误认为与其他系统服务同时启动
核心接口	addService / getService / checkService	误认为它处理业务逻辑
特殊句柄	0号句柄固定指向ServiceManager	误认为0号句柄是普通服务
通信范围	只参与寻址，不参与后续数据传输	误认为所有Binder调用都经过它
权限控制	注册系统服务需要相应权限	误认为任何进程都能注册任意服务名

六、案例场景：SystemServer注册ActivityManagerService

以SystemServer启动ActivityManagerService为例，可以完整看到ServiceManager的工作过程：

// SystemServer中注册ActivityManagerService（简化）
ActivityManagerService ams = new ActivityManagerService(context);
// 通过ServiceManager注册服务名
ServiceManager.addService(Context.ACTIVITY_SERVICE, ams);

// 客户端查询
IBinder binder = ServiceManager.getService(Context.ACTIVITY_SERVICE);
IActivityManager am = IActivityManager.Stub.asInterface(binder);
// 后续调用直接通过binder进行，不再经过ServiceManager
am.startActivity(...);

在这个场景中，addService将“activity”这个名字与AMS的Binder实体绑定；客户端通过getService("activity")拿到Binder代理；之后的startActivity调用直接通过Binder驱动到达AMS所在进程。ServiceManager只在注册和查询两个瞬间被访问，之后便退居幕后。