Android Framework源码解析:SystemServiceManager 完全解析—

Android Framework源码解析:SystemServiceManager 完全解析——系统服务启动核心原理

前言

前面我们完整梳理了 Android 开机启动完整链路：

init 进程 → Zygote 进程孵化 → system_server 进程启动 → 应用进程 fork

我们知道：Zygote 是 Android 的进程孵化器，依靠 COW 写时复制机制，让所有应用进程共享系统预加载资源，极大提升应用启动速度。

而 system_server 是 Android Framework 最核心的系统进程，系统所有核心能力（AMS、WMS、PMS、PKMS、蓝牙、窗口管理、包管理等）全部运行在该进程中。

但很多同学会有一个核心疑问：

system_server 仅仅是一个进程，它内部成千上百个系统服务到底是谁创建的？谁统一管理？谁控制启动顺序、生命周期、异常容错？

答案就是：SystemServiceManager（系统服务管理器，简称 SSM）。

本篇文章将从 ServiceManager 底层原理 → SSM 初始化 → 服务反射创建流程 → 完整生命周期 → 分级启动机制 → 四大核心底层机制 全方位吃透 Android 系统服务启动源码，读完彻底打通 Framework 开机核心逻辑。

一、先厘清：ServiceManager 底层启动原理（必懂基础）

1.1 ServiceManager 是什么？

ServiceManager 是 Android Binder 架构的全局服务注册表 & 跨进程通信中转站。

它是一个独立原生进程，由 init 进程优先拉起，启动时机 早于 Zygote、早于 system_server。

所有系统服务、App 跨进程通信，全部依赖 ServiceManager 完成服务寻址。

1.2 ServiceManager 启动 rc 配置

路径：/frameworks/native/cmds/servicemanager/servicemanager.rc

service servicemanager /system/bin/servicemanager    class core animation    user system    group system readproc    critical    file /dev/kmsg w    onrestart setprop servicemanager.ready false    onrestart restart --only-if-running apexd    task_profiles ProcessCapacityHigh    shutdown critical

系统 rc 服务分为三个优先级：core > main > late_start，ServiceManager 属于 core 核心进程，系统最高优先级，保障系统基础通信能力永不宕机。

1.3 ServiceManager 核心启动流程（main.cpp）

源码路径：frameworks/native/cmds/servicemanager/main.cpp

// servicemanager进程入口// 源码路径：frameworks/native/cmds/servicemanager/main.cpp// 编译产物：/system/bin/servicemanager// 作用：Android系统Binder全局上下文管理器，全系统唯一的服务注册/查询中转站int main(int argc, char** argv) {    // ====== 1. 日志系统初始化 ======    // 输出到内核缓冲区/dev/kmsg，可通过dmesg抓取    android::base::InitLogging(argv, android::base::KernelLogger);    // ====== 2. 启动参数校验 ======    if(argc > 2) {        LOG(FATAL) << "usage: " << argv[0] << " [binder driver]";    }    // 默认使用/dev/binder驱动；vndservicemanager会传/dev/vndbinder    const char* driver = argc == 2 ? argv[1] : "/dev/binder";    // ====== 3. 性能追踪埋点注册 ======#if !defined(VENDORSERVICEMANAGER) && !defined(__ANDROID_RECOVERY__)    android::register_perfetto_te_categories();#endif    LOG(INFO) << "Starting sm instance on " << driver;    // ====== 4. 初始化Binder进程环境 ======    // 打开Binder驱动、完成mmap内存映射    sp<ProcessState> ps = ProcessState::initWithDriver(driver);    // 关闭多线程：ServiceManager逻辑简单，单线程避免并发锁冲突    ps->setThreadPoolMaxThreadCount(0);    // 只允许oneway异步调用，防止被某个客户端同步阻塞导致全系统服务查询卡死    ps->setCallRestriction(ProcessState::CallRestriction::FATAL_IF_NOT_ONEWAY);    // 关闭后台调度限制，保证高优先级运行    IPCThreadState::self()->disableBackgroundScheduling(true);    // ====== 5. 创建服务管理核心实例 ======    // 内部维护哈希表：key=服务名, value=Binder对象    // Access模块负责SELinux权限拦截    sp<ServiceManager> manager = sp<ServiceManager>::make(std::make_unique<Access>());    manager->setRequestingSid(true);    // ====== 6. 将自己注册为根服务 "manager" ======    auto addRet = manager->addService(        "manager", manager, false /*allowIsolated*/,        IServiceManager::DUMP_FLAG_PRIORITY_DEFAULT);    if(!addRet.isOk()) {        LOG(ERROR) << "Could not self register servicemanager";    }    // ====== 7. 抢占Binder全局唯一上下文管理器身份 ======    IPCThreadState::self()->setTheContextObject(manager);    // 向Binder驱动发起ioctl，系统同时只能有一个进程抢占成功    if(!ps->becomeContextManager()) {        LOG(FATAL) << "Could not become context manager";    }    // ====== 8. 创建Looper，监听Binder请求 ======    sp<Looper> looper = Looper::prepare(false /*allowNonCallbacks*/);    sp<BinderCallback> binderCallback = BinderCallback::setupTo(looper);    ClientCallbackCallback::setupTo(looper, manager, binderCallback);    // ====== 9. 设置就绪属性 ======#ifndef VENDORSERVICEMANAGER    // system_server会轮询等待此属性，就绪后才开始注册系统服务    if(!SetProperty("servicemanager.ready", "true")) {        LOG(ERROR) << "Failed to set servicemanager ready property";    }#endif    // ====== 10. 主线程永久阻塞循环 ======    // 无请求时挂起不占CPU，有请求时唤醒处理    while(true) {        looper->pollAll(-1);    }    return EXIT_FAILURE;}

核心启动流程拆解：

日志初始化
：绑定内核日志 /dev/kmsg，开机日志可通过 dmesg 抓取
Binder 驱动绑定
：默认打开 /dev/binder 全局驱动，完成 mmap 内存映射
进程策略配置
：关闭多线程、只允许 oneway 异步调用，防止服务管理器被卡死
权限模块加载
：内置 Access 权限校验，拦截非法服务注册
自我注册
：将自己注册为系统唯一根服务 manager
抢占全局上下文身份
：向 Binder 驱动抢占唯一 ContextManager
Looper 死循环阻塞
：永久监听全局 Binder 请求，处理 addService/getService
设置就绪属性
：servicemanager.ready=true，通知 system_server 可以开始注册系统服务

1.4 关键认知：为什么必须独立进程？

如果 ServiceManager 挂在 system_server 内部，一旦 system_server 崩溃重启，整个系统 Binder 通信全部瘫痪。

独立进程设计保证：系统无论如何重启，服务寻址能力始终在线。

二、核心类彻底厘清

很多开发者学不懂系统服务，根源是分不清下面三个类的边界：

2.1 SystemServer（总调度者）

system_server 是系统核心进程，只负责统筹调度：

初始化系统运行环境

创建 SSM 实例

按开机顺序批量启动系统服务

不参与服务具体生命周期管理、不处理业务逻辑。

2.2 SystemServiceManager(SSM)（真正的管理者）

本文核心主角，整个 Android 系统服务的大管家。

全权负责： - 服务反射创建 - 类名去重防重复启动 - 服务实例缓存 - onStart 生命周期调用 - BootPhase 分级回调 - 多用户生命周期分发 - 启动耗时监控与告警 - 异常捕获与日志 - 服务注册封印（sealStartedServices）

2.3 ServiceManager（全局Binder服务注册表）

很多开发者极易混淆 ServiceManager 和 SystemServiceManager，二者名称相似、职能完全不同，是 Framework 核心易错点。ServiceManager 是独立原生进程，不属于 system_server 进程，是整个 Android 系统的 Binder 通信核心中枢。

核心职责：维护全局 Binder 服务注册表，对外提供统一的 addService 服务注册、getService 服务查询能力，负责跨进程服务寻址。所有系统服务（AMS/WMS等）在 SSM 中完成初始化后，最终都会注册到 ServiceManager，供 App、其他系统进程跨进程调用。

核心特点：独立进程、开机优先启动、只做服务寻址、不管理服务生命周期、不参与服务初始化。

2.4 SystemService（服务父类）

所有系统服务的父类（AMS、WMS、PMS、CarService 全部继承它）。

定义统一生命周期规范，只负责自身业务逻辑实现，被 SSM 统一调度。

2.5 ServiceManager 与 SystemServiceManager 核心关系

这是 Framework 开机流程最高频混淆点，两者名字相似、层级不同、进程不同、职责互补、毫无上下级关系。

1）核心区别一句话

SystemServiceManager(SSM)：管「对象生命周期」（进程内、Java层、本地管理）

ServiceManager(SM)：管「跨进程Binder寻址」（全局、Native层、通信管理）

2）完整协作关系

1. SSM 在 system_server 内部，通过反射创建 AMS/WMS/PMS 等服务 Java 实例；

2. SSM 调用服务 onStart() 完成初始化；

3. 服务内部将自身 Binder 句柄 注册到 ServiceManager；

4. 外部 App/其他进程通过 ServiceManager 拿到 Binder 代理，实现跨进程调用。

┌─────────────────── system_server 进程 ───────────────────┐│                                                           ││  ① SSM 通过反射创建 AMS/WMS/PMS 等服务 Java 实例          ││              ↓                                            ││  ② SSM 调用服务 onStart() 完成初始化                       ││              ↓                                            ││  ③ 服务在 onStart() 内调用 publishBinderService()          ││     → 最终调用 ServiceManager.addService() 注册到 SM       ││                                                           │└───────────────────────────────────────────────────────────┘              ↓ Binder跨进程┌──────────── ServiceManager 进程 ──────────────────────────┐│  ④ SM 记录服务名→Binder句柄映射                            ││  ⑤ App/其他进程通过 SM.getService() 获取 Binder 代理        │└───────────────────────────────────────────────────────────┘

3）终极区分口诀

SSM 管生老病死（创建、启动、阶段回调），SM 管对外曝光（注册、查询、跨进程）。

2.6 四者层级关系一句话总结

SystemServer（调度发起）    → SystemServiceManager（进程内管理服务生命周期）        → SystemService（具体业务实现）            → ServiceManager（全局Binder注册暴露，跨进程可调用）

三、SSM 初始化流程（开机必经之路）

3.1 调用链路

SystemServer.main()    → run()        → new SystemServiceManager(mSystemContext)

3.2 核心源码

源码路径：`frameworks/base/services/java/com/android/server/SystemServer.java`

privatevoidrun() {    // 省略环境初始化...    // 创建系统服务管理器（整个系统服务诞生的起点）    mSystemServiceManager = new SystemServiceManager(mSystemContext);    mSystemServiceManager.setStartInfo(mRuntimeRestart,            mRuntimeStartElapsedTime, mRuntimeStartUptime);    mDumper.addDumpable(mSystemServiceManager);    // 全局暴露，供系统内部任意位置获取SSM实例    LocalServices.addService(SystemServiceManager.class, mSystemServiceManager);    // 准备并行初始化线程池（用于加速开机）    SystemServerInitThreadPool tp = SystemServerInitThreadPool.start();    // ...    // 按顺序启动四大类服务    startBootstrapServices(t);   // 引导服务（最核心、最先启动）    startCoreServices(t);        // 核心服务    startOtherServices(t);       // 其他服务    startApexServices(t);        // APEX模块服务（动态模块化服务）}

3.3 SSM 构造方法核心作用

源码路径：frameworks/base/services/core/java/com/android/server/SystemServiceManager.java

public SystemServiceManager(Context context) {    mContext = context;    mServices = new ArrayList<>();    mServiceClassnames = new ArraySet<>();    mNumUserPoolThreads = Math.min(        Runtime.getRuntime().availableProcessors(),        DEFAULT_MAX_USER_POOL_THREADS);  // 默认最大3}| 字段 | 作用 ||------|------|| `mContext` | 系统最高权限上下文，所有服务共用 || `mServices` | 缓存所有已启动的系统服务实例（有序） || `mServiceClassnames` | 服务类名集合，用于去重防止重复启动 || `mNumUserPoolThreads` | 多用户生命周期回调线程池大小，动态适配 CPU 核心数 |

3.4 服务启动的四个阶段 SSM 将服务按重要性和依赖关系分为四批启动：

startBootstrapServices(t); // 系统基础：AMS、PMS、PowerMS、DisplayMS... startCoreServices(t); // 核心能力：BatteryService、UsageStats、WebView... startOtherServices(t); // 其他服务：WMS、InputMS、蓝牙、网络、音频... startApexServices(t); // APEX动态模块：来自可更新的apex模块中的服务

在 startOtherServices 入口，SSM 会记录此时服务数量： // SystemServer.java private void startOtherServices(@NonNull TimingsTraceAndSlog t) { mSystemServiceManager.updateOtherServicesStartIndex(); // ... } 这个索引用于多用户生命周期回调的并行优化——**Bootstrap/Core 服务按顺序回调，Other 服务可以并行回调**，加速多用户场景。

四、系统服务诞生完整源码流程（核心重点）

一个系统服务从无到有，完全由 SSM 的 startService 方法完成。SSM 提供了**三种启动方式**：

4.1 启动方式一：通过 Class 反射创建

最常用方式，编译时已知服务类：

// SystemServer中的典型调用 mSystemServiceManager.startService(PowerManagerService.class); mSystemServiceManager.startService(DisplayManagerService.class);

源码实现：

// SystemServiceManager.javapublic <T extends SystemService> T startService(Class<T> serviceClass) {    try {        final String name = serviceClass.getName();        Slog.i(TAG, "Starting " + name);        Trace.traceBegin(Trace.TRACE_TAG_SYSTEM_SERVER, "StartService " + name);        // 校验：必须继承 SystemService        if (!SystemService.class.isAssignableFrom(serviceClass)) {            throw new RuntimeException("Failed to create " + name                    + ": service must extend " + SystemService.class.getName());        }        final T service;        try {            // 1. 获取 public 构造器（参数为Context）            Constructor<T> constructor = serviceClass.getConstructor(Context.class);            // 2. 反射实例化，传入系统全局上下文            service = constructor.newInstance(mContext);        } catch (InstantiationException ex) {            throw new RuntimeException("Failed to create service " + name                    + ": service could not be instantiated", ex);        } catch (IllegalAccessException ex) {            throw new RuntimeException("Failed to create service " + name                    + ": service must have a public constructor with a Context argument", ex);        } catch (NoSuchMethodException ex) {            throw new RuntimeException("Failed to create service " + name                    + ": service must have a public constructor with a Context argument", ex);        } catch (InvocationTargetException ex) {            throw new RuntimeException("Failed to create service " + name                    + ": service constructor threw an exception", ex);        }        // 进入第二阶段：注册 & 启动        startService(service);        return service;    } finally {        Trace.traceEnd(Trace.TRACE_TAG_SYSTEM_SERVER);    }}

4.2 启动方式二：通过类名字符串创建 用于运行时动态加载的服务（如 APEX 模块中的服务）：

// SystemServiceManager.javapublic SystemService startService(String className) {    final Class<SystemService> serviceClass = loadClassFromLoader(        className, this.getClass().getClassLoader());    return startService(serviceClass);}

4.3 启动方式三：从独立 JAR 包创建

用于 `STANDALONE_SYSTEMSERVER_JARS` 中定义的服务，需要独立 ClassLoader 加载：

// SystemServiceManager.javapublic SystemService startServiceFromJar(String className, String path) {    PathClassLoader pathClassLoader =            SystemServerClassLoaderFactory.getOrCreateClassLoader(                    path, this.getClass().getClassLoader(), isJarInTestApex(path));    final Class<SystemService> serviceClass = loadClassFromLoader(className, pathClassLoader);    return startService(serviceClass);}

4.4 核心逻辑：去重、缓存、执行 onStart 生命周期

无论哪种启动方式，最终都汇聚到这个方法：

// SystemServiceManager.javapublic void startService(@NonNullfinal SystemService service) {    // 1. 去重判断：防止同一服务被重复启动    String className = service.getClass().getName();    if (mServiceClassnames.contains(className)) {        Slog.i(TAG, "Not starting an already started service " + className);        return;    }    mServiceClassnames.add(className);    // 2. 纳入 SSM 统一管理（有序列表）    mServices.add(service);    // 3. 执行服务第一阶段生命周期 onStart    long time = SystemClock.elapsedRealtime();    try {        service.onStart();    } catch (RuntimeException ex) {        throw new RuntimeException("Failed to start service "                + service.getClass().getName()                + ": onStart threw an exception", ex);    }    // 4. 超时告警（默认阈值 50ms），用于开机性能优化    warnIfTooLong(SystemClock.elapsedRealtime() - time, service, "onStart");}

4.5 服务注册封印机制

所有服务启动完毕后，SSM 会"封印"服务列表，禁止后续再注册新服务：

// SystemServiceManager.javapublic void sealStartedServices() {    mServiceClassnames = Collections.emptySet();       // 不再允许新增    mServices = Collections.unmodifiableList(mServices); // 列表不可变}这在 `startApexServices()` 末尾调用，确保开机完成后系统服务列表完全固定。

4.6 为什么 Android 必须用反射创建系统服务？

很多同学疑惑：为什么不直接 new，非要反射？

**核心原因：**| 优势 | 说明 ||------|------|| 解耦框架与业务 | SystemServer 不需要硬编码 new 所有服务类，新增服务无需修改启动核心代码 || 统一规范约束 | 强制所有服务必须拥有 `public Constructor(Context)` 构造器，统一初始化入口 || 批量统一管理 | 一套逻辑兼容上千个系统服务，统一做去重、缓存、耗时监控、异常捕获 || 支持动态加载 | APEX 模块中的服务只能通过类名字符串动态加载，反射是必然选择 || 性能追踪友好 | 统一在 startService 入口埋入 Trace 性能追踪，便于开机性能分析 |

五、系统服务完整四阶段生命周期

所有系统服务，全部遵守 SSM 定义的统一生命周期，有序启动、分层就绪。

源码路径：frameworks/base/services/core/java/com/android/server/SystemService.java

public abstract class SystemService {    private final Context mContext;    // 唯一构造器：子类必须传入Context    public SystemService(@NonNull Context context) {        mContext = context;    }    // ====== 核心生命周期方法 ======    // 阶段1：服务启动入口（必须重写）    // 在这里注册Binder服务、初始化基础数据结构    public abstract void onStart();    // 阶段2：开机分阶段回调（按需重写）    public void onBootPhase(@BootPhase int phase) {}    // 阶段3：多用户生命周期（按需重写）    public void onUserStarting(@NonNullTargetUser user) {}    public void onUserUnlocking(@NonNullTargetUser user) {}    public void onUserUnlocked(@NonNullTargetUser user) {}    public void onUserSwitching(@NullableTargetUserfrom, @NonNullTargetUser to) {}    public void onUserStopping(@NonNullTargetUser user) {}    public void onUserStopped(@NonNullTargetUser user) {}    // 用户支持性判断（优化用，可跳过不支持的用户）    public boolean isUserSupported(@NonNullTargetUser user) {        return true;    }    // ====== 服务注册工具方法 ======    // 注册Binder服务到ServiceManager（供跨进程调用）    protected final void publishBinderService(@NonNullString name, @NonNullIBinder service) {        publishBinderService(name, service, false);    }    protected final void publishBinderService(String name, IBinder service,            boolean allowIsolated, int dumpPriority) {        // 最终调用 android.os.ServiceManager.addService()        ServiceManager.addService(name, service, allowIsolated, dumpPriority);    }    // 注册本地服务（仅system_server进程内可用，无需跨进程）    protected final <T> void publishLocalService(Class<T> type, T service) {        LocalServices.addService(type, service);    }}

5.2 生命周期完整执行链路

反射实例化对象（Constructor）    → onStart()：初始化 & 注册 Binder 服务        → onBootPhase(100)：等待默认屏幕        → onBootPhase(200)：等待传感器服务        → onBootPhase(480)：锁屏设置就绪        → onBootPhase(500)：系统核心服务就绪        → onBootPhase(520)：设备特定服务就绪        → onBootPhase(550)：ActivityManager就绪        → onBootPhase(600)：三方App可启动        → onBootPhase(1000)：开机彻底完成            → 多用户生命周期回调

5.3 publishBinderService 实战示例

以 PowerManagerService 为例，看 onStart 中如何将服务注册到 ServiceManager：

// PowerManagerService.java（简化）public final class PowerManagerService extends SystemService {    public PowerManagerService(Context context) {        super(context);        // 构造器中只做轻量初始化    }    @Override    public void onStart() {        // 注册Binder服务到ServiceManager，外部通过"power"名称查找        publishBinderService(Context.POWER_SERVICE, mBinderService);        // 注册本地服务，仅system_server进程内部使用        publishLocalService(PowerManagerInternal.class, mLocalService);        // ...    }    @Override    public void onBootPhase(int phase) {        if (phase == PHASE_SYSTEM_SERVICES_READY) {            // 系统服务就绪后，初始化传感器、显示等依赖            systemReady();        } else if (phase == PHASE_BOOT_COMPLETED) {            // 开机完成后执行最终初始化        }    }}

这里清晰展示了 SSM → SystemService → ServiceManager 的完整协作：

1. SSM 通过反射创建 PowerManagerService

2. 调用 `onStart()` → 内部调用 `publishBinderService()`

3. 最终落到 `ServiceManager.addService("power", binder)` 完成全局注册

六、BootPhase 分级启动机制（核心干货）

6.1 为什么需要 BootPhase 机制？

如果所有系统服务在 `onStart()` 中一次性全部完成初始化：

1、**服务依赖混乱**：A 依赖 B，但 A 先启动时 B 还未就绪，直接崩溃
2、**主线程严重卡顿**：大量耗时操作堆积，开机时间暴涨
3、**无法区分时机**：不同业务需要在不同设备状态下执行（屏幕就绪 vs 用户解锁 vs 开机完成）

Google 解决方案：把系统开机拆分为多个有序阶段，服务把不同逻辑放到不同阶段执行，层层递进、有序就绪。

6.2 Android 完整开机阶段常量（源码最新版本）

所有阶段定义在 `SystemService.java`，数值从小到大代表开机进度递增：

// 最新AOSP源码中的完整阶段定义public static final int PHASE_WAIT_FOR_DEFAULT_DISPLAY       = 100;public static final int PHASE_WAIT_FOR_SENSOR_SERVICE        = 200;public static final int PHASE_LOCK_SETTINGS_READY            = 480;public static final int PHASE_SYSTEM_SERVICES_READY          = 500;public static final int PHASE_DEVICE_SPECIFIC_SERVICES_READY = 520;public static final int PHASE_ACTIVITY_MANAGER_READY         = 550;public static final int PHASE_THIRD_PARTY_APPS_CAN_START     = 600;public static final int PHASE_BOOT_COMPLETED                 = 1000;

6.3 各阶段详解（含执行时机 & 适用场景）

| 阶段 | 值 | 触发位置 | 含义 & 适用场景 ||------|-----|---------|-----------------|| WAIT_FOR_DEFAULT_DISPLAY | 100 | startBootstrapServices 末尾 | 默认显示屏就绪。适合显示、帧率相关底层初始化 || WAIT_FOR_SENSOR_SERVICE | 200 | startOtherServices 开头 | 传感器服务就绪（异步启动完成）。适合依赖传感器的服务 || LOCK_SETTINGS_READY | 480 | startOtherServices 中段 | 锁屏设置数据可读。适合需要读取锁屏/加密配置的服务 || SYSTEM_SERVICES_READY | 500 | startOtherServices 中段 | **核心框架服务全部就绪**（PowerManager/PackageManager 可安全调用）。绝大部分服务依赖此阶段 || DEVICE_SPECIFIC_SERVICES_READY | 520 | startOtherServices 中段 | 设备特定服务就绪。适合依赖厂商定制服务的逻辑 || ACTIVITY_MANAGER_READY | 550 | startOtherServices 中段 | AMS 完全就绪，可以发送广播。适合需要广播或启动四大组件的服务 || THIRD_PARTY_APPS_CAN_START | 600 | startOtherServices 后段 | 三方 App 可以启动、绑定服务。适合需要与 App 交互的初始化逻辑 || BOOT_COMPLETED | 1000 | AMS.finishBooting() | **整机开机彻底完成**。所有延迟逻辑、统计上报、非刚需初始化统一放这里 |

**关键细节**：`PHASE_BOOT_COMPLETED` 不是由 SystemServer 直接调用，而是由 **AMS.finishBooting()** 在开机动画结束后触发。这意味着此阶段执行时用户已经看到桌面。

6.4 底层分发源码原理

// SystemServiceManager.javapublic void startBootPhase(@NonNull TimingsTraceAndSlog t, int phase) {    // 阶段必须严格递增，不能重复或回退    if (phase <= mCurrentPhase) {        throw new IllegalArgumentException("Next phase must be larger than previous");    }    mCurrentPhase = phase;    Slog.i(TAG, "Starting phase " + mCurrentPhase);    try {        t.traceBegin("OnBootPhase_" + phase);        final int serviceLen = mServices.size();        for (int i = 0; i < serviceLen; i++) {            final SystemService service = mServices.get(i);            long time = SystemClock.elapsedRealtime();            t.traceBegin("OnBootPhase_" + phase + "_" + service.getClass().getName());            try {                service.onBootPhase(mCurrentPhase);            } catch (Exception ex) {                throw new RuntimeException("Failed to boot service "                        + service.getClass().getName()                        + ": onBootPhase threw an exception during phase "                        + mCurrentPhase, ex);            }            warnIfTooLong(SystemClock.elapsedRealtime() - time, service, "onBootPhase");            t.traceEnd();        }    } finally {        t.traceEnd();    }    // 开机完成后关闭初始化线程池，释放资源    if (phase == SystemService.PHASE_BOOT_COMPLETED) {        final long totalBootTime = SystemClock.uptimeMillis() - mRuntimeStartUptime;        t.logDuration("TotalBootTime", totalBootTime);        SystemServerInitThreadPool.shutdown();    }}

源码关键点解读：

1. 阶段严格递增：phase <= mCurrentPhase 会直接抛异常，保证开机流程不可逆
2. 全量遍历：每个阶段都会通知**所有已注册服务**，由服务自身决定是否响应
3. 单服务性能追踪：每个服务的每个阶段都有独立的 Trace 标记，systrace 可精确定位耗时服务
4. 开机完成收尾：BOOT_COMPLETED 阶段会打印总开机时间并关闭初始化线程池
6.5 开发规范（系统服务开发必备）

| 逻辑类型 | 应放入阶段 | 原因 ||---------|-----------|------|| Binder 注册、数据结构初始化 | onStart() | 最轻量，不依赖其他服务 || 传感器/硬件相关 | 200 | 等待硬件服务就绪 || 依赖 PMS/PowerMS 等核心服务 | 500 | 确保依赖已就绪 || 需要发送广播、启动 Activity | 550 | AMS 此时才能正常工作 || 需要与三方 App 交互 | 600 | App 进程此后才能启动 || 延迟统计、非刚需初始化 | 1000 | 不拖延开机速度 |

6.6 设计精髓总结

将开机过程拆分为多个确定性阶段，不同服务在不同阶段完成初始化，**解耦服务依赖、串行有序启动、分层就绪、极致优化开机速度**——这是 Android 系统服务稳定运行的核心底层保障。

七、多用户生命周期管理（进阶）

Android 从多用户场景（多用户手机、车载多乘客、工作资料）出发，为系统服务设计了完整的用户级生命周期。

7.1 用户生命周期事件

onUserStarting → onUserUnlocking → onUserUnlocked → onUserSwitching → onUserStopping → onUserStopped

7.2 并行优化机制

SSM 对多用户回调做了精细的并行优化：

// SystemServiceManager.javaprivate boolean useThreadPool(int userId, @NonNullString onWhat) {    switch (onWhat) {        case USER_STARTING:            // 低内存设备和系统用户不并行（安全优先）            return !ActivityManager.isLowRamDeviceStatic()                    && userId != UserHandle.USER_SYSTEM;        case USER_COMPLETED_EVENT:            return true;  // 完成事件总是并行        default:            return false;    }}private boolean useThreadPoolForService(@NonNullString onWhat, int serviceIndex) {    switch (onWhat) {        case USER_STARTING:            // 只有"Other"类别的服务才放入线程池并行            // Bootstrap/Core服务仍然串行，保证核心服务依赖正确            return serviceIndex >= sOtherServicesStartIndex;        case USER_COMPLETED_EVENT:            return true;        default:            return false;    }}

设计亮点：

1、Bootstrap/Core 服务（索引 < sOtherServicesStartIndex）：严格串行，保证依赖顺序
2、Other 服务：**线程池并行**，加速多用户启动
3、线程池大小 = min(CPU核心数, 3)，超时上限 30 秒
4、低内存设备强制串行，避免内存压力
7.3 isUserSupported 优化
服务可以通过重写 isUserSupported() 声明自己不支持某类用户，SSM 会自动跳过回调：
```
// SSM内部逻辑boolean supported = service.isUserSupported(curUser);if (!supported && prevUser != null) {    supported = service.isUserSupported(prevUser);}if (!supported) {    continue;  // 跳过不支持此用户的服务}
```
八、SSM 四大核心底层机制（Framework 精髓）
8.1 BootPhase 分级启动机制
已在第六章深入分析。核心价值：**解耦服务依赖、有序启动、开机加速**。
8.2 服务依赖自动管理机制
Android 没有像 Spring 那样显式声明依赖注入，而是通过**启动顺序 + 阶段回调**隐性解决依赖：
Bootstrap 服务最先启动：AMS、PMS、PowerMS 等基础设施无条件先就绪
阶段回调保证时序：后续服务在 `onBootPhase(500)` 时可以安全获取核心服务引用
LocalServices 提供进程内服务发现：无需跨进程即可获取其他服务的内部接口

// 典型模式：在阶段回调中安全获取依赖@OverridepublicvoidonBootPhase(int phase) {    if (phase == PHASE_SYSTEM_SERVICES_READY) {        // 此时 PowerManager、PackageManager 已就绪        mPowerManager = getContext().getSystemService(PowerManager.class);        mPackageManager = LocalServices.getService(PackageManagerInternal.class);    }}

8.3 耗时监控与性能告警机制

SSM 对每个操作都做了细粒度耗时监控：

// SystemServiceManager.javaprivate static final int SERVICE_CALL_WARN_TIME_MS = 50; // 50ms告警阈值privatevoidwarnIfTooLong(long duration, SystemService service, String operation){    if (duration > SERVICE_CALL_WARN_TIME_MS) {        Slog.w(TAG, "Service " + service.getClass().getName()                + " took " + duration + " ms in " + operation);    }}

配合TimingsTraceAndSlog 和 Trace.traceBegin/traceEnd，开发者可以通过 **Perfetto/systrace** 精确定位开机耗时瓶颈。在 `PHASE_BOOT_COMPLETED` 阶段，SSM 还会记录总开机时间：

final long totalBootTime = SystemClock.uptimeMillis() - mRuntimeStartUptime;t.logDuration("TotalBootTime", totalBootTime);

8.4 服务异常容错机制

SSM 对服务生命周期回调的异常处理策略：

| 操作 | 异常处理策略 | 原因 ||------|------------|------|| onStart() | **直接崩溃** system_server | 启动失败的核心服务会导致系统不可用 || onBootPhase() | **直接崩溃** system_server | 关键阶段初始化失败系统无法正常运行 || onUser*() 回调 | **记录 WTF 日志但不崩溃** | 单用户问题不应影响整机 |```java// onUser回调中的容错处理} catch(Exception ex) {    // Slog.wtf 会记录到 dropbox，但不会杀死进程    logFailure(onWhat, curUser, serviceName, ex);}

这种分级容错设计确保：

核心服务问题 → 触发 system_server 重启（Watchdog 恢复）

用户级问题 → 记录日志但系统继续运行

九、完整流程时序图

init 进程  │  ├── 启动 ServiceManager（core类，最先启动）  │       → 打开 /dev/binder  │       → 抢占 Context Manager  │       → Looper 循环等待  │       → 设置 servicemanager.ready=true  │  ├── 启动 Zygote  │       → fork system_server  │  └── system_server 进程          │          ├── new SystemServiceManager(context)          │          ├── startBootstrapServices()          │   ├── SSM.startService(Installer.class)          │   ├── SSM.startService(AMS.class)          │   ├── SSM.startService(PowerManagerService.class)          │   ├── SSM.startService(DisplayManagerService.class)          │   ├── ...          │   └── SSM.startBootPhase(100)  // WAIT_FOR_DEFAULT_DISPLAY          │          ├── startCoreServices()          │   ├── SSM.startService(BatteryService.class)          │   ├── SSM.startService(UsageStatsService.class)          │   └── ...          │          ├── startOtherServices()          │   ├── SSM.updateOtherServicesStartIndex() ← 记录并行边界          │   ├── SSM.startBootPhase(200)  // WAIT_FOR_SENSOR_SERVICE          │   ├── SSM.startBootPhase(480)  // LOCK_SETTINGS_READY          │   ├── SSM.startBootPhase(500)  // SYSTEM_SERVICES_READY          │   ├── SSM.startBootPhase(520)  // DEVICE_SPECIFIC_SERVICES_READY          │   ├── SSM.startBootPhase(550)  // ACTIVITY_MANAGER_READY          │   ├── SSM.startBootPhase(600)  // THIRD_PARTY_APPS_CAN_START          │   └── ...          │          ├── startApexServices()          │   ├── SSM.startServiceFromJar(...)  ← APEX模块服务          │   └── SSM.sealStartedServices()     ← 封印！禁止后续注册          │          └── AMS.finishBooting()              └── SSM.startBootPhase(1000)  // BOOT_COMPLETED                  └── SystemServerInitThreadPool.shutdown()  ← 释放初始化线程池

十、总结

| 组件 | 角色 | 核心职责 ||------|------|---------|| **ServiceManager** | Binder 全局路由 | 独立进程，服务注册/查询，跨进程寻址 || **SystemServer** | 进程容器 & 调度者 | 创建 SSM，按序批量启动服务 || **SystemServiceManager** | 服务大管家 | 反射创建、去重、缓存、生命周期、分级回调、性能监控、封印 || **SystemService** | 服务父类 | 定义统一规范，子类实现具体业务 |**系统服务完整生命链路**：SSM反射实例化服务  → onStart() 初始化 & publishBinderService 注册到 ServiceManager    → onBootPhase() 分级就绪      → onUser*() 多用户生命周期回调        → sealStartedServices() 封印服务列表

结语

读懂 SystemServiceManager，就彻底打通了 Android 系统服务启动的核心原理。后续所有 AMS、WMS、车载 CarService、系统权限、开机流程源码分析，全部基于这套机制运行。

核心收获：

1. 理解了 ServiceManager（Binder 通信中枢）与 SystemServiceManager（Java 服务管理）的本质区别
2. 掌握了系统服务从反射创建到 Binder 注册的完整流程
3. 深入理解了 BootPhase 分级启动的设计哲学和源码实现
4. 了解了多用户并行优化、耗时监控、异常容错等工程细节

后续文章将继续深入：AMS 启动与服务注册全流程、WMS 窗口管理初始化、系统服务 Binder 通信完整链路**，持续深耕 Framework 底层原理。

前言