SS誕生后，便和生父Zygote分道揚鑣，它有了自己的歷史使命。它的使命是什么呢？其代碼如下所示： ~~~ pid =Zygote.forkSystemServer(); if(pid == 0) { //SS進程返回0，那么下面這句話就是SS的使命： handleSystemServerProcess(parsedArgs); } ~~~ SS調用handleSystemServerProcess來承擔自己的職責。 **ZygoteInit.java** ~~~ private static void handleSystemServerProcess( ZygoteConnection.ArgumentsparsedArgs) throws ZygoteInit.MethodAndArgsCaller { //關閉從Zygote那里繼承下來的Socket。 closeServerSocket(); //設置SS進程的一些參數。 setCapabilities(parsedArgs.permittedCapabilities, parsedArgs.effectiveCapabilities); //調用ZygoteInit函數。 RuntimeInit.zygoteInit(parsedArgs.remainingArgs); } ~~~ 好了，SS走到RuntimeInit了，它的代碼在RuntimeInit.java中，如下所示： **RuntimeInit.java** ~~~ public static final void zygoteInit(String[]argv) throws ZygoteInit.MethodAndArgsCaller { //做一些常規初始化 commonInit(); //①native層的初始化。 zygoteInitNative(); intcurArg = 0; for (/* curArg */ ; curArg < argv.length; curArg++) { String arg = argv[curArg]; if (arg.equals("--")) { curArg++; break; } else if (!arg.startsWith("--")) { break; } else if (arg.startsWith("--nice-name=")) { String niceName = arg.substring(arg.indexOf('=') + 1); //設置進程名為niceName，也就是"system_server" Process.setArgV0(niceName); } } //startClass名為"com.android.server.SystemServer" String startClass = argv[curArg++]; String[] startArgs = new String[argv.length - curArg]; System.arraycopy(argv, curArg, startArgs, 0, startArgs.length); //②調用startClass，也就是com.android.server.SystemServer類的main函數。 invokeStaticMain(startClass, startArgs); } ~~~ 對于上面列舉出的兩個關鍵點，我們一個一個地分析。 1. zygoteInitNative分析 先看zygoteInitNative，它是一個native函數，實現在AndroidRuntime.cpp中。 **AndroidRuntime.cpp** ~~~ static voidcom_android_internal_os_RuntimeInit_zygoteInit( JNIEnv* env,jobject clazz) { gCurRuntime->onZygoteInit(); } //gCurRuntime是什么？還記得我們在本章開始說的app_process的main函數嗎？ int main(int argc, const char* const argv[]) { AppRuntime runtime;// 就是這個。當時我們沒顧及它的構造函數，現在回過頭看看。 } //AppRuntime的定義 class AppRuntime : public AndroidRuntime static AndroidRuntime* gCurRuntime = NULL; // gCurRuntime為全局變量。 AndroidRuntime::AndroidRuntime() { SkGraphics::Init();//Skia庫初始化 SkImageDecoder::SetDeviceConfig(SkBitmap::kRGB_565_Config); SkImageRef_GlobalPool::SetRAMBudget(512 * 1024); gCurRuntime= this; //gCurRuntime被設置為AndroidRuntime對象自己 } ~~~ 由于SS是從Zygote fork出來的，所以它也擁有Zygote進程中定義的這個gCurRuntime，也就是AppRuntime對象。那么，它的onZygoteInit會干些什么呢？它的代碼在App_main.cpp中，我們一起來看： **App_main.cpp** ~~~ virtual void onZygoteInit() { //下面這些東西和Binder有關系，但讀者可以先不管它。 sp<ProcessState> proc = ProcessState::self(); if(proc->supportsProcesses()) { proc->startThreadPool();//啟動一個線程，用于Binder通信。 } } ~~~ 一言以蔽之，SS調用zygoteInitNative后，將和Binder通信系統建立聯系，這樣SS就能夠使用Binder了。關于Binder的知識，在第6章中將詳細介紹，讀者朋友現在不必關注。 2. invokeStaticMain分析 再來看第二個關鍵點invokeStaticMain。代碼如下所示： **RuntimeInit.java** ~~~ private static void invokeStaticMain(StringclassName, 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 wheninvoking static main " + className, ex); } Method m; try { //找到com.android.server.SystemServer類的main函數，肯定有地方要調用它 m = cl.getMethod("main", new Class[] { String[].class }); }catch (NoSuchMethodException ex) { ...... }catch (SecurityException ex) { ...... } int modifiers = m.getModifiers(); if(! (Modifier.isStatic(modifiers) && Modifier.isPublic(modifiers))) { ...... } //拋出一個異常，為什么不在這里直接調用上面的main函數呢？ throw new ZygoteInit.MethodAndArgsCaller(m, argv); } ~~~ invokeStaticMain竟然拋出了一個異常，它是在哪里被截獲呢？原來是在ZygoteInit的main函數中。請看這段代碼： 注意：我們所在的進程是system_server。 **ZygoteInit.java** ~~~ .... if (argv[1].equals("true")) { //SS進程中，拋出一個異常MethodAndArgsCaller startSystemServer(); ...... catch(MethodAndArgsCaller caller) { //被截獲，調用caller的run函數 caller.run(); } ~~~ 再來看看MethodAndArgsCaller的run函數。 ~~~ public void run() { try { //這個mMethod為com.android.server.SystemServer的main函數 mMethod.invoke(null, new Object[] { mArgs }); } catch(IllegalAccessException ex) { ...... } } ~~~ 拋出的這個異常最后會導致com.android.server.SystemServer類的main函數被調用。不過這里有一個疑問，為什么不在invokeStaticMain那里直接調用，而是采用這種拋異常的方式呢？我對這個問題的看法是： - 這個調用是在ZygoteInit.main中，相當于Native的main函數，即入口函數，位于堆棧的頂層。如果不采用拋異常的方式，而是在invokeStaticMain那里調用，則會浪費之前函數調用所占用的一些調用堆棧。 關于這個問題的深層思考，讀者可以利用fork和exec的知識。對這種拋異常的方式，我個人覺得是對exec的一種近似模擬，因為后續的工作將交給com.android.server.SystemServer類來處理。 3. SystemServer的真面目 ZygoteInit分裂產生的SS，其實就是為了調用com.android.server.SystemServer的main函數，這簡直就是改頭換面！下面就來看看這個真實的main函數，代碼如下所示： **SystemServer.java** ~~~ public static void main(String[] args) { ...... //加載libandroid_servers.so System.loadLibrary("android_servers"); //調用native的init1函數。 init1(args); } ~~~ 其中main函數將加載libandroid_server.so庫，這個庫所包含的源碼文件在文件夾framework/base/services/jni下。 （1）init1分析 init1是native函數，在com_android_server_SystemServer.cpp中實現。來看看它，代碼如下所示： **com_android_server_SystemServer.cpp** ~~~ extern "C" int system_init(); static voidandroid_server_SystemServer_init1(JNIEnv* env, jobject clazz) { system_init();//調用另外一個函數。 } ~~~ system_init的實現在system_init.cpp中，它的代碼如下所示： **system_init.cpp** ~~~ extern "C" status_t system_init() { //下面這些調用和Binder有關，我們會在第6章中講述，這里先不必管它。 sp<ProcessState> proc(ProcessState::self()); sp<IServiceManager> sm = defaultServiceManager(); sp<GrimReaper>grim = new GrimReaper(); sm->asBinder()->linkToDeath(grim, grim.get(), 0); charpropBuf[PROPERTY_VALUE_MAX]; property_get("system_init.startsurfaceflinger", propBuf,"1"); if(strcmp(propBuf, "1") == 0) { //SurfaceFlinger服務在system_server進程創建 SurfaceFlinger::instantiate(); } ...... //調用com.android.server.SystemServer類的init2函數 AndroidRuntime* runtime = AndroidRuntime::getRuntime(); runtime->callStatic("com/android/server/SystemServer","init2"); //下面這幾個函數調用和Binder通信有關，具體內容在第6章中介紹。 if (proc->supportsProcesses()) { ProcessState::self()->startThreadPool(); //調用joinThreadPool后，當前線程也加入到Binder通信的大潮中 IPCThreadState::self()->joinThreadPool(); } returnNO_ERROR; } ~~~ init1函數創建了一些系統服務，然后把調用線程加入Binder通信中。不過其間還通過JNI調用了com.android.server.SystemServer類的init2函數，下面就來看看這個init2函數。 （2）init2分析 init2在Java層，代碼在SystemServer.java中，如下所示： **SystemServer.java** ~~~ public static final void init2() { Threadthr = new ServerThread(); thr.setName("android.server.ServerThread"); thr.start();//啟動一個ServerThread } ~~~ 啟動了一個ServerThread線程。請直接看它的run函數。這個函數比較長，大概看看它干了什么即可。 **SystemServer.java::ServerThread的run函數** ~~~ public void run(){ .... //啟動Entropy Service ServiceManager.addService("entropy",new EntropyService()); //啟動電源管理服務 power =new PowerManagerService(); ServiceManager.addService(Context.POWER_SERVICE, power); //啟動電池管理服務。 battery= new BatteryService(context); ServiceManager.addService("battery", battery); //初始化看門狗，在拓展部分將介紹關于看門狗的知識 Watchdog.getInstance().init(context,battery, power, alarm, ActivityManagerService.self()); //啟動WindowManager服務 wm =WindowManagerService.main(context, power, factoryTest !=SystemServer.FACTORY_TEST_LOW_LEVEL); ServiceManager.addService(Context.WINDOW_SERVICE,wm); //啟動ActivityManager服務 (ActivityManagerService)ServiceManager.getService("activity")) .setWindowManager(wm); ......//總之，系統各種重要服務都在這里啟動 Looper.loop(); //進行消息循環，然后處理消息。關于這部分內容參見第5章。 } ~~~ init2函數比較簡單，就是單獨創建一個線程，用以啟動系統各項服務，至此，讀者或許能理解SS的重要性了吧？ - **Java世界的核心Service都在這里啟動，所以它非常重要。** * * * * * **說明**：本書不對這些Service做進一步分析，今后有機會再做做專門介紹。 * * * * *