SystemServer核心邏輯的入口是main函數，其代碼如下： **SystemServer.java** ~~~ public static void main(String[] args) { if(System.currentTimeMillis() < EARLIEST_SUPPORTED_TIME) { //如果系統時鐘早于1970，則設置系統時鐘從1970開始 Slog.w(TAG, "System clock is before 1970; setting to 1970."); SystemClock.setCurrentTimeMillis(EARLIEST_SUPPORTED_TIME); } //判斷性能統計功能是否開啟 if(SamplingProfilerIntegration.isEnabled()) { SamplingProfilerIntegration.start(); timer = new Timer(); timer.schedule(new TimerTask() { @Override public void run() { //SystemServer性能統計，每小時統計一次，統計結果輸出為文件 SamplingProfilerIntegration.writeSnapshot("system_server", null); }// SNAPSHOT_INTERVAL定義為1小時 }, SNAPSHOT_INTERVAL, SNAPSHOT_INTERVAL); } //和Dalvik虛擬機相關的設置，主要是內存使用方面的控制 dalvik.system.VMRuntime.getRuntime().clearGrowthLimit(); VMRuntime.getRuntime().setTargetHeapUtilization(0.8f); //加載動態庫libandroid_servers.so System.loadLibrary("android_servers"); init1(args);//調用native的init1函數 } ~~~ main函數首先做一些初始化工作，然后加載動態庫libandroid_servers.so，最后再調用native的init1函數。該函數在libandroid_servers.so庫中實現，其代碼如下： **com_android_server_SystemServer.cpp** ~~~ extern "C" int system_init(); static voidandroid_server_SystemServer_init1(JNIEnv* env, jobject clazz) { system_init(); //調用上面那個用extern 聲明的system_init函數 } ~~~ 而system_init函數又在另外一個庫libsystem_server.so中實現，代碼如下： **System_init.cpp** ~~~ extern "C" status_t system_init() { LOGI("Enteredsystem_init()"); //初始化Binder系統 sp<ProcessState> proc(ProcessState::self()); //獲取ServiceManager的客戶端對象BpServiceManager sp<IServiceManager> sm = defaultServiceManager(); //GrimReaper是一個很“血腥“的名字，俗稱死神 sp<GrimReaper>grim = new GrimReaper(); /* 下面這行代碼的作用就是注冊grim對象為ServiceManager死亡信息的接收者。一旦SM死亡， Binder系統就會發送訃告信息，這樣grim對象的binderDied函數就會被調用。該函數內部 將kill自己（即SystemServer）。 筆者覺得，對于這種因摯愛離世而自殺的物體，叫死神好像不太合適 */ sm->asBinder()->linkToDeath(grim, grim.get(), 0); charpropBuf[PROPERTY_VALUE_MAX]; //判斷SystemServer是否啟動SurfaceFlinger服務，該值由init.rc //腳本設置，默認為零，即不啟動SF服務 property_get("system_init.startsurfaceflinger",propBuf, "1"); /* 從4.0開始，和顯示相關的核心服務surfaceflinger可獨立到另外一個進程中。 筆者認為，這可能和目前SystemServer的負擔過重有關。另外，隨著智能終端上HDMI的普及， 未來和顯示相關的工作將會越來越繁重。將SF放在單獨進程中，不僅可加強集中管理，也可充分 利用未來智能終端上多核CPU的資源 */ if(strcmp(propBuf, "1") == 0) { SurfaceFlinger::instantiate(); } //判斷SystemServer是否啟動傳感器服務，默認將啟動傳感器服務 property_get("system_init.startsensorservice", propBuf,"1"); if(strcmp(propBuf, "1") == 0) { //和SF相同，傳感器服務也支持在獨立進程中實現 SensorService::instantiate(); } //獲得AndroidRuntime對象 AndroidRuntime* runtime = AndroidRuntime::getRuntime(); JNIEnv*env = runtime->getJNIEnv(); ......//查找Java層的SystemServer類，獲取init2函數的methodID jclassclazz = env->FindClass("com/android/server/SystemServer"); ...... jmethodID methodId = env->GetStaticMethodID(clazz, "init2","()V"); ......//通過JNI調用Java層的init2函數 env->CallStaticVoidMethod(clazz,methodId); //主線程加入Binder線程池 ProcessState::self()->startThreadPool(); IPCThreadState::self()->joinThreadPool(); returnNO_ERROR; } ~~~ 那么，SystemServer的main函數究竟做了什么呢？ 通過init1函數，辛辛苦苦從Java層穿越到Native層，做了一些初始化工作后，又通過JNI從Native層穿越到Java層去調用init2函數。 init2函數返回后，最終又回歸到Native層。 是不是感覺init1和init2這兩個函數的命名似曾相識，和我們初學編程時自定義的函數名非常像呢？其實代碼中有一段“扭捏”的注釋，解釋了編寫這種“初級”代碼的原因。很簡單，就是在對AndroidRuntime初始化前必須對一些核心服務初始化。 通過注釋可看出，這段代碼的作者也擔心被人指責，但至少可以把函數名取得更形象一點吧？