流程
init 進程
Zygote 進程
SystemServer 進程
由于SystemServer是Zygote進程fork出來的，所以該進程也擁有一個ZygoteServer所開啟等待AMS連接的Socket實例副本。在這里并不需要這個Socket，所以關閉。
- bootloader啟動linux Kernel 內(nèi)核和init進程
- init進程分裂出更多名為"daemons(守護進程)"的底層的Linux進程, 諸如android debug deamon, USB deamon等. 這些守護進程處理底層硬件相關的接口
- init進程會解析init.rc 腳本做一些初始化的工作，包括掛在文件系統(tǒng)，創(chuàng)建工作目錄以及啟動系統(tǒng)服務進程等，其中包括Zygote,ServiceManager，meidia等
- Zygote 進程會預加載必要的 Java Classes和 resource ，并打開 /dev/socket/zygote socket 去監(jiān)聽啟動應用程序的請求
- Zygote 進程會進一步啟動 system server進程，然后 system-servver 進程中會啟動AMS\WMS\PMS等服務，等服務都啟動后，AMS會打開Lanucher應用的Home Activity
system_server 為什么要在 Zygote 中啟動，而不是由 init 直接啟動呢？
Zygote 作為一個孵化器，可以提前加載一些資源，這樣 fork() 時基于 Copy-On-Write 機制創(chuàng)建的其他進程就能直接使用這些資源，而不用重新加載。比如 system_server 就可以直接使用 Zygote 中的 JNI 函數(shù)、共享庫、常用的類、以及主題資源。
為什么要專門使用 Zygote 進程去孵化應用進程，而不是讓 system_server 去孵化呢？
首先 system_server 相比 Zygote 多運行了 AMS、WMS 等服務，這些對一個應用程序來說是不需要的。另外進程的 fork() 對多線程不友好，在Linux中，fork的時候只復制當前線程到子進程，其他線程在子進程中“蒸發(fā)”了。這可能會導致死鎖，而 system_server 中肯定是有很多線程的。
在大多數(shù)操作系統(tǒng)上，為了性能的因素，鎖基本上都是實現(xiàn)在用戶態(tài)的而非內(nèi)核態(tài)（因為在用戶態(tài)實現(xiàn)最方便，基本上就是通過原子操作或者之前文章中提到的memory barrier實現(xiàn)的），所以調用fork的時候，會復制父進程的所有鎖到子進程中。
問題就出在這了。從操作系統(tǒng)的角度上看，對于每一個鎖都有它的持有者，即對它進行l(wèi)ock操作的線程。假設在fork之前，一個線程對某個鎖進行的lock操作，即持有了該鎖，然后另外一個線程調用了fork創(chuàng)建子進程?？墒窃谧舆M程中持有那個鎖的線程卻"消失"了，從子進程的角度來看，這個鎖被“永久”的上鎖了，因為它的持有者“蒸發(fā)”了。
那么如果子進程中的任何一個線程對這個已經(jīng)被持有的鎖進行l(wèi)ock操作話，就會發(fā)生死鎖。
Zygote 為什么不采用 Binder 機制進行 IPC 通信？
Binder 機制中存在 Binder 線程池，是多線程的，如果 Zygote 采用 Binder 的話就存在上面說的 fork() 與 多線程的問題了。 其實嚴格來說，Binder 機制不一定要多線程，所謂的 Binder 線程只不過是在循環(huán)讀取 Binder 驅動的消息而已，只注冊一個 Binder 線程也是可以工作的，比如 service manager 就是這樣的。 實際上 Zygote 盡管沒有采取 Binder 機制，它也不是單線程的，但它在 fork() 前主動停止了其他線程，fork() 后重新啟動了。
System Server 和 Service Manager聯(lián)系
- ServiceManager:是一個守護進程，負責管理Server并向Client提供查詢Server的功能。
- System Server 進程的主要功能:
- 加載 android servers 底層函數(shù)庫
- 啟動 android 系統(tǒng)中的 native 服務
- 創(chuàng)建、注冊并啟動 Android 的系統(tǒng)服務,在獨立線程中運行
- 創(chuàng)建 Looper 消息循環(huán),處理 System Server 進程中的事件消息
內(nèi)部維護一個list來記錄已經(jīng)注冊的所有的service，統(tǒng)一管理，向Client提供查詢服務
- luncher 進程是由ams啟動完畢后發(fā)起的，走的是app的啟動流程。所以fork的是zy gote進程。
參考
[copy on write] https://blog.csdn.net/u013043762/article/details/80817979
Android 顯示系統(tǒng)：SurfaceFlinger詳解
[Android系統(tǒng)啟動流程]
