一、init工作流程：
1、解析兩個配置文件，一個是系統配置文件init.rc，另一個是與硬件平臺相關的配置文件。init.硬件平臺名稱.rc。
2、執行各個階段的動作，創建zygote的工作就是在其中的某個階段完成的。
3、調用property_init初始化屬性相關的資源，並且通過property_start_service啓動屬性服務。
4、init進入一個無限循環，並且等待一些事情的發生。重點關注init如何處理來自socket和來自屬於服務器的相關事情。
二、zygote創建Java環境的步驟：
1、創建AppRuntime對象，並調用它的start。此後的活動則由AppRuntime來控制。
2、調動startVm創建Java虛擬機，然後調用startReg來註冊JNI函數。
3、通過JNI調用com.android.internal.os.ZygoteInit類的main函數，從此進入Java世界。然後在這個世界剛開創的時候，什麼東西都沒有。
4、調用registerZygoteSocket。通過這個函數，它可以響應子孫後代的請求。同時Zygote調用preloadClasses和preloadResources，爲Java世界添磚加瓦。
5、zygote覺得自己的工作壓力太大，便通過調用startSystemServer分裂一個子進程system_server來爲java世界服務。
6、zygote完成了Java世界的初創工作，下一步調用runSelectLoopMode。等待請求的到來（比如啓動activity）。
三、SystemServer小結：
1、ZygoteInit調用startSystemServer創建system_server進程
2、SS調用handleSystemServerProcess完成自己的使命
3、handleSystemServerProcess拋出異常，最終調用com.android.server.SystemServer的main函數
4、main函數加載libandroid_server.so並調用native的init1函數
5、init1函數通過JNI調用com.android.server.SystemServer類的init2函數。init2函數創建一個線程，用語加載各種Service
6、init1函數最終加入Binder通信系統
四、zygote分裂總結：
1、Zygote進程調用runSelectLoopMode
2、SystemServer進程發送消息給Zygote進程
3、Zygote進程fork創建子進程
4、子進程調用android.app.ActivityThread的main函數
五、ViewRoot、Surface、SF之間的關係：
1、ViewRoot有個成員變量mSurface，它是Surface類型，它和一塊Raw Buffer有關聯。
2、ViewRoot是個ViewParent，它的子view的繪畫操作，是在畫布Surface上展開的。
3、Surface和SF有交互。
六、ViewRoot和WMS之間的關係：
1、ViewRoot通過IWindowSession和WMS進程進行跨進程通信，IWindowSession定義在IWindowSession.aidl文件中。
2、ViewRoot內部有一個W對象，它也是一個基於Binder通信的類，W是IWindow的Bn端，用於響應請求。IWindow定義在IWindow.adil中。
3、事件分發大致流程：WMS所在的SystemServer進程接收到事件；WMS找到UI位於屏幕頂端的進程所對應的IWindow對象，它是Bp端對象；調用這個IWindow對象的dispatchKey，調用到IWindow的Bn端，它位於ViewRoot中，ViewRoot再根據內部view的位置信息找到真正處理事件的view，然後調用其dispatchKey函數完成事件處理。
七、Activity的創建和顯示總結：
1、Activity的頂層View是DecorView，而我們在onCreate中通過setContentView設置的View是其中的一部分。DecorView是一個FrameLayout類型的ViewGroup。
2、Activity和UI有關，它包含一個Window（PhoneWindow）和一個WindowManager（LocalWindowManager）對象，這兩個對象控制Activity顯示。
3、LocalWindowManager使用WindowManagerImpl作爲最終處理對象（Proxy模式），這個WindowManagerImpl中有一個ViewRoot對象。
4、ViewRoot實現了ViewParent接口，它有兩個重要的成員變量，一個是mView，它指向Activity頂層UI單元的DecorView，另外一個是mSurface，這個Surface包含了一個Canvas。除此之外，ViewRoot還通過Binder系統和WMS進行了跨進程通信。
5、ViewRoot能處理Handler的消息，Activity的顯示就是由ViewRoot在它的performTraversals函數中完成。
6、整個Activity的繪製流程就是從mSurface中lock一塊Canvas，然後交給mView去自由發揮畫畫的才能，最後unlockCanvasAndPost釋放這塊Canvas。
八、Surface從Native層到Java層的總結：
1、創建一個SurfaceComposerClient。（Java層SurfaceSession對象的構造函數會調用Native的SurfaceSession_init函數，看名字這個對象會和SF進行交互，SF派生於SurfaceComposer）
2、調用SurfaceComposerClient的createSurface得到一個SurfaceControl對象。
3、調用SurfaceControl的writeToParcel把一些信息寫到Parcel包中。
4、根據Parcel包的信息構造一個Surface對象。把這個對象保存到Java層的mSurface對象中，這樣ViewRoot得到了一個Native的Surface對象。
5、調用Surface的lock。
6、UI畫圖。
7、調用Surface的unlockAndPost。
九、關於SurfaceComposerClient：
1、SurfaceComposerClient成員mSignalServer，是SF在客戶端的代理BpSurfaceFlinger，主要作用是在客戶端更新完BackBuffer後（刷新了界面），通知SF進行PageFlipping和輸出等工作。
2、SurfaceComposerClient成員mControl，它是跨進程的SharedClient，是Surface系統的ControlBlock對象。
3、SurfaceComposerClient成員mClient，它是BClient在客戶端的對應物。
4、SF是從Thread派生的，所以它會有一個單獨運行的工作線程。
5、BClient和SF之間採用了Proxy模式，BClient支持Binder通信，它接受客戶端的請求，並派發給SF執行。
6、SharedClient構建於一塊共享內存中，SurfaceComposerClient和Client對象均持有這塊共享內存。
十、關於SurfaceControl：
1、mClient成員變量指向SurfaceComposerClient。
2、mSurface成員變量Binder通信響應端爲SurfaceLayer。
3、SurfaceLayer有一個變量mOwner指向它的外部類Layer，而Layer有一個成員變量mSurface指向SurfaceLayer。
4、Native Surface和SF的SurfaceLayer簡歷Binder聯繫；
十一、SurfaceFlinger工作流程：
1、調用waitForEvent等待重繪或者事務處理。
2、如果有事務處理請求，則調用handleTransaction進行處理。
3、調用handlePageFlip，對各個顯示層進行PageFlip。對於Layer類，它會生成一個新的紋理。
4、調用handleRepaint，它會遍歷各個顯示層的onDraw函數。
5、調用unlockClient，它會遍歷各個顯示層的finishPageFlip函數。
6、調用postFrameBuffer，將混合過的內容投遞到屏幕。
