1 SystemServer分析
SystemServer的进程名就是前面所说的“system_server”，是zygote进程“app_process”fork出来的第一个子嗣，其重要性不言而喻。下面我们简称其为SS。
1.1 SS的诞生
先回顾一下SS是如何创建的：
|
/*在zygoteinit.java的startsystemserver方法中*/ String args[] = { "--setuid=1000", "--setgid=1000", "--capabilities=" + capabilities + "," + capabilities, "--runtime-init", "--nice-name=system_server", "com.android.server.SystemServer", }; ZygoteConnection.Arguments int pid; try { parsedArgs = new ZygoteConnection.Arguments(args); ZygoteConnection.applyDebuggerSystemProperty(parsedArgs); ZygoteConnection.applyInvokeWithSystemProperty(parsedArgs); /* pid parsedArgs.uid, parsedArgs.gid, parsedArgs.gids, parsedArgs.debugFlags, null, parsedArgs.permittedCapabilities, parsedArgs.effectiveCapabilities); } catch throw new RuntimeException(ex); } |
下面看看forkSystemServer函数的具体内容 ：
|
/*在Dalvik_dalvik_system_Zygote.cpp中)*/ /* * native public static int nativeForkSystemServer(int uid, int * int[] gids, int debugFlags, int[][] * long permittedCapabilities, long */ static void Dalvik_dalvik_system_Zygote_forkSystemServer( const u4* args, JValue* { pid_t pid; /*根据参数fork一个子进程SS，并返回子进程的PID*/ pid = forkAndSpecializeCommon(args, true, true); /* The zygote process checks whether the child if (pid > 0) { int status; ALOGI("System server process gDvm.systemServerPid = pid; /* There is a slight window * but it went * we recheck here just */ /*函数退出前需要先检查创建的子进程SS是否退出了*/ if (waitpid(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 } } /*再看sigchldHandler函数，此函数由zygote在fork子进程之前调用！*/ static void sigchldHandler(int s) { pid_t pid; int status; while ((pid = waitpid(-1, &status, WNOHANG)) /* LOG死亡子进程的状态，以便调试*/ if (WIFEXITED(status)) { if ALOG(LOG_DEBUG, ZYGOTE_LOG_TAG, "Process %d exited cleanly (%d)", (int) pid, WEXITSTATUS(status)); } IF_ALOGV(/*should use ZYGOTE_LOG_TAG*/) { ALOG(LOG_VERBOSE, ZYGOTE_LOG_TAG, "Process %d exited cleanly (int) pid, WEXITSTATUS(status)); } } } else if if ALOG(LOG_DEBUG, ZYGOTE_LOG_TAG, "Process %d terminated by signal (%d)", (int) pid, WTERMSIG(status)); } 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 ALOG(LOG_INFO, ZYGOTE_LOG_TAG, "Process %d dumped core", (int) pid); } #endif /* ifdef WCOREDUMP */ } /*如果崩溃的子进程是SS，那么zygote就自杀，然后由init进程重新fork zygote进程，进而重启SS进程*/ if (pid == 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 SIGCHLD error in waitpid: %s",strerror(errno)); } } |
从上面的分析可以看出SS同zygote进程同生共死，可见SS的重要性！下面开始分析SS在Android系统中到底扮演者什么样的角色。
1.2 SS的使命
SS进程诞生后，就同zygote进程分道扬镳了。它有了自己的使命，那么它的使命是什么呢？这需要我们会到zygotinit.java文件中的startSystemServer方法中：
|
try { …… pid } catch 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(); //然后将umask值设为0077，这样的话新创建的文件和目录在默认情况下就//只有创建用户本身拥有读写权限了~ Libcore.os.umask(S_IRWXG | if (parsedArgs.niceName != Process.setArgV0(parsedArgs.niceName); //有昵称就设置昵称 } if (parsedArgs.invokeWith != WrapperInit.execApplication(parsedArgs.invokeWith, parsedArgs.niceName, parsedArgs.targetSdkVersion, null, parsedArgs.remainingArgs); } else { /*调用zygoteInit函数，并将主要的参数传递给SS*/ RuntimeInit.zygoteInit(parsedArgs.targetSdkVersion, } } |
现在SS就进入到RuntimeInit类中了，zygoteInit的代码在RuntimeInit.java中，详细代码如下：
|
/** * The main function called when started * could be unified with main(), if the native * were rationalized with Zygote * * Current recognized args: * <ul> * <li> <code> [--] * </ul> * * @param targetSdkVersion target SDK * @param argv arg strings */ public static final void zygoteInit(int throws if (DEBUG) Slog.d(TAG, /*Redirect System.out and System.err to the Android redirectLogStreams(); /*做一些常规初始化操作：很简单，可以看源代码中的注释*/ commonInit(); /*key1 native层的初始化*/ nativeZygoteInit(); /*key2 applicationInit(targetSdkVersion, argv); } |
下面开始详细分析key1和key2。
1、nativeZygoteInit分析
nativeZygoteInit是一个native函数，它的实现在androidRuntime.cpp中
|
static void { gCurRuntime->onZygoteInit(); } gCurRuntime 是什么呢？回顾app_process(zygote)的main函数中有： AppRuntime runtime; AppRuntime类的定义： class AppRuntime : public 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 == gCurRuntime = this; // } |
由于SS是从zygote
fork出来的，所以它也拥有zygote进程中定义的这个gCurRuntime对象，那么onZygoteInit有什么作用呢？它的代码在App_main.cpp中：
|
virtual void onZygoteInit() { atrace_set_tracing_enabled(true); //这个函数与binder有关，暂时不细究~ sp<ProcessState> proc ALOGV("App process: starting proc->startThreadPool(); } |
一言以蔽之，SS调用nativeZygoteInit后，将于Binder通信系统建立联系，这样SS就能够使用binder了。关于Binder的知识，将在后面详细介绍，这里不过多关注。
2、applicationInit分析
applicationInit主要是完成SS的应用层(java层)的初始化工作，该函数的核心功能在invokeStaticMain函数中：
|
private static void invokeStaticMain(String throws ZygoteInit.MethodAndArgsCaller { //传递进来的参数className = “com.android.server.SystemServer” Class<?> cl; try { cl = } catch throw new RuntimeException( "Missing class when invoking static main " + className, ex); } Method m; try { m = } catch throw new RuntimeException( "Missing static main on " + className, ex); } catch (SecurityException throw new RuntimeException( "Problem getting static main on " + className, ex); } int modifiers = if (! throw new RuntimeException( "Main method is not public and static on " + className); } /* * This throw gets * by invoking the * clears up all the * up the process. */ /*重点来了！！！这里竟然抛出了一个异常！从源代码的注释可以知道，这个异常被ZygoteInit.main()截获(注意:我们此时是在SS进程中)，然后调用该异常的run函数。 */ throw new } /*回到zygoteinit.java的main函数看一下这个run 函数的功能*/ public void run() { try /*这个mMethod是com.android.server.SystemServer的main函数*/ mMethod.invoke(null, new Object[] { mArgs }); } …… } |
可以看出，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 dalvik.system.VMRuntime.getRuntime().clearGrowthLimit(); …… //加载libandroid_servers.so库 System.loadLibrary("android_servers"); Slog.i(TAG, "Entered the // 判断服务是否为sensor服务，如果是，就启动之。 nativeInit(); // This used to be its own // just the loop we run on ServerThread thr = new 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通信系统中，进行消息循环。