最近看了很多大神的博客，都是有關(guān)Android啟動流程文章 ，看得很辛苦，似懂非懂的感覺。這篇文章是對Android啟動流程的總結(jié)和自己的見解，沒有復(fù)雜源碼分析，只是簡單總結(jié)闡述流程而已。
- 系統(tǒng)進(jìn)程啟動流程
手機(jī)開機(jī)時，先由init進(jìn)程創(chuàng)建 Zygote進(jìn)程， Zygote進(jìn)程會啟動虛擬機(jī)（ART：4.4以上； Dalvik虛擬機(jī)：4.4以下；兩者的區(qū)別是：ART是運行本地機(jī)器碼的， 比Dalvik更快。）啟動虛擬機(jī)過程中，會加載系統(tǒng)核心庫。接著注冊JNI方法；再接著就啟動SystemServer進(jìn)程，該進(jìn)程是通過Zygote進(jìn)程fork出來的， SystemServer進(jìn)程會啟動一系列的系統(tǒng)服務(wù)，比如PackageManagerService, ActivityManagerService, WindowManangerService等等等，SystemServer充當(dāng)管理角色，管理所有系統(tǒng)服務(wù)。 整個流程總結(jié)大概如下圖所示:
- 應(yīng)用程序的啟動流程
用戶日常使用的應(yīng)用是通過點擊Launcher羅列的一個圖標(biāo)來啟動的，Launcher本身也是一個應(yīng)用，但這個應(yīng)用是隨系統(tǒng)啟動時加載運行的。SystemServer進(jìn)程會啟動一系列的系統(tǒng)服務(wù)，其中PackageManagerService服務(wù)啟動時，會掃描系統(tǒng)里的apk，包括/system/framework , /system/app , /data/app 等。接著會在ActivityManagerService進(jìn)程中啟動Launcher；用戶點擊某個應(yīng)用圖標(biāo)會通過Zygote進(jìn)程fork一個進(jìn)程給該應(yīng)用。下圖所示是Zygote進(jìn)程fork應(yīng)用程序進(jìn)程的流程
Zygote進(jìn)程是如何fork一個進(jìn)程給應(yīng)用程序的？ 先來張圖比較形象：
Zygote進(jìn)程：作為服務(wù)端，Zygote進(jìn)程在啟動時已經(jīng)開啟一個ServerSocket, 一直在等待客戶端的請求。收到請求就會fork一個進(jìn)程，然后執(zhí)行一個main方法，這個方法是從客戶端傳來一個class的全包名和一系列args參數(shù)。所以在這里它們進(jìn)程間通訊是通過Socket來通訊的。
當(dāng)點擊Launcher里一個應(yīng)用圖標(biāo)，會把需要啟動的應(yīng)用包信息傳遞給ActivityManagerService服務(wù)，ActivityManagerService服務(wù)打開Socket鏈接Zygote進(jìn)程的ServerSocket，通知Zygote進(jìn)程fork進(jìn)程，ActivityManagerService服務(wù)主要是傳遞了"android.app.ActivityThread"這條命令給Zygote，Zygote進(jìn)程通過調(diào)用ActivityThread的main方法。在這個方法里啟動主線程的Looper, 創(chuàng)建了ActivityThread對象，這個應(yīng)用就這樣在自己進(jìn)程中啟動了。
在前面說到的系統(tǒng)進(jìn)程啟動流程中，SystemServer進(jìn)程也是通過Zygote進(jìn)程fork的，原理和ActivityThread相同，也是通過Socket通訊，調(diào)用SystemServer的main啟動的。
參考文章:
https://juejin.im/entry/576e42f9128fe1005a27fc11
http://blog.csdn.net/luoshengyang/article/details/8885792
http://blog.csdn.net/luoshengyang/article/details/6768304
http://blog.csdn.net/luoshengyang/article/details/6747696
http://blog.csdn.net/luoshengyang/article/details/6685853
http://blog.csdn.net/luoshengyang/article/details/6689748
http://blog.csdn.net/luoshengyang/article/details/6767736
