4、系统上下文创建：SystemServer的进程环境、SystemContext的构建过程

好，我们继续往下走。上一章聊完了SystemServer的主线程启动，这一章咱们聚焦一个关键环节——系统上下文创建。

说白了，就是给SystemServer搭好一个能跑起来的“舞台”。这个舞台包括进程环境、资源路径、还有那个无处不在的SystemContext。你想想看，SystemServer要管理那么多系统服务，它自己得先有个稳定的“家”才行。

4.1 进程环境初始化：SystemServer的“出生证明”

SystemServer启动后，第一件事不是急着创建服务，而是先把自己“收拾干净”。

我记得在Android 8.0之前，这块代码还比较简单。后来随着Treble架构的引入，进程环境初始化变得复杂了不少。我个人习惯把这一步叫做“系统服务的出生证明”——它决定了SystemServer以什么身份、什么权限、什么资源来运行。

核心工作有这么几项：

• 设置进程名称：通过Process.setArgV0("system_server")，让ps命令能看到它。
• 设置时区与语言：从系统属性中读取，确保后续服务使用正确的本地化配置。
• 初始化Binder线程池：SystemServer本身就是一个Binder服务端，需要提前准备好线程池。
• 加载JNI库：比如android_servers这个so库，里面封装了大量底层调用。

4.2 SystemContext的构建：一个“万能”的Context

接下来就是重头戏——SystemContext的创建。这个对象在Android源码里叫mSystemContext，它是整个SystemServer的“根Context”。

你可能会问：为什么不用普通的ContextImpl？

嗯，原因很简单。SystemServer不是普通的App进程，它没有Activity、没有Application。但它又需要访问资源、查询包信息、获取系统服务。所以Google专门为它设计了一个SystemContext，本质上是一个ContextImpl的变体，但做了特殊处理。

构建过程大致如下：

// 源码位置：frameworks/base/services/java/com/android/server/SystemServer.java
private void createSystemContext() {
    // 1. 创建ActivityThread实例
    ActivityThread activityThread = ActivityThread.systemMain();
    
    // 2. 通过ActivityThread创建Context
    mSystemContext = activityThread.getSystemContext();
    
    // 3. 设置主题
    mSystemContext.setTheme(android.R.style.Theme_DeviceDefault_Light_DarkActionBar);
    
    // 4. 创建SystemServiceManager
    mSystemServiceManager = new SystemServiceManager(mSystemContext);
}

这段代码看着简单，但背后做了不少事。我拆开来讲：

4.3 ActivityThread.systemMain()：一个特殊的入口

ActivityThread.systemMain()是SystemServer独有的调用路径。普通App启动时走的是main()方法，而SystemServer走的是systemMain()。

区别在哪？

对比项	普通App	SystemServer
入口方法	ActivityThread.main()	ActivityThread.systemMain()
Context类型	ContextImpl	SystemContext
包名	应用包名	android
权限	应用权限	系统权限（SYSTEM_UID）

我个人习惯把systemMain()理解为“系统级单例”。它只被调用一次，创建出来的ActivityThread实例会一直存活到系统关机。

4.4 SystemContext的内部结构：它到底特殊在哪？

我们来看看SystemContext的源码。它其实是一个内部类，定义在ContextImpl.java里：

// 源码位置：frameworks/base/core/java/android/app/ContextImpl.java
static class SystemContext extends ContextImpl {
    @Override
    public String getPackageName() {
        return "android";
    }
    
    @Override
    public String getBasePackageName() {
        return "android";
    }
    
    @Override
    public File getCacheDir() {
        return new File("/cache");
    }
    
    // 其他方法...
}

看到了吗？它的getPackageName()返回的是"android"，而不是某个具体App的包名。这意味着SystemServer可以访问framework-res.apk里的所有资源。

我曾经在项目中遇到过一个问题：某个系统服务需要读取一个自定义资源，但一直报Resources.NotFoundException。排查了半天，发现是Context传错了——传了一个普通App的Context进去，自然找不到系统资源。

4.5 资源与主题的初始化

SystemContext创建完成后，紧接着就是设置主题。这一步看似简单，但影响深远。

为什么？因为SystemServer里很多服务会弹对话框、显示通知、或者绘制界面。如果没有一个合适的主题，这些UI元素会变得很难看，甚至在某些设备上出现兼容性问题。

我记得在Android 5.0刚推出Material Design时，Google就踩过这个坑。早期版本里SystemServer用的还是Holo主题，结果系统UI和第三方App的Material风格格格不入。后来才统一改成了Theme_DeviceDefault系列。

代码里是这样设置的：

mSystemContext.setTheme(android.R.style.Theme_DeviceDefault_Light_DarkActionBar);

这个主题是“亮色背景+深色ActionBar”，适合大多数设备。当然，厂商可以自定义，但一般不会动这个。

4.6 SystemServiceManager的诞生

最后一步，就是创建SystemServiceManager。这个类我后面会专门讲，这里先提一句：它是所有系统服务的“管家”。

创建代码很简单：

mSystemServiceManager = new SystemServiceManager(mSystemContext);

但它的作用可不小。它负责服务的注册、启动、生命周期管理，甚至包括服务的线程模型。可以说，没有SystemServiceManager，SystemServer就是一盘散沙。

4.7 避坑指南：我踩过的几个坑

讲了这么多理论，最后分享几个实战中容易踩的坑：

• 坑一：Context泄露。SystemContext是全局单例，千万别在服务里持有它的短生命周期引用。我曾经见过一个服务把SystemContext传给了匿名内部类，结果导致整个SystemServer无法GC。
• 坑二：资源ID冲突。因为SystemContext的包名是"android"，所以它只能访问framework-res.apk里的资源。如果你想用第三方库的资源，得自己处理包名映射。
• 坑三：线程模型。SystemContext本身不是线程安全的。如果你在多个线程里同时调用getSystemService()，可能会出现竞态条件。我建议在服务启动阶段就做好缓存。

嗯，这一章的内容就到这里。系统上下文的创建看似简单，但它是整个SystemServer的根基。下一章我们会深入SystemServiceManager，看看它到底是怎么管理那些成百上千的系统服务的。