本文基于MTK2601 - Android5.1分析
1、所有的進程都是init進程的子孫進程，也就是說，所有的進程都是直接或者間接地由init進程fork出來的。Zygote進程也不例外，它是在系統(tǒng)啟動的過程，由init進程創(chuàng)建的。在系統(tǒng)啟動腳本system/core/rootdir/init.zygote32.rc文件中，我們可以看到啟動Zygote進程的腳本命令：
2、app_process運行后且傳入?yún)?shù)（SystemServer得到加載），對應源碼如下：
frameworks/base/cmds/app_process/app_main.cpp:
截取main函數(shù)關鍵代碼：
frameworks/base/core/jni/AndroidRuntime.cpp:
截取start函數(shù)關鍵代碼：
由以上代碼可知，VM運行后會直接獲得JNIEnv* env指針；剩下的就是JNI的用法了。
截取startVm部分關鍵代碼：
3、如此一來，代碼順序來到Java層，ZygoteInit的main方法關鍵代碼：
1)? registerZygoteSocket:創(chuàng)建了一個ServerSocket接口，用來和ActivityManagerService通訊
這部分代碼可自行查看源碼，說白了就是Android系統(tǒng)封裝的Java套接字；
ZygoteInit是套接字服務端。
2)? 調用startSystemServer函數(shù)來啟動SystemServer組件
handleSystemServerProcess方法截?。?/p>
此時的class就是上文代碼中的com.android.server.SystemServer
3)? 調用runSelectLoop函數(shù)進入一個無限循環(huán)在前面創(chuàng)建的socket接口上等待ActivityManagerService請求創(chuàng)建新的應用程序進程。
ActivityManagerService會通過Process的start方法和ZygoteInit進行socket通信，并且創(chuàng)建一個子進程，相當于Java套接字的客戶端；此套接字在Process中維護：
ActivityManagerService中的調用關系：
把相關參數(shù)發(fā)送給Zygote（上文有zygoteconnection接收參數(shù)的代碼，并且會調用handleChildProc方法，此方法就已經是子進程了）；
由以上代碼分析此時classname就是android.app.ActivityThread；并且作為新進程的主進程。
ActivityThread想必都熟悉了，典型的Looper線程，且不會退出。
4、SystemServer分析：
由上可知，SystemServer的main方法在子進程中被調用。
run方法如下：
1）startBootstrapServices();
例如：Installer、ActivityManagerService、PowerManagerService、DisplayManagerService、PackageManagerService、UserManagerService
2）startCoreServices();
例如：LightsService、BatteryService、UsageStatsService、WebViewUpdateService
3）startOtherServices();
此處服務較多。。?？丛创a吧
服務加載完成后，不過有一個地方需要貼出來：
另外，SystemServer有一個非常重要的方法：
以后要定制一些服務可以直接加在ServiceManager里面了；應該不太容易被系統(tǒng)殺死吧O(∩_∩)O哈哈哈~
4、分析新應用的啟動（兩種情況）：
1）非SystemServer應用進程：
入口是ActivityThread的main函數(shù)：
也就是fork完子進程后的線程就是主線程，另外可以看下Looper.prepareMainLooper函數(shù)。
2）SystemServer的run方法有一句：
// Initialize the system context.
createSystemContext();
可在之前截圖中查看；接下來：
跟到attach方法中：
1）先看else里面：
mInitialApplication就是一個Application實例，且直接調用了onCreate方法。
貌似沒有看出有啥貓膩，Application在SystemServer中有啥用呢？
2）另一種情況下（可以看見有heap限制）：
我們可以看見，直接拿到ActivityManagerNative，調用attachApplication方法，ActivityManagerNative是抽象類，其實現(xiàn)類就是ActivityManagerService。
attachApplication方法調用attachApplicationLocked方法：
thread和ActivityThread的mAppThread是同一個Binder。
由此發(fā)現(xiàn)，ActivityManagerService實際上是和ActivityThread的內部類ApplicationThread直接進行交互的（由于Binder的存在），具體有activity的生命周期、service的生命周期以及服務的綁定、解綁等搔操作，哈哈。
ApplicationThread的bindApplication方法最后會用Handler向ActivityThread發(fā)消息：
消息處理如下：
回到上面attachApplicationLocked方法，有一句：
mStackSupervisor.attachApplicationLocked(app)；方法內部會調用自己的realStartActivityLocked方法：
同樣是用Handler給ActivityThread發(fā)消息；
performLaunchActivity方法應該就比較熟悉了，截取關鍵部分吧：
callActivityOnCreate跟進去就對應到Activity的onCreate了。
圖中的appContext對象就是ContextImpl的實例；也就是我們常常在Activity中用的上下文O(∩_∩)O哈哈~
