SystemServer分析

1 SystemServer分析

SystemServer的进程名就是前面所说的“system_server”，是zygote进程“app_process”fork出来的第一个子嗣，其重要性不言而喻。下面我们简称其为SS。

1.1 SS的诞生

先回顾一下SS是如何创建的：

/*在zygoteinit.java的startsystemserver方法中*/

String args[] = {

"--setuid=1000",

"--setgid=1000", "--setgroups=1001,1002,1003,1004,1005,1006,1007,1008,1009,1010,1018,1032,3001,3002,3003,3006,3007",

"--capabilities=" + capabilities + "," + capabilities,

"--runtime-init",

"--nice-name=system_server",

"com.android.server.SystemServer",

};

ZygoteConnection.Arguments parsedArgs = null;

int pid;

try {

parsedArgs = new ZygoteConnection.Arguments(args);

ZygoteConnection.applyDebuggerSystemProperty(parsedArgs);

ZygoteConnection.applyInvokeWithSystemProperty(parsedArgs);

/* Request to fork the system server process */

pid = Zygote.forkSystemServer( //调用此函数创建SS！

parsedArgs.uid, parsedArgs.gid,

parsedArgs.gids,

parsedArgs.debugFlags,

null,

parsedArgs.permittedCapabilities,

parsedArgs.effectiveCapabilities);

} catch (IllegalArgumentException ex) {

throw new RuntimeException(ex);

}

下面看看forkSystemServer函数的具体内容：

/*在Dalvik_dalvik_system_Zygote.cpp中)*/

* native public static int nativeForkSystemServer(int uid, int gid,

* int[] gids, int debugFlags, int[][] rlimits,

* long permittedCapabilities, long effectiveCapabilities);

static void Dalvik_dalvik_system_Zygote_forkSystemServer(

const u4* args, JValue* pResult)

{

pid_t pid;

/*根据参数fork一个子进程SS，并返回子进程的PID*/

pid = forkAndSpecializeCommon(args, true, true);

/* The zygote process checks whether the child process has died or not. */

if (pid > 0) {

int status;

ALOGI("System server process %d has been created", pid);

gDvm.systemServerPid = pid; //保存SS的PID

/* There is a slight window that the system server process has crashed

* but it went unnoticed because we haven't published its pid yet. So

* we recheck here just to make sure that all is well.

/*函数退出前需要先检查创建的子进程SS是否退出了*/

if (waitpid(pid, &status, WNOHANG) == pid) {

//如果SS退出了，那么zygote就自杀~

ALOGE("System server process %d has died. Restarting Zygote!", pid);

kill(getpid(), SIGKILL);

}

RETURN_INT(pid);

}

下面在看看forkAndSpecializeCommon函数主要完成两个工作：1，根据传入的参数对子进程做一些处理，如设置进程名，各种id等；2，就是调用很重要的信号处理函数setSignalHandler()。

该函数代码如下：

static void setSignalHandler()

{

int err;

struct sigaction sa;

memset(&sa, 0, sizeof(sa));

sa.sa_handler = sigchldHandler; //关联信号处理函数

err = sigaction (SIGCHLD, &sa, NULL); //设置信号处理函数，该信号是子进程死亡的信号

if (err < 0) {

ALOGW("Error setting SIGCHLD handler: %s", strerror(errno));

}

/*再看sigchldHandler函数，此函数由zygote在fork子进程之前调用！*/

static void sigchldHandler(int s)

{

pid_t pid;

int status;

while ((pid = waitpid(-1, &status, WNOHANG)) > 0) {

/* LOG死亡子进程的状态，以便调试*/

if (WIFEXITED(status)) {

if (WEXITSTATUS(status)) {

ALOG(LOG_DEBUG, ZYGOTE_LOG_TAG, "Process %d exited cleanly (%d)",

(int) pid, WEXITSTATUS(status));

} else {

IF_ALOGV(/*should use ZYGOTE_LOG_TAG*/) {

ALOG(LOG_VERBOSE, ZYGOTE_LOG_TAG,

"Process %d exited cleanly (%d)",

(int) pid, WEXITSTATUS(status));

}

} else if (WIFSIGNALED(status)) {

if (WTERMSIG(status) != SIGKILL) {

ALOG(LOG_DEBUG, ZYGOTE_LOG_TAG,

"Process %d terminated by signal (%d)",

(int) pid, WTERMSIG(status));

} else {

IF_ALOGV(/*should use ZYGOTE_LOG_TAG*/) {

ALOG(LOG_VERBOSE, ZYGOTE_LOG_TAG,

"Process %d terminated by signal (%d)",

(int) pid, WTERMSIG(status));

}

#ifdef WCOREDUMP

if (WCOREDUMP(status)) {

ALOG(LOG_INFO, ZYGOTE_LOG_TAG, "Process %d dumped core",

(int) pid);

}

#endif /* ifdef WCOREDUMP */

}

/*如果崩溃的子进程是SS，那么zygote就自杀，然后由init进程重新fork zygote进程，进而重启SS进程*/

if (pid == gDvm.systemServerPid) {

ALOG(LOG_INFO, ZYGOTE_LOG_TAG,

"Exit zygote because system server (%d) has terminated",

(int) pid);

kill(getpid(), SIGKILL);

}

if (pid < 0) {

ALOG(LOG_WARN, ZYGOTE_LOG_TAG,

"Zygote SIGCHLD error in waitpid: %s",strerror(errno));

}

从上面的分析可以看出SS同zygote进程同生共死，可见SS的重要性！下面开始分析SS在Android系统中到底扮演者什么样的角色。

1.2 SS的使命

SS进程诞生后，就同zygote进程分道扬镳了。它有了自己的使命，那么它的使命是什么呢？这需要我们会到zygotinit.java文件中的startSystemServer方法中：

try {

……

pid = Zygote.forkSystemServer(…);

} catch (IllegalArgumentException ex) {

throw new RuntimeException(ex);

}

/* For child process */

if (pid == 0) {

//这里就是SS的使命！

handleSystemServerProcess(parsedArgs);

}

/* handleSystemServerProcess 的详细代码如下*/

private static void handleSystemServerProcess(

ZygoteConnection.Arguments parsedArgs)

throws ZygoteInit.MethodAndArgsCaller {

closeServerSocket(); //首先关闭从zygote继承来的socket

//然后将umask值设为0077，这样的话新创建的文件和目录在默认情况下就//只有创建用户本身拥有读写权限了~

Libcore.os.umask(S_IRWXG | S_IRWXO);

if (parsedArgs.niceName != null) {

Process.setArgV0(parsedArgs.niceName); //有昵称就设置昵称

}

if (parsedArgs.invokeWith != null) {

WrapperInit.execApplication(parsedArgs.invokeWith,

parsedArgs.niceName, parsedArgs.targetSdkVersion,

null, parsedArgs.remainingArgs);

} else {

/*调用zygoteInit函数，并将主要的参数传递给SS*/

RuntimeInit.zygoteInit(parsedArgs.targetSdkVersion, parsedArgs.remainingArgs);

}

现在SS就进入到RuntimeInit类中了，zygoteInit的代码在RuntimeInit.java中，详细代码如下：

/**

* The main function called when started through the zygote process. This

* could be unified with main(), if the native code in nativeFinishInit()

* were rationalized with Zygote startup.<p>

* Current recognized args:

* <ul>

* <li> <code> [--] <start class name> <args>

* </ul>

* @param targetSdkVersion target SDK version

* @param argv arg strings

public static final void zygoteInit(int targetSdkVersion, String[] argv)

throws ZygoteInit.MethodAndArgsCaller {

if (DEBUG) Slog.d(TAG, "RuntimeInit: Starting application from zygote");

/*Redirect System.out and System.err to the Android log.分别对应log.info和log.warm*/

redirectLogStreams();

/*做一些常规初始化操作：很简单，可以看源代码中的注释*/

commonInit();

/*key1 native层的初始化*/

nativeZygoteInit();

/*key2 应用层的初始化，其实主要是通过调用invokeStaticMain函数来调用com.android.server.SystemServer类的main函数*/

applicationInit(targetSdkVersion, argv);

}

下面开始详细分析key1和key2。

1、nativeZygoteInit分析

nativeZygoteInit是一个native函数，它的实现在androidRuntime.cpp中

static void com_android_internal_os_RuntimeInit_nativeZygoteInit(JNIEnv* env, jobject clazz)

{

gCurRuntime->onZygoteInit();

}

gCurRuntime 是什么呢？回顾app_process(zygote)的main函数中有：

AppRuntime runtime;

AppRuntime类的定义：

class AppRuntime : public AndroidRuntime // AppRuntime继承于AndroidRuntime

而gCurRuntime定义如下：

static AndroidRuntime* gCurRuntime = NULL;

//说明 gCurRuntime是一个AndroidRuntime类对象

AndroidRuntime的构造函数如下：

AndroidRuntime::AndroidRuntime() :

mExitWithoutCleanup(false)

{

//图形相关的初始化，skia库初始化。

SkGraphics::Init();

SkImageDecoder::SetDeviceConfig(SkBitmap::kRGB_565_Config);

SkImageRef_GlobalPool::SetRAMBudget(512 * 1024);

mOptions.setCapacity(20);

assert(gCurRuntime == NULL);

gCurRuntime = this; // gCurRuntime被设置为AndroidRuntime对象自己！

}

由于SS是从zygote fork出来的，所以它也拥有zygote进程中定义的这个gCurRuntime对象，那么onZygoteInit有什么作用呢？它的代码在App_main.cpp中：

virtual void onZygoteInit()

{

atrace_set_tracing_enabled(true);

//这个函数与binder有关，暂时不细究~

sp<ProcessState> proc = ProcessState::self();

ALOGV("App process: starting thread pool.\n");

proc->startThreadPool(); //启动一个线程，用于Binder通信。

}

一言以蔽之，SS调用nativeZygoteInit后，将于Binder通信系统建立联系，这样SS就能够使用binder了。关于Binder的知识，将在后面详细介绍，这里不过多关注。

2、applicationInit分析

applicationInit主要是完成SS的应用层(java层)的初始化工作，该函数的核心功能在invokeStaticMain函数中：

private static void invokeStaticMain(String className, String[] argv)

throws ZygoteInit.MethodAndArgsCaller {

//传递进来的参数className = “com.android.server.SystemServer”

Class<?> cl;

try {

cl = Class.forName(className);

} catch (ClassNotFoundException ex) {

throw new RuntimeException(

"Missing class when invoking static main " + className,

ex);

}

Method m;

try {

m = cl.getMethod("main", new Class[] { String[].class });

} catch (NoSuchMethodException ex) {

throw new RuntimeException(

"Missing static main on " + className, ex);

} catch (SecurityException ex) {

throw new RuntimeException(

"Problem getting static main on " + className, ex);

}

int modifiers = m.getModifiers();

if (! (Modifier.isStatic(modifiers) && Modifier.isPublic(modifiers))) {

throw new RuntimeException(

"Main method is not public and static on " + className);

}

* This throw gets caught in ZygoteInit.main(), which responds

* by invoking the exception's run() method. This arrangement

* clears up all the stack frames that were required in setting

* up the process.

/*重点来了！！！这里竟然抛出了一个异常！从源代码的注释可以知道，这个异常被ZygoteInit.main()截获(注意:我们此时是在SS进程中)，然后调用该异常的run函数。

throw new ZygoteInit.MethodAndArgsCaller(m, argv);

}

/*回到zygoteinit.java的main函数看一下这个run 函数的功能*/

public void run() {

try {

/*这个mMethod是com.android.server.SystemServer的main函数*/

mMethod.invoke(null, new Object[] { mArgs });

} catch (IllegalAccessException ex) {

……

}

可以看出，invokeStaticMain抛出异常后会导致zygote进程调用com.android.server.SystemServer的main函数。那么为什么不直接在invokeStaticMain里面调用，转而使用这种方法呢？这个涉及到堆栈调用相关的只是，笔者还没弄明白，暂时搁置~

3、SS的真面目

Zygoteinit分裂产生的SS其实就是为了调用com.android.server.SystemServer的main函数！那么我们来看一看这个main函数到底做了什么：

public static void main(String[] args) {

……..

// Mmmmmm... more memory!这尼玛是在搞笑？

dalvik.system.VMRuntime.getRuntime().clearGrowthLimit();

……

//加载libandroid_servers.so库

System.loadLibrary("android_servers");

Slog.i(TAG, "Entered the Android system server!");

// 调用native函数，初始化native服务，其实就完成一个功能：

判断服务是否为sensor服务，如果是，就启动之。

nativeInit();

// This used to be its own separate thread, but now it is

// just the loop we run on the main thread.

ServerThread thr = new ServerThread(); //创建一个服务线程

thr.initAndLoop(); //重点在这个函数！

}

initAndLoop函数完成了SS真正的功能：启动系统各项重要的服务，然后此线程进行消息循环，接收和处理消息。

1.3 对SS的总结

SS的启动流程：

Zygoteinit调用startSystemServer创建System_server进程；SS调用hanleSystemServerProcess完成自己的使命；hanleSystemServerProcess抛出异常MethodAndArgsCaller，最终调用com.android.server.SystemServer的main函数；main函数创建一个ServerThread线程，再调用这个线程的initAndLoop函数；在这个initAndLoop函数中，启动系统各项重要的服务，并将该线程加入到Binder通信系统中，进行消息循环。