SystemServer

序言

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

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

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

SystemServer发动的流程都阅历了什么
AMS是在哪里发动的，它的功用是什么
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的这个线程中进行处理。

问题

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

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

最终

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

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

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

AMS的起源，SystemServer的前世今生

SystemServer

序言

宿世

1. 梦回Zygote进程

2. 两条不同的路

3. 条件假定

4. Zygote进程

5. 割裂出的子进程

此生

1. 预备Looper

2. 创立上下文啦

3. SystemServiceManager

4. startBootstrapServices

5. startCoreServices

6. startOtherServices

7. Looper.loop

问题

最终

图解

作者信息

AMS的起源，SystemServer的前世今生

SystemServer

序言

宿世

1. 梦回Zygote进程

2. 两条不同的路

3. 条件假定

4. Zygote进程

5. 割裂出的子进程

此生

1. 预备Looper

2. 创立上下文啦

3. SystemServiceManager

4. startBootstrapServices

5. startCoreServices

6. startOtherServices

7. Looper.loop

问题

最终

图解

相关文章

浅谈 Spring 如何解决 Bean 的循环依赖问题

用户行为分析模型实践（三）——H5通用分析模型

Openstack之log详解

AB实验统计学基础：假设检验和最小样本量

作者信息