
2.3 SystemServer处理过程
SystemServer进程主要用于创建系统服务,我们熟知的AMS、WMS和PMS都是由它来创建的,本书后面的章节会介绍AMS和WMS,因此掌握SystemServer进程是如何启动的,它在启动时做了哪些工作是十分必要的。
2.3.1 Zygote处理SystemServer进程
在2.2节中讲到了Zygote进程启动了SystemServer进程,本节来学习Zygote是如何处理SystemServer进程的,时序图如图2-2所示。

图2-2 Zygote处理SystemServer进程的时序图
在ZygoteInit.java的startSystemServer方法中启动了SystemServer进程,如下所示:


SystemServer 进程复制了Zygote进程的地址空间,因此也会得到Zygote进程创建的Socket,这个Socket对于SystemServer进程没有用处,因此,需要注释1处的代码来关闭该Socket,接着在注释2处调用handleSystemServerProcess方法来启动SystemServer进程。handleSystemServerProcess方法的代码如下所示:

在注释1处创建了PathClassLoader,关于PathClassLoader将在第12章进行介绍。在注释2处调用了ZygoteInit的zygoteInit方法,代码如下所示:


在注释1处调用nativeZygoteInit方法,一看方法的名称就知道调用的是Native层的代码,用来启动Binder线程池,这样SystemServer进程就可以使用Binder与其他进程进行通信了。注释2处是用于进入SystemServer的main方法,现在分别对注释1和注释2的内容进行介绍。
1.启动Binder线程池
nativeZygoteInit是一个Native方法,因此我们先要了解它对应的JNI文件,不了解JNI的可以查看第9章内容,如下所示:

通过JNI的gMethods数组,可以看出nativeZygoteInit方法对应的是JNI文件AndroidRuntime.cpp的com_android_internal_os_ZygoteInit_nativeZygoteInit函数:

这里gCurRuntime是AndroidRuntime类型的指针,具体指向的是AndroidRuntime的子类AppRuntime,它在app_main.cpp中定义,我们接着来查看AppRuntime的onZygoteInit方法,代码如下所示:

注释1处的代码用来启动一个Binder线程池,这样SystemServer进程就可以使用Binder与其他进程进行通信了。看到这里我们知道RuntimeInit.java的nativeZygoteInit函数主要是用来启动Binder线程池的。
2.进入SystemServer的main方法
我们再回到RuntimeInit.java的代码,在注释2处调用了RuntimeInit的applicationInit方法,代码如下所示:

在applicationInit方法中主要调用了invokeStaticMain方法:


注释1处的className为com.android.server.SystemServer,通过反射返回的cl为SystemServer类。在注释2处找到SystemServer中的main方法。在注释3处将找到的main方法传入MethodAndArgsCaller异常中并抛出该异常,捕获MethodAndArgsCaller异常的代码在ZygoteInit.java的main方法中,这个main方法会调用SystemServer的main方法。那么为什么不直接在invokeStaticMain方法中调用SystemServer的main方法呢?原因是这种抛出异常的处理会清除所有的设置过程需要的堆栈帧,并让SystemServer的main方法看起来像是SystemServer进程的入口方法。在Zygote启动了SystemServer进程后,SystemServer进程已经做了很多的准备工作,而这些工作都是在SystemServer的main方法调用之前做的,这使得SystemServer的main方法看起来不像是SystemServer进程的入口方法,而这种抛出异常交由ZygoteInit.java的main方法来处理,会让SystemServer的main方法看起来像是SystemServer进程的入口方法。
下面来查看在ZygoteInit.java的main方法中是如何捕获MethodAndArgsCaller异常的:


当捕获到MethodAndArgsCaller异常时就会在注释1处调用MethodAndArgsCaller的run方法,MethodAndArgsCaller是Zygote.java的静态内部类:

注释1处的mMethod指的就是SystemServer的main方法,调用了mMethod的invoke方法后,SystemServer的main方法就会被动态调用,SystemServer 进程就进入了SystemServer的main方法中。
2.3.2 解析SystemServer进程
下面来查看SystemServer的main方法:

main方法中只调用了SystemServer的run方法,如下所示:

在注释1处加载了动态库libandroid_servers.so。接下来在注释2处创建SystemServiceManager,它会对系统服务进行创建、启动和生命周期管理。在注释3处的startBootstrapServices方法中用SystemServiceManager启动了ActivityManagerService、PowerManagerService、PackageManagerService等服务。在注释4处的startCoreServices方法中则启动了DropBoxManagerService、BatteryService、UsageStatsService和WebViewUpdateService。在注释5处的startOtherServices 方法中启动了CameraService、AlarmManagerService、VrManagerService等服务。这些服务的父类均为SystemService。从注释3、4、5的方法中可以看出,官方把系统服务分为了三种类型,分别是引导服务、核心服务和其他服务,其中其他服务是一些非紧要和不需要立即启动的服务。这些系统服务总共有100多个,表2-1列出部分系统服务及其作用。
表2-1 部分系统服务及其作用

这些系统服务启动逻辑是相似的,这里以启动PowerManagerService来进行举例,代码如下所示:

SystemServiceManager的startService方法启动了PowerManagerService,startService方法如下所示:

在注释1处将PowerManagerService添加到mServices中,其中mServices是一个存储SystemService类型的ArrayList,这样就完成了PowerManagerService的注册工作。在注释2处调用PowerManagerService的onStart函数完成启动PowerManagerService。
除了用mSystemServiceManager的startService函数来启动系统服务外,也可以通过如下形式来启动系统服务,以PackageManagerService为例:

直接调用了PackageManagerService的main方法:


在注释1处直接创建PackageManagerService 并在注释2处将PackageManagerService注册到ServiceManager中,ServiceManager用来管理系统中的各种Service,用于系统C/S架构中的Binder通信机制:Client端要使用某个Service,则需要先到ServiceManager查询Service的相关信息,然后根据Service的相关信息与Service所在的Server进程建立通信通路,这样Client端就可以使用Service了。
2.3.3 SystemServer进程总结
SystemServer进程被创建后,主要做了如下工作:
(1)启动Binder线程池,这样就可以与其他进程进行通信。
(2)创建SystemServiceManager,其用于对系统的服务进行创建、启动和生命周期管理。
(3)启动各种系统服务。