【吃透源码系列】之Android系统启动（三）启动服务

在上一篇文章中，我们深入分析了 init.rc 的语法结构和解析机制。本文将继续沿着 Android 系统启动的时间线，详细追踪 init 进程如何从解析 rc 文件到启动系统核心服务（包括 ServiceManager、Zygote 和 SystemServer）的完整链路。本文基于 Android 11 (API 30) 的 AOSP 源码进行分析。

一、从 init.rc 解析到服务启动

1.1 init main 函数中的服务启动触发序列

回顾 init 进程的第二阶段（SecondStageMain），它按顺序触发以下事件：

// system/core/init/init.cpp
int SecondStageMain(int argc, char** argv) {
    // ... 属性服务、SELinux 等初始化 ...

    // 加载所有启动脚本（init.rc 及所有 import 的文件）
    LoadBootScripts(am, sm);

    // 触发 early-init 事件
    am.QueueEventTrigger("early-init");

    // 等待冷启动完成（ueventd 创建设备节点）
    am.QueueBuiltinAction(wait_for_coldboot_done_action, "wait_for_coldboot_done");

    // 触发 init 事件
    am.QueueEventTrigger("init");

    // 触发 late-init 事件（关键！这里会触发 Zygote 启动）
    std::string bootmode = GetProperty("ro.bootmode", "");
    if (bootmode == "charger") {
        am.QueueEventTrigger("charger");
    } else {
        am.QueueEventTrigger("late-init");
    }

    // 进入主事件循环
    while (true) {
        if (!(waiting_for_prop || Service::is_exec_service_running())) {
            am.ExecuteOneCommand();
        }
        if (!(waiting_for_prop || Service::is_exec_service_running())) {
            RestartProcesses();
        }
        // epoll_wait 等待事件...
    }
}

核心流程是：LoadBootScripts 加载并解析所有 rc 文件，然后将解析后的 Action 和 Service 存入 ActionManager 和 ServiceList，最后通过触发器机制依次执行各阶段的任务。

1.2 LoadBootScripts 加载 rc 文件

// system/core/init/init.cpp
static void LoadBootScripts(ActionManager& action_manager, ServiceList& service_list) {
    Parser parser = CreateParser(action_manager, service_list);

    std::string bootscript = GetProperty("ro.boot.init_rc", "");
    if (bootscript.empty()) {
        parser.ParseConfig("/system/etc/init/hw/init.rc");
        // 加载所有 import 引用的 rc 文件
        parser.set_is_system_etc_init_loaded(true);
        parser.ParseConfig("/system/etc/init");
        // 加载供应商 rc
        parser.ParseConfig("/vendor/etc/init");
        // 加载 odm rc
        parser.ParseConfig("/odm/etc/init");
        // 加载 product rc
        parser.ParseConfig("/product/etc/init");
    } else {
        parser.ParseConfig(bootscript);
    }
}

CreateParser 创建了解析器，并向其中注册了所有内置命令（BuiltinFunctionMap）和关键字映射。解析器会逐行扫描 rc 文件，通过 SectionParser 接口处理每一行文本，最终构建出 Action、Service、Import 等对象。

1.3 Parser 创建与 SectionParser 体系

// system/core/init/parser.cpp
Parser CreateParser(ActionManager& action_manager, ServiceList& service_list) {
    Parser parser;

    // 注册 Action section 解析器
    parser.AddSectionParser("on", std::make_unique<ActionParser>(&action_manager, &subcontexts));
    // 注册 Service section 解析器
    parser.AddSectionParser("service", std::make_unique<ServiceParser>(&service_list, &subcontexts));
    // 注册 Import section 解析器
    parser.AddSectionParser("import", std::make_unique<ImportParser>(&parser));

    return parser;
}

这三种 SectionParser 分别对应 rc 文件中 on <trigger>、service <name> 和 import <path> 语句的解析。当 Parser 遇到 “on” 开头的行，就委托给 ActionParser；遇到 “service” 开头的行，则委托给 ServiceParser。

1.4 ActionParser 解析 Action 语句

// system/core/init/action_parser.cpp
class ActionParser : public SectionParser {
  public:
    Result<void> ParseSection(std::vector<std::string>&& args,
                              const std::string& filename, int line) override {
        // args[0] = "on", args[1] = trigger name, args[2..] = trigger subparameters
        std::vector<std::string> triggers(args.begin() + 1, args.end());
        if (triggers.size() < 1) {
            return Error() << "Actions must have a trigger";
        }

        std::string event_trigger;
        std::map<std::string, std::string> property_triggers;

        // 解析触发器：区分 event trigger 和 property trigger
        for (const auto& trigger : triggers) {
            if (!is_property_trigger) {
                event_trigger = trigger;
            } else {
                // 如 "property:sys.boot_completed=1"
                property_triggers[name] = value;
            }
        }

        // 创建 Action 对象
        action_ = std::make_unique<Action>(false, subcontext_, filename, line,
                                            event_trigger, property_triggers);
        return {};
    }

    Result<void> ParseLineSection(std::vector<std::string>&& args, int line) override {
        // 向 action_ 中添加 Command 对象（通过函数映射查找对应的命令实现）
        return action_ ? action_->AddCommand(std::move(args), line) : Result<void>{};
    }

    Result<void> EndSection() override {
        // 将构建好的 Action 注册到 ActionManager
        if (action_ && action_->NumCommands() > 0) {
            action_manager_->AddAction(std::move(action_));
        }
        return {};
    }
};

每一个 on <trigger> ... 块被解析为一个 Action 对象，其内部包含一个 Command 列表。Command 的实现来自 BuiltinFunctionMap，它是一个从命令名字符串到函数指针的映射表。

二、Service 解析与启动机制

2.1 ServiceParser 解析 Service 语句

// system/core/init/service_parser.cpp
class ServiceParser : public SectionParser {
  public:
    Result<void> ParseSection(std::vector<std::string>&& args,
                              const std::string& filename, int line) override {
        // args[0] = "service", args[1] = service name, args[2] = binary path
        const std::string& name = args[1];
        const std::string& path = args[2];

        // 提取传递给 binary 的参数（args[3...]）
        std::vector<std::string> str_args(args.begin() + 3, args.end());

        // 创建 Service 对象
        service_ = std::make_unique<Service>(name, subcontext, str_args);
        return {};
    }

    Result<void> ParseLineSection(std::vector<std::string>&& args, int line) override {
        // 解析 service 块内的 option 行（如 class, user, group, oneshot, disabled, socket 等）
        // 通过 keyword map 找到对应的处理函数
        return service_ ? service_->HandleLine(args, line) : Result<void>{};
    }

    Result<void> EndSection() override {
        // 将构建好的 Service 注册到 ServiceList
        if (service_) {
            service_manager_->AddService(std::move(service_));
        }
        return {};
    }
};

2.2 Service Option 的解析——keyword_map

keyword_map.h 定义了 Service 可用的所有 option 关键字及其处理函数指针：

// system/core/init/keyword_map.h
template <typename T>
class KeywordMap {
  public:
    void AddMap(const std::string& keyword, T function) {
        map_[keyword] = function;
    }
    // 查找关键字对应的处理函数
    T Find(const std::string& keyword) const {
        auto it = map_.find(keyword);
        return it != map_.end() ? it->second : nullptr;
    }
};

Service 类在初始化时注册所有 option 关键字：

// system/core/init/service.cpp
Service::OptionHandlerMap Service::sHandlerMap = {
    {"class",       {1,    1,    &Service::HandleClass}},
    {"user",        {1,    1,    &Service::HandleUser}},
    {"group",       {1,    NR_SVC_SUPP_GIDS, &Service::HandleGroup}},
    {"capabilities",{1,    1,    &Service::HandleCapabilities}},
    {"oneshot",     {0,    0,    &Service::HandleOneshot}},
    {"disabled",    {0,    0,    &Service::HandleDisabled}},
    {"critical",    {0,    0,    &Service::HandleCritical}},
    {"socket",      {3,    6,    &Service::HandleSocket}},
    {"seclabel",    {1,    1,    &Service::HandleSeclabel}},
    {"setenv",      {2,    2,    &Service::HandleSetenv}},
    {"onrestart",   {1,    kMax, &Service::HandleOnrestart}},
    {"writepid",    {1,    kMax, &Service::HandleWritepid}},
    {"priority",    {1,    1,    &Service::HandlePriority}},
    {"namespace",   {1,    2,    &Service::HandleNamespace}},
    {"oom_score_adjust", {1, 1, &Service::HandleOomScoreAdjust}},
    {"memcg.swappiness", {1, 1, &Service::HandleMemcgSwappiness}},
    {"memcg.soft_limit_in_bytes", {1, 1, &Service::HandleMemcgSoftLimitInBytes}},
    {"memcg.limit_in_bytes", {1, 1, &Service::HandleMemcgLimitInBytes}},
    {"rlimit",      {3,    3,    &Service::HandleRlimit}},
    // ... 更多
};

例如，HandleClass 的实现：

// system/core/init/service.cpp
Result<void> Service::HandleClass(const std::vector<std::string>& args) {
    classnames_.push_back(args[1]);  // 将 class 名添加到 service 的 class 列表
    return {};
}

2.3 Service 的启动流程

当一个 Service 需要启动时（如通过 class_start core 触发），调用链如下：

Action::ExecuteOneCommand()
→ Command::InvokeFunc()           // builtin 命令（如 class_start）
→ builtin_commands.cpp::do_class_start()
→ ServiceList::ForEachServiceInClass()
→ Service::Start()

// system/core/init/service.cpp
Result<void> Service::Start() {
    // 1. 检查是否已启动
    if (flags_ & SVC_RUNNING) {
        return {};
    }

    // 2. 检查是否被禁用
    if (flags_ & SVC_DISABLED) {
        return {};
    }

    // 3. 检查必要的运行时资源
    // ...

    // 4. 创建子进程
    pid_t pid = fork();
    if (pid == 0) {
        // 子进程
        umask(077);

        // 设置环境变量
        for (const auto& [key, val] : environment_) {
            setenv(key.c_str(), val.c_str(), 1);
        }

        // 应用 service 配置：用户、组、能力、SELinux 上下文等
        // ...
        if (!ExpandArgsAndExecv(args_, sigstop_)) {
            PLOG(ERROR) << "cannot execv('" << args_[0] << "')";
        }
        _exit(127);
    }

    // 5. 父进程继续
    pid_ = pid;
    flags_ |= SVC_RUNNING;
    start_order_ = next_start_order_++;

    // 6. 如果是 oneshot 且没有 disabled，一旦启动就不保持 running 状态
    // ...

    return {};
}

2.4 class_start 的实现

// system/core/init/builtin_commands.cpp
static Result<void> do_class_start(const BuiltinArguments& args) {
    // 启动指定 service class 下的所有未启动 service
    for (const auto& service : ServiceList::GetInstance().services_in_class(args[1])) {
        if (!service->IsRunning()) {
            service->Start();
        }
    }
    return {};
}

三、ServiceManager 启动：Binder 大管家

3.1 ServiceManager 在 init.rc 中的定义

# system/core/rootdir/init.rc
service servicemanager /system/bin/servicemanager
    class core animation
    user system
    group system readproc
    critical
    onrestart restart zygote
    onrestart restart media
    onrestart restart surfaceflinger
    onrestart restart audioserver
    writepid /dev/cpuset/system-background/tasks
    shutdown critical

servicemanager 被归类为 core 类，且标记为 critical。一旦它 crash，会在 4 分钟内重启超过 4 次的话设备将重启进入 recovery 模式。同时通过 onrestart 配置，servicemanager 重启时会连带重启 zygote、media、surfaceflinger 和 audioserver。

3.2 ServiceManager 源码分析

ServiceManager 是 Binder 体系的服务注册中心，所有 Binder 服务（AMS、WMS、PMS 等）都通过它将自身注册出来供其他进程查询。

// frameworks/native/cmds/servicemanager/service_manager.c
int main(int argc, char** argv) {
    // 1. 打开 Binder 驱动
    struct binder_state *bs;
    bs = binder_open("/dev/binder", 128*1024);
    if (!bs) {
        ALOGE("failed to open binder driver\n");
        return -1;
    }

    // 2. 将自身注册为 Binder 上下文管理器（handle = 0）
    if (binder_become_context_manager(bs)) {
        ALOGE("cannot become context manager (%s)\n", strerror(errno));
        return -1;
    }

    // 3. 获取 SELinux 上下文
    selinux_enabled = is_selinux_enabled();
    sehandle = selinux_status_open();
    // ...

    // 4. 进入主循环，等待并处理 Binder 请求
    binder_loop(bs, svcmgr_handler);

    return 0;
}

binder_become_context_manager 向 Binder 驱动发送 BINDER_SET_CONTEXT_MGR ioctl 命令，将自身登记为上下文管理器。此后，其他进程通过 BINDER_WRITE_READ ioctl 向 ServiceManager 发送 SVC_MGR_ADD_SERVICE 来注册服务，发送 SVC_MGR_GET_SERVICE / SVC_MGR_CHECK_SERVICE 来查询服务。

ServiceManager 中的 svcmgr_handler 函数处理这些请求：

// frameworks/native/cmds/servicemanager/service_manager.c
int svcmgr_handler(struct binder_state *bs,
                   struct binder_transaction_data *txn,
                   struct binder_io *msg,
                   struct binder_io *reply) {
    // 根据 txn->code 分发到不同的处理逻辑
    switch(txn->code) {
    case SVC_MGR_GET_SERVICE:
    case SVC_MGR_CHECK_SERVICE:
        // 根据服务名查找 Binder handle
        handle = do_find_service(s, len, txn->sender_euid, txn->sender_pid);
        bio_put_ref(reply, handle);
        return 0;

    case SVC_MGR_ADD_SERVICE:
        // 注册新的 Binder 服务
        if (do_add_service(bs, s, len, handle, txn->sender_euid, allow_isolated, txn->sender_pid))
            return -1;
        break;

    case SVC_MGR_LIST_SERVICES:
        // 列出已注册的服务
        // ...
    }
}

3.3 ServiceManager 在 Android 10+ 的变迁

从 Android 10 开始，Google 引入了一个兼容的 ServiceManager 替代实现——使用 Binder Driver V2 的 vndservicemanager 专门管理 vendor 域的服务，实现了 system 和 vendor 服务的分离：

// frameworks/native/cmds/servicemanager/main.cpp (Android 10+ 用 C++ 重写)
int main(int argc, char* argv[]) {
    if (argc > 1) {
        // "vndservicemanager" 专门管理 /dev/vndbinder
        if (strcmp(argv[1], "vndservicemanager") == 0) {
            return VndServiceManager::main(argc, argv);
        }
    }
    return ServiceManager::main(argc, argv);
}

这种分离的目的是加强 Treble 架构下的隔离性：system 分区的服务运行在 /dev/binder 上，vendor 分区的 HAL 服务运行在 /dev/vndbinder 上，互不干扰。

四、Zygote 启动：Java 世界的造物主

4.1 Zygote 在 init.rc 中的定义

# system/core/rootdir/init.zygote64.rc (以 64 位为例)
service zygote /system/bin/app_process64 -Xzygote /system/bin --zygote --start-system-server
    class main
    priority -20
    user root
    group root readproc reserved_disk
    socket zygote stream 660 root system
    socket usap_pool_primary stream 660 root system
    onrestart restart audioserver
    onrestart restart cameraserver
    onrestart restart media
    onrestart restart netd
    onrestart restart wificond
    writepid /dev/cpuset/foreground/tasks

关键信息：

• Zygote 的二进制文件是 app_process64（或 app_process32），通过参数 --zygote --start-system-server 告知它进入 Zygote 模式。
• Zygote 创建了 zygote 和 usap_pool_primary 两个 socket，这是后续 AMS 向 Zygote 请求 fork 新进程的通信通道。
• Zygote 的 class 是 main，由 class_start main 统一启动。

4.2 app_process 的 native 入口

// frameworks/base/cmds/app_process/app_main.cpp
int main(int argc, char* const argv[]) {
    // 创建 AppRuntime（继承自 AndroidRuntime）
    AppRuntime runtime(argv[0], computeArgBlockSize(argc, argv));

    // 解析命令行参数
    bool zygote = false;
    bool startSystemServer = false;
    String8 niceName;
    String8 className;

    int i = runtime.addVmArguments(argc, argv);
    if (i < argc) {
        // 检查 "--zygote" 参数
        if (strcmp(argv[i], "--zygote") == 0) {
            zygote = true;
            // 记录 zygote 类型：zygote64 / zygote64_32 / zygote32
            niceName = ZYGOTE_NICE_NAME;
        }
        // 检查 "--start-system-server" 参数
        if (strcmp(argv[i], "--start-system-server") == 0) {
            startSystemServer = true;
        }
    }

    // 设置进程名
    if (!niceName.isEmpty()) {
        runtime.setArgv0(niceName.string(), true);
    }

    if (zygote) {
        // 进入 ZygoteInit，参数是 startSystemServer
        runtime.start("com.android.internal.os.ZygoteInit", args, startSystemServer);
    } else {
        // 普通 app_process 模式（如 am 命令）
        runtime.start("com.android.internal.os.RuntimeInit", args, false);
    }
}

4.3 AndroidRuntime.start——初始化 ART 虚拟机

// frameworks/base/core/jni/AndroidRuntime.cpp
void AndroidRuntime::start(const char* className, const Vector<String8>& options,
                           bool zygote) {
    // 1. 启动 ART 虚拟机
    JniInvocation jni_invocation;
    jni_invocation.Init(NULL);
    JNIEnv* env;
    if (startVm(&mJavaVM, &env, zygote, primary_zygote) != 0) {
        return;
    }
    onVmCreated(env);

    // 2. 注册 Android 框架的 JNI 方法
    if (startReg(env) < 0) {
        ALOGE("Unable to register all android natives\n");
        return;
    }

    // 3. 通过反射调用 Java 类的 main 方法
    // 对于 Zygote：调用 com.android.internal.os.ZygoteInit.main()
    char* slashClassName = toSlashClassName(className != NULL ? className : "");
    jclass startClass = env->FindClass(slashClassName);
    jmethodID startMeth = env->GetStaticMethodID(startClass, "main",
            "([Ljava/lang/String;)V");
    env->CallStaticVoidMethod(startClass, startMeth, strArray);
}

4.4 ZygoteInit.main——Java 层核心逻辑

// frameworks/base/core/java/com/android/internal/os/ZygoteInit.java
public static void main(String argv[]) {
    ZygoteServer zygoteServer = null;

    try {
        // 1. 预加载系统类库和资源（此步骤极其耗时）
        preload(bootTimingsTraceLog);

        // 2. 创建 ZygoteServer，打开本地 socket
        zygoteServer = new ZygoteServer(isPrimaryZygote);

        if (startSystemServer) {
            // 3. Fork 出 system_server 进程
            Runnable r = forkSystemServer(abiList, zygoteSocketName, zygoteServer);
            if (r != null) {
                // 在 system_server 子进程中执行
                r.run();
                return;
            }
        }

        // 4. Zygote 进入主循环：监听 socket，等待 AMS 的 fork 请求
        caller = zygoteServer.runSelectLoop(abiList);
    } catch (Throwable ex) {
        throw ex;
    } finally {
        if (zygoteServer != null) {
            zygoteServer.closeServerSocket();
        }
    }

    // 5. 处理每次 fork 请求（每个子进程从这里开始运行）
    if (caller != null) {
        caller.run();
    }
}

4.5 Zygote 的预加载过程

预加载是 Zygote 启动中最耗时的阶段，但它也是 Android 能快速启动应用的关键机制：

// frameworks/base/core/java/com/android/internal/os/ZygoteInit.java
static void preload(TimingsTraceLog bootTimingsTraceLog) {
    // 1. 预加载 classes（frameworks/base/preloaded-classes 列表中的类）
    preloadClasses();

    // 2. 预加载资源（drawable, color, anim 等）
    preloadResources();

    // 3. 预加载 OpenGL 驱动
    preloadOpenGL();

    // 4. 预加载系统共享库
    preloadSharedLibraries();

    // 5. 预加载文本区域（TextLayout）
    preloadTextResources();

    // 6. 初始化 WebView Factory
    WebViewFactory.prepareWebViewInZygote();
}

预加载的好处是：fork 出的子进程共享父进程（Zygote）的内存页，不需要每个 App 都重新加载这些通用类库和资源，大大加速了应用启动速度。

4.6 forkSystemServer

// frameworks/base/core/java/com/android/internal/os/ZygoteInit.java
private static Runnable forkSystemServer(String abiList, String socketName,
        ZygoteServer zygoteServer) {
    // 1. 设置 system_server 的启动参数
    String args[] = {
        "--setuid=1000",          // system uid
        "--setgid=1000",          // system gid
        "--setgroups=...",
        "--capabilities=" + capabilities + "," + capabilities,
        "--runtime-args",
        "--nice-name=system_server",
        "--target-sdk-version=" + VMRuntime.SDK_VERSION_CUR_DEVELOPMENT,
        "com.android.server.SystemServer",
    };

    // 2. 调用 Zygote.forkSystemServer() 进行 fork
    int pid = Zygote.forkSystemServer(
            parsedArgs.uid, parsedArgs.gid,
            parsedArgs.gids,
            parsedArgs.runtimeFlags,
            null,
            parsedArgs.permittedCapabilities,
            parsedArgs.effectiveCapabilities);

    if (pid == 0) {
        // 子进程：返回一个 Runnable，会在 ZygoteInit.main() 中被执行
        return handleSystemServerProcess(parsedArgs);
    }

    // 父进程（Zygote）：返回 null，继续 runSelectLoop
    return null;
}

4.7 Zygote.runSelectLoop

// frameworks/base/core/java/com/android/internal/os/ZygoteServer.java
Runnable runSelectLoop(String abiList) {
    ArrayList<FileDescriptor> socketFDs = new ArrayList<>();
    ArrayList<ZygoteConnection> peers = new ArrayList<>();

    // 注册 socket
    socketFDs.add(mZygoteSocket.getFileDescriptor());
    peers.add(null);

    // USAP pool socket
    if (mUsapPoolSocket != null) {
        socketFDs.add(mUsapPoolSocket.getFileDescriptor());
    }

    while (true) {
        // 使用 poll() 等待新连接（类似 epoll）
        Os.poll(pollFDs, -1);

        for (int i = pollFDs.length - 1; i >= 0; --i) {
            if (i == 0) {
                // 新的连接请求
                ZygoteConnection newPeer = acceptCommandPeer(abiList);
                peers.add(newPeer);
                socketFDs.add(newPeer.getFileDescriptor());
            } else {
                // 已有的连接有数据到达（AMS 发送 fork 请求）
                boolean done = peers.get(i).runOnce(abiList);
                if (done) {
                    peers.remove(i);
                    socketFDs.remove(i);
                }
            }
        }
    }
}

ZygoteConnection.runOnce() 是实际处理 fork 请求的地方。它通过 socket 接收 AMS 发送的参数（进程名、uid/gid、seinfo 等），然后调用 Zygote.forkAndSpecialize() fork 出新的应用进程，并在子进程中调用 ZygoteInit.zygoteInit() 完成初始化（包括 Binder 线程池启动等），最终加载 ActivityThread 并调用其 main() 方法。

五、SystemServer 启动：Android 服务大管家

5.1 SystemServer.main

// frameworks/base/services/java/com/android/server/SystemServer.java
public static void main(String[] args) {
    new SystemServer().run();
}

private void run() {
    // 1. 记录启动时间戳
    final long uptimeMillis = SystemClock.elapsedRealtime();

    // 2. 设置主线程 Looper
    Looper.prepareMainLooper();

    // 3. 加载 android_servers native 库（libandroid_servers.so）
    System.loadLibrary("android_servers");

    // 4. 创建系统上下文
    createSystemContext();

    // 5. 创建 SystemServiceManager
    mSystemServiceManager = new SystemServiceManager(mSystemContext);
    LocalServices.addService(SystemServiceManager.class, mSystemServiceManager);

    // 6. 初始化 ActivityThread
    mActivityManagerService = ActivityManagerService.Lifecycle.startService(
            mSystemServiceManager, atm);

    // 7. 按阶段启动服务
    try {
        t.traceBegin("StartServices");
        startBootstrapServices();     // 引导服务
        startCoreServices();          // 核心服务
        startOtherServices();         // 其他服务
    } catch (Throwable ex) {
        throw ex;
    }

    // 8. 进入主线程消息循环
    Looper.loop();
    throw new RuntimeException("Main thread loop unexpectedly exited");
}

5.2 三个启动阶段的详细分析

第一阶段：startBootstrapServices（引导服务）

引导服务是系统运行的最基础依赖，必须最先启动。包括：

startBootstrapServices() 顺序：
1. Installer (installd 的 Java 代理)           - 软件包安装依赖
2. DeviceIdentifiersPolicyService              - 设备标识策略
3. ActivityManagerService.Lifecycle            - AMS（通过反射启动）
4. PowerManagerService.Lifecycle               - 电源管理
5. RecoverySystemService.Lifecycle             - 恢复系统
6. LightsService.Lifecycle                     - 背光控制
7. DisplayManagerService.Lifecycle             - 显示管理
8. PackageManagerService.main()                - PKMS（此步骤极耗时）
9. UserManagerService.Lifecycle                - 用户管理
10. SensorService                              - 传感器服务

startBootstrapServices() → AMS 构造完成后，调用 AMS.setSystemProcess() 将 AMS 注册到 ServiceManager，使其成为系统中最顶层的 Binder 服务。

第二阶段：startCoreServices（核心服务）

核心服务是系统基础功能，但不属于引导级别依赖：

startCoreServices() 顺序：
1. DropBoxManagerService         - 日志收集
2. BatteryService                - 电池管理
3. UsageStatsService             - 应用使用统计
4. WebViewUpdateService          - WebView 更新
5. BinderCallsStatsService       - Binder 调用统计
6. ... 更多

第三阶段：startOtherServices（其他服务）

这是最大的服务启动阶段，包括 WMS、IMS、BluetoothService、CameraService 等大量系统服务。此阶段通过 SystemServiceManager 统一管理生命周期：

// frameworks/base/services/java/com/android/server/SystemServer.java
private void startOtherServices() {
    // 创建 InputManagerService
    inputManager = new InputManagerService(context);

    // 启动 WMS
    wm = WindowManagerService.main(context, inputManager, ...);
    ServiceManager.addService(Context.WINDOW_SERVICE, wm, ...);

    // 启动 IMS
    inputManager.setWindowManagerCallbacks(wm.getInputMonitor());
    inputManager.start();

    // WMS 通知 AMS 就绪
    mActivityManagerService.setWindowManager(wm);

    // 启动 UI 模式管理、网络策略、闹钟管理、蓝牙、相机...
    // 每个服务启动后可能触发多个阶段的 bootPhase 回调

    // 最终阶段：启动 Launcher
    mActivityManagerService.systemReady(() -> {
        // Phase 550: BOOT_PROGRESS_AMS_READY
        startHomeActivityLocked(mCurrentUserId, "systemReady");
    });
}

5.3 SystemServiceManager 与服务生命周期

SystemServiceManager 是管理所有系统服务生命周期的容器，采用统一的生命周期阶段模型：

// frameworks/base/services/core/java/com/android/server/SystemServiceManager.java
public class SystemServiceManager {
    private final ArrayList<SystemService> mServices = new ArrayList<>();

    // 通过反射创建并启动服务
    public <T extends SystemService> T startService(Class<T> serviceClass) {
        final String name = serviceClass.getName();
        Constructor<T> constructor = serviceClass.getConstructor(Context.class);
        final T service = constructor.newInstance(mContext);
        mServices.add(service);
        service.onStart();  // 调用生命周期方法
        return service;
    }

    // 通知所有已注册服务进入指定的启动阶段
    public void startBootPhase(final int phase) {
        mCurrentPhase = phase;
        final int serviceLen = mServices.size();
        for (int i = 0; i < serviceLen; i++) {
            final SystemService service = mServices.get(i);
            service.onBootPhase(mCurrentPhase);
        }
    }
}

Boot Phase 的关键阶段：

// frameworks/base/services/core/java/com/android/server/SystemService.java
public static final int PHASE_WAIT_FOR_DEFAULT_DISPLAY = 100;
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;

六、总体启动时间线回顾

init 进程 (PID=1)
├── LoadBootScripts (解析 init.rc)
│     ├── ActionParser / ServiceParser
│     └── 构建 ActionManager + ServiceList
├── 触发 early-init
│     ├── 创建关键目录 (/dev, /proc, /sys)
│     ├── ueventd 冷启动（等待所有设备节点）
│     └── 设置 SELinux policy
├── 触发 init
│     ├── 初始化属性服务
│     └── 执行设备初始化命令
├── 触发 late-init
│     ├── class_start core
│     │     ├── servicemanager  (Binder 大管家)
│     │     ├── hwservicemanager (HIDL 服务管理)
│     │     └── vndservicemanager (vendor binder 管理)
│     └── class_start main
│           └── zygote
│                 ├── AndroidRuntime.start()
│                 │     ├── startVm (ART 虚拟机)
│                 │     └── startReg (注册 JNI)
│                 ├── ZygoteInit.main()
│                 │     ├── preload (预加载资源)
│                 │     ├── forkSystemServer
│                 │     │     └── SystemServer.run()
│                 │     │           ├── startBootstrapServices
│                 │     │           ├── startCoreServices
│                 │     │           └── startOtherServices
│                 │     │                 └── AMS.systemReady
│                 │     │                       └── startHomeActivityLocked
│                 │     └── runSelectLoop (主循环)
│                 └── 等待 AMS 的 fork 请求...
└── 进入 epoll 事件循环

七、核心面试题

Q1：Zygote 为什么不直接在 Native 层通过 clone() 创建进程，而要绕到 Java 层通过 ZygoteInit 来管理 fork？

答：Zygote 在 fork 之前进行了大量的预加载工作（preload classes、preload resources、preload OpenGL 等）。这些预加载消耗了大量的内存和时间。通过在 Java 层管理 fork 时机，每个 fork 出的子进程都可以继承 Zygote 已经预加载好的内存页（copy-on-write 机制），从而避免每个 App 进程都重新加载这些共享资源。如果把 fork 逻辑写在 Native 层，虽然技术上可行，但无法方便地管理 Java 层的预加载状态和后续初始化流程，也失去了通过 Java 反射灵活调度不同启动目标的能力（如 RuntimeInit 和 ZygoteInit 的切换）。

Q2：ServiceManager 的 handle 为什么是 0？为什么 Binder 驱动要设计”上下文管理器”这个特殊角色？

答：Binder 驱动需要一个众所周知的入口点来让客户端查询其他服务。这个入口点被设计为 handle 0，即每个 Client 不需要事先知道 ServiceManager 的 Binder 引用，驱动层面约定 handle 0 就是 ServiceManager。客户端通过 BC_TRANSACTION 向 handle 0 发送请求时，驱动自动将其路由到标记为上下文管理器的进程。这种设计避免了”先有鸡还是先有蛋”的问题——如果 ServiceManager 也需要通过名字查找，那么谁先来注册 ServiceManager 自己？handle 0 的硬编码解决了这个 bootstrap 问题。

Q3：init 进程如何决定 system_server 什么时候应该重启？critical flag 的 4 分钟 4 次规则是如何实现的？

答：在 Service 对象的 Reap() 方法中（system/core/init/service.cpp），当子进程退出时检查 SVC_CRITICAL flag。如果该 flag 被设置，init 会记录 crash 时间戳到 time_crashed_ 字段。如果两次 crash 间隔小于 4 分钟，crash_count_ 递增；超过 4 分钟则重置计数为 1。当 crash_count_ > 4 时，init 通过 LOG(FATAL) 触发系统重启进入 recovery 模式。这个机制保护系统不会在关键服务反复崩溃时陷入不可用状态。

Q4：Android 的 init 进程和 Linux 传统 init（如 sysvinit / systemd）的核心区别是什么？

答：Android init 是为嵌入式移动设备专门设计的精简 init 系统，核心差异包括：(1) init.rc 语法——Android 设计了一套自己的声明式配置语言，而不是继承 System V init 的 shell 脚本风格或 systemd 的 unit 文件格式；(2) 内置属性服务——Android init 集成了 property_service，管理全局系统属性，并支持可持久化属性（persist. 前缀），这是传统 Linux init 不具备的；(3) ueventd 集成——Android init 同一二进制文件承担 ueventd 职责，负责 /dev 下设备节点的动态创建，而传统 Linux 依赖 udev；(4) 无运行级别——Android init 使用事件触发器（on boot、on property 等）而不是运行级别（runlevel）来控制服务启动顺序。

Q5：USAP (Unspecialized App Process) 池是什么？它与 Zygote 的关系是什么？

答：USAP 是 Android 10 引入的优化机制。传统 Zygote 模式：AMS 每当需要启动新应用时，都向 Zygote 发送请求，Zygote 要进行 fork + specialize（设置进程属性、uid/gid、seinfo 等），这个过程有固定开销。USAP 池机制：Zygote 在空闲时提前 fork 出一批”未特化”的进程（已 fork 但尚未 specialize），放入池中。当 AMS 请求新进程时，直接从池中取出一个已经存在的进程进行 specialize，跳过了 fork 系统调用的开销。这在高频启动应用的场景（如自动化测试）中能显著提升性能。USAP 通过 usap_pool_primary socket 与 AMS 交互。

AOSP 核心路径参考：

• system/core/init/init.cpp — init 进程主入口
• system/core/init/action_parser.cpp — Action 解析器
• system/core/init/service_parser.cpp — Service 解析器
• system/core/init/service.cpp — Service 类实现（fork/启动/重启）
• system/core/init/keyword_map.h — Service Option 关键字映射
• system/core/init/builtin_commands.cpp — 内置命令实现 (class_start 等)
• system/core/rootdir/init.rc — 主 rc 文件
• frameworks/native/cmds/servicemanager/main.cpp — ServiceManager
• frameworks/base/cmds/app_process/app_main.cpp — Zygote Native 入口
• frameworks/base/core/jni/AndroidRuntime.cpp — ART 虚拟机启动
• frameworks/base/core/java/com/android/internal/os/ZygoteInit.java — Zygote Java 层
• frameworks/base/core/java/com/android/internal/os/ZygoteServer.java — Zygote Socket 管理
• frameworks/base/services/java/com/android/server/SystemServer.java — SystemServer
• frameworks/base/services/core/java/com/android/server/SystemServiceManager.java — 服务生命周期管理
• frameworks/base/services/core/java/com/android/server/SystemService.java — Boot Phase 定义