SystemServer

序言

这么快，咱们就来到了本系列的第三章了。上一章，其实埋了个小坑。便是Zygote怎么创立的SystemServer。所以这一章，就要详细讲一下SystemServer了。

敞开文章之前，希望各位能给点个赞，加个重视，你们的支撑便是我最大的动力。

仍是老规矩，提出几个问题，文章最终再试着自己答复一下。加深下印象。

1. SystemServer发动的流程都阅历了什么
2. AMS是在哪里发动的，它的功用是什么
3. SystemServer是Zygote割裂出来的，为什么功用却彻底不同

---

时间回溯到看上一篇Zygote文章的时分。最终一段写forkSystemServer的时分，其实有些太草率了。只说了会创立可是没说咋建的，也没办法，总之是希望文章，不要太长，不然咱们看了就累了（现实是没啥人看）。本着做了就得负责的主意，把之前的坑，留到了这儿。

多说一嘴哈，这章估计会有许多的代码量，我仍是尽量捡里边最最要害的点。其余的一些或许重要可是不要害的点 ，就有或许会被疏忽了，不然文章就太长了，咱们看不下去，反而不如简单一点。

---

宿世

SystemServer的创立还得追溯到之前的Zygote进程中的ZygoteInit代码中。这儿的Zygote.forkSystemServer()办法便是完成割裂的要害代码。它内部调用了native办法完成了进程割裂。

履行完这行代码之后。咱们的体系中就会呈现两个一模一样的进程，只不过进程id不一样。这两个进程都会持续履行之后的代码。一个是Zygote进程，一个是割裂出来的子进程（此刻还没给该进程命名SystemServer）。

1. 梦回Zygote进程

这儿精简了一下ZygoteInit的代码，只留了几个重要的办法。而且重要代码都加了注释，不必深究代码内部做了什么。这样能够更加便利了解。让咱们先看下代码，再接着往后看。

  class ZygoteInit {
      public static void main(String argv[]) {
           // ...代码疏忽...
           // 此处的startSystemServer为true
          if (startSystemServer) {
              // 调用forkSystemServer办法
              Runnable r = forkSystemServer();
              if (r != null) {
                  r.run();
                  return;
              }
          }
          // runselectloop内部是一个while(true)的循环，
          // 只有在退出while循环时，会return一个runnable
          // 一旦履行完结，意味着zygote进程一切代码履行完结。
          Runnable caller = zygoteServer.runSelectLoop(abiList);
          if (caller != null) {
              caller.run();
          }
      }
      private static Runnable forkSystemServer() {
          // 内部经过native办法割裂进程，
          // 割裂之后，一个zygote进程，一个子进程。
          int pid = Zygote.forkSystemServer();
          // 这儿之后的代码，Zygote进程和割裂出的子进程都会持续履行
          if (pid == 0) {
              // 子进程关闭socket
              zygoteServer.closeServerSocket(); 
              // 这儿给进程命名，并发动Systemserver.java
              return handleSystemServerProcess(parsedArgs);
          }
           // Zygote进程，履行完forkSystemServer办法会回来null
           return null;
      }
      private static Runnable handleSystemServerProcess(ZygoteArguments parsedArgs) 
         // niceName是进程姓名，即SystemServer。
         // 在这儿把这个割裂出来的进程，从头命名为SystemServer
        if (parsedArgs.mNiceName != null) {
            Process.setArgV0(parsedArgs.mNiceName);
        }
       // ...代码疏忽...
       // 此处调用native办法敞开Binder线程池
       // 这儿经过SystemServer的全类名，用反射的办法，发动SystemServer的main办法
       return ZygoteInit.zygoteInit(parsedArgs.mTargetSdkVersion,
                  parsedArgs.mDisabledCompatChanges,
                  parsedArgs.mRemainingArgs, cl);
      }
  }

咱们在main办法里调用了forkSystemServer办法。forkSystemServer办法中经过 int pid = Zygote.forkSystemServer(); 割裂了一个进程出来，并回来割裂出的进程的pid值。这儿割裂进程是调用的native办法，即底层的c++代码。所以这儿一笔带过。有兴趣的同学能够进源码中检查。

此刻已经有了两个进程。一个Zygote进程，一个割裂出来的子进程。而且两个进程都会持续履行未履行完的代码。

2. 两条不同的路

咱们再将目光转回到 int pid = Zygote.forkSystemServer();，这句代码能够了解为，割裂进程并回来子进程的pid。

进程在割裂后，都会回来一个pid的值，且持续履行。只不过Zygote进程回来的是子进程的pid，而 子进程因为它是被割裂出来的进程，所以Zygote.forkSystemServer();办法回来的是0。从这儿开端两个进程的命运就开端走向了两条不同的路途。

3. 条件假定

这儿为了便利了解，咱们做个假定，假定Zygote的进程id为1000，割裂出的子进程id为2000。

4. Zygote进程

假定在Zygote进程中，回来的pid的值是割裂出的子进程的2000。

咱们在看回上面ZygoteInit代码中，因为Zygote进程回来的pid的值对错0的数，所以forkSystemServer() 这个办法对于Zygote进程来说回来的是null，再看ZygoteInit的代码可知，Zygote进程将会履行zygoteServer.runSelectLoop(abiList) 这行代码。

即在割裂进程后，将会进入循环等候。不太清楚的同学，能够看下之前关于zygote的我就问Zygote进程，你究竟都干了啥这篇文章。

5. 割裂出的子进程

而在子进程中，因为 int pid = Zygote.forkSystemServer(); 回来的pid是0，所以会履行if (pid == 0) 这个代码块里的handleSystemServerProcess(parsedArgs) 办法。

这个办法里会给割裂出来的进程从头命名为SystemServer，而且会经过反射履行SystemServer.java中的main办法。

至此，SystemServer就正式和Zygote别离开了。

---

此生

上面说到，割裂出的子进程会履行SystemServer的main办法。所以为了便利了解，先上一个SystemServer大致的功用图。同时后边加上SystemServer精简过的代码。以便利咱们加深回忆。从图中可知SystemServer大概做了7件事。不过，预备Looper和Looper.loop()也能够看做一件事。

public final class SystemServer {
    /**
     * The main entry point from zygote.
     */
    public static void main(String[] args) {
        new SystemServer().run();
    }
    private void run() {
            // 1. Prepare the main looper thread (this thread).
            android.os.Process.setThreadPriority(
                    android.os.Process.THREAD_PRIORITY_FOREGROUND);
            Looper.prepareMainLooper();
            // Initialize native services.
            System.loadLibrary("android_servers");
            // 2. Initialize the system context.
            createSystemContext();
            // 3. Create the system service manager.
            mSystemServiceManager = new SystemServiceManager(mSystemContext);
            // Start services.
            // 4. 发动引导类服务
            startBootstrapServices(t); 
            // 5. 发动中心类服务
            startCoreServices(t); 
            // 6. 发动其他类服务
            startOtherServices(t); 
            // 7. Loop forever.
            Looper.loop();
        throw new RuntimeException("Main thread loop unexpectedly exited");
    }
}

1. 预备Looper

这儿做的榜首件事，便是给当前的线程设置了优先级。紧接着便是咱们特别了解的一句代码Looper.prepareMainLooper();

了解Handler的童鞋看到这个必定特别亲热。这便是为什么在主线程中能够直接运用Handler的原因，这个的话涉及Handler和Looper的联系，这儿不做过多的赘述，感兴趣的同学能够上网搜一下，或许让我出一篇这个的文章。不过网上已经有太多的人写这个了。 后边的ActivityThread类的main办法中会呈现这个办法。咱们能够找一下这个办法。

这儿的Looper.prepareMainLooper(); 和后边的 Looper.loop(); 是相对应的。

2. 创立上下文啦

这儿会初始化体系类上下文，而且会呈现咱们很了解的一个类ActivityThread。调用它的systemMain() 办法。

public final class SystemServer {
    // 省掉其他代码
    private void createSystemContext() {
        ActivityThread activityThread = ActivityThread.systemMain();
        mSystemContext = activityThread.getSystemContext();
        final Context systemUiContext = activityThread.getSystemUiContext();
    }
}

下面有ActivityThread的相关代码。systemMain办法中创立了ActivityThread目标，而且履行了attach办法。因为这儿的参数system是true，所以履行的是else里的代码块。

attach办法里，创立了context上下文，同时经过Instrumentation创立了application。为了控制文章长度，就不在这儿贴相关代码了。

public final class ActivityThread{
    public static void main(String[] args) {
        // 预备looper
        Looper.prepareMainLooper();
        // 主线程进入循环等候
        Looper.loop();
        throw new RuntimeException("Main thread loop unexpectedly exited");
    }
    @UnsupportedAppUsage
    public static ActivityThread systemMain() {
        ActivityThread thread = new ActivityThread();
        thread.attach(true, 0);
        return thread;
    }
    Application mInitialApplication;
    private void attach(boolean system, long startSeq) {
        if (!system) {
            // 内容很重要，涉及App发动，可是此处用不到所以省掉.......
        } else {
            mInstrumentation = new Instrumentation();
            mInstrumentation.basicInit(this);
            // 创立上下文，context持有该ActivityThread目标
            ContextImpl context = ContextImpl.createAppContext(this, getSystemContext().mPackageInfo);
            // mPackageInfo是LoadedApk，LoadedApk内部含有Instrumentation，
            // 经过Instrumentation的 newApplication办法创立了Application。
            mInitialApplication = context.mPackageInfo.makeApplication(true, null);
            mInitialApplication.onCreate();
        }
    }
}

ContextImpl是Context的具体完成类。同时创立了LoadedApk目标。LoadedApk记载了当前要加载的apk的相关信息，例如PackageName，LibDir，ResDir等。

/**
 * Common implementation of Context API, which provides the base
 * context object for Activity and other application components.
 */
class ContextImpl extends Context {
    @UnsupportedAppUsage
    static ContextImpl createSystemContext(ActivityThread mainThread) {
        LoadedApk packageInfo = new LoadedApk(mainThread);
        ContextImpl context = new ContextImpl(null, mainThread, packageInfo, null, null, null, null,
                0, null, null);
        return context;
    }
}

---

3. SystemServiceManager

SystemServiceManager官方的注释解说是，管理SystemService的创立、开端以及其他生命周期事件。经过反射的办法，调用SystemService以及其子类的start办法。后边的startCoreServices办法里有相关代码。

/**
 * Manages creating, starting, and other lifecycle events of system services
 * {@link com.android.server.SystemService system services}.
 *
 * {@hide}
 */
public class SystemServiceManager {
    /**
     * Starts a service by class name.
     */
    public SystemService startService(String className) {
        final Class<SystemService> serviceClass = loadClassFromLoader(className,
                this.getClass().getClassLoader());
        return startService(serviceClass);
    }
    /**
     * Creates and starts a system service. The class must be a subclass of
     * {@link com.android.server.SystemService}.
     */
    public <T extends SystemService> T startService(Class<T> serviceClass) {
            // Create the service.
            Constructor<T> constructor = serviceClass.getConstructor(Context.class);
            final T service = constructor.newInstance(mContext);
            startService(service);
            return service;
    }
    public void startService(@NonNull final SystemService service) {
        // Register it.
        mServices.add(service);
        // Start it.
        service.onStart();
    }
}

---

4. startBootstrapServices

敞开体系服务，这儿有许多许多的Service被发动。其中最要害的几个Service便是ActivityManagerService，简称AMS。别的一个是ActivityTaskManagerService，简称ATMS 。还有PackageManagerService ，即PMS。

其实AMS 和ATMS 他们两个其实是有些渊源的。最开端四大组件的发动服务都在ActivityManagerService中，不过等到了Android10.0之后，或许是研发人员觉得AMS的工作量太大了，所以给他找了个小弟ATMS，将activity的相关工作放到了ActivityTaskManagerService中。不过AMS还会持有ATMS引用，这波属实是让AMS从一个底层员工变成了一个带新人的老员工。

private void startBootstrapServices(@NonNull TimingsTraceAndSlog t) {
     mPackageManagerService = PackageManagerService.main(mSystemContext, installer,
                    mFactoryTestMode != FactoryTest.FACTORY_TEST_OFF, mOnlyCore);
    // Activity manager runs the show.
    ActivityTaskManagerService atm = mSystemServiceManager.startService(
            ActivityTaskManagerService.Lifecycle.class).getService();
    mActivityManagerService = ActivityManagerService.Lifecycle.startService(
            mSystemServiceManager, atm);
    mActivityManagerService.setSystemServiceManager(mSystemServiceManager);
    //省掉许多代码...
}

startBootstrapServices这儿创立了许多service，其中最引人注意的是PMS，AMS以及ATMS。

---

5. startCoreServices

中心服务这儿的话，没有太多可说的。假如各位有感兴趣的能够直接看代码中的英文注释自行了解。我就不多做加工了，或许原汁原味比我加工过的更好了解。

不过从这儿经过SystemServeiceManager的start办法，发动了许多SystemService的子类。

/**
 * Starts some essential services that are not tangled up in the bootstrap process.
 */
private void startCoreServices(@NonNull TimingsTraceAndSlog t) {
    // Service for system config
    mSystemServiceManager.startService(SystemConfigService.class);
    // Tracks the battery level.  Requires LightService.
    mSystemServiceManager.startService(BatteryService.class);
    // Tracks application usage stats.
    mSystemServiceManager.startService(UsageStatsService.class);
    mActivityManagerService.setUsageStatsManager(
            LocalServices.getService(UsageStatsManagerInternal.class));
    // Tracks whether the updatable WebView is in a ready state and watches for update installs.
    if (mPackageManager.hasSystemFeature(PackageManager.FEATURE_WEBVIEW)) {
        mWebViewUpdateService = mSystemServiceManager.startService(WebViewUpdateService.class);
    }
    // Tracks and caches the device state.
    mSystemServiceManager.startService(CachedDeviceStateService.class);
    // Tracks cpu time spent in binder calls
    mSystemServiceManager.startService(BinderCallsStatsService.LifeCycle.class);
    // Tracks time spent in handling messages in handlers.
    mSystemServiceManager.startService(LooperStatsService.Lifecycle.class);
    // Manages apk rollbacks.
    mSystemServiceManager.startService(ROLLBACK_MANAGER_SERVICE_CLASS);
    // Service to capture bugreports.
    mSystemServiceManager.startService(BugreportManagerService.class);
    // Serivce for GPU and GPU driver.
    mSystemServiceManager.startService(GpuService.class);
}

---

6. startOtherServices

他来了他来了，他带着Launcher走来了。这儿边创立了windowsManagerService，而且调用了AMS的systemReady办法发动了Launcher这个app。

这儿稍微挖个坑，发动Launcher的流程，留到AMS里边在进行解说，这儿只说结果。那便是startOtherServices里创立了Launcher。

private void startOtherServices(@NonNull TimingsTraceAndSlog t) {
    WindowManagerService wm = null;
    wm = WindowManagerService.main(context, inputManager, !mFirstBoot, mOnlyCore,
            new PhoneWindowManager(), mActivityManagerService.mActivityTaskManager);
    ServiceManager.addService(Context.WINDOW_SERVICE, wm, /* allowIsolated= */ false,
            DUMP_FLAG_PRIORITY_CRITICAL | DUMP_FLAG_PROTO);
}

---

7. Looper.loop

最终的最终，和咱们的最初相照应。咱们的SystemServer进程的主线程经过Looper.loop进入循环等候。一旦有handler传递音讯，就会在systemServer的这个线程中进行处理。

问题

1. SystemServer发动的流程都阅历了什么
2. AMS是在哪里发动的，它的功用是什么
3. SystemServer是Zygote割裂出来的，为什么功用却彻底不同

到这儿，再回头去看上面的几个问题，我想各位应该有自己的答案了吧。

最终

SystemServer到此就结束了，其实还有一些东西没有说，比方SystemManager怎么注册服务，比方AMS怎么发动Launcher。这些假如各位感兴趣的话，能够给我留言，我会再写相应的文章进行解说。

别的，只看文章真的只能是暂时记住。真的想加深回忆，需要自己走一遍源码流程。好回忆不如烂笔头，在走源码的时分，将重要的点进行记载，也是加深回忆的一种办法。

假如各位觉得本文写的还算将就，请咱们帮助点个赞加个重视，你们的点赞重视，便是我更新文章的最大动力。让咱们一起学习，一起前进，最终给各位一个图解，让咱们一起加油～

图解