閱讀者三篇Android繪制文章，會讓你對理解Android繪制有幫助：
- Android Render(一)Activity窗口構成和繪制解析
- Android Render(二)7.1源碼硬件加速下draw繪制流程分析
- Android Render(三)supportVersion 27.0.0源碼RecyclerView繪制流程解析
一、Activity窗口構成
這里我們會介紹到Activity、PhoneWindow、DecorView、ViewRootImpl、WindowManagerImpl、WindowManagerGlobal、ActivityThread和Surface，關于Activity窗口有很多方面可講，我這里只側重于Activity窗口的Render方面來講解。先來兩張張大家早已經爛熟于心的圖：
一個Activity的構成有，Activity、PhoneWindow、DecorView，再加上DecorView里面的TitleBar和我們填充的content內容，這些還Activity構成需要的具體類，不是一些輔助類，其實還有ViewRootImpl、WindowManagerImpl、WindowManagerGlobal、ActivityThread這幾個不可見的輔助類，雖然是Activity構成可見UI界面沒用到，但是這幾個輔助類都是直接或者間接負責了Activity的構建和繪制的。下面我按照我的理解來一一介紹這些類的作用和被創建時機，有不對的地方還請大家指正：
Activity：一個繼承
ContextThemeWrapper的類，繼承自ContextThemeWrapper那么意味著，通過Activity可以訪問當前包的資源（getResources、getAssets）和啟動其他組件（Activity、Service、Broadcast）以及得到各種服務（getSystemService），并且定義了當前Activity的Theme主題類型 ，關于Context的解釋請看：http://www.cnblogs.com/android100/p/Android-Context.html
并且只有創建了一個Activity才會創建后面的PhoneWindow、DecorView、ViewRootImpl、WindowManagerImpl、和Surface這些類。我這里并沒說ActivityThread類，ActivityThread是Android應用的主線程（UI線程），一個應用進程才有一個UI線程。也沒有說WindowManagerGlobal類，這個類用了幾個數組管理一個應用進程內所有Activity的DecorView和ViewRootImpl以及WindowManager對應關系的。WindowManagerGlobal是一個單例的類，一個應用進程內也只有一個。但是WindowManagerImpl是每一個Activity都有一個的。Activity是在ActivityThread的performLaunchActivity方法中用ClassLoader類加載器創建出來的。PhoneWindow： 一個繼承于抽象類Window的類，也是Window的唯一實現類。在Activity中PhoneWindow處在頂級位置，但是PhoneWindow是一個不可見的類，PhoneWindow內的DecorView才是我們可見的UI布局，但是我們可見的UI布局為啥要包裝一層PhoneWindow列？經過我的多次查看源代碼和推敲，我發現
PhoneWindow負責了Activity UI界面頂級布局DecorView的創建，PhoneWindow保存了window attributes即窗口布局屬性參數，保存了與WindowManagerService進程通訊的IBinder （取名token）方便去系統WindowManagerService進程通訊，并且負責了用戶Key和Touch事件的分發，但是PhoneWindow分發事件也是交給了DecorView來完成的。除了我們Activity在setContent時PhoneWindow創建了DecorView，好像PhoneWindow并沒有負責太多的Render的事件?？丛创a確實就是如此啊！,其實真正的Render操作都在ViewRootImpl類中。PhoneWindow是在Activity的attach方法中new出來的。WindowManagerImpl： 見名知意，就是管理Window的，在這里就是管理
PhoneWindow的，每一個Activity都有一個自己的WindowManagerImpl來管理自己的PhoneWindow，WindowManagerImpl其實是用來管理PhoneWindow里面的DecorView的，也可能是DecorView級別的其他的View，還有就是WindowManagerImpl是用來跟一個App全局的PhoneWindow管理器WindowManagerGlobal通信的，添加、移除和更新DecorView層級的View時WindowManagerImpl會調用WindowManagerGlobal中的方法來進行全局管理。WindowManagerImpl是在Activity的attach方法中new PhoneWindow后調用mWindow.setWindowManager方法創建的，其內部是調用setWindowManager的createLocalWindowManager方法new出來的。DecorView： 是一個ViewGroup，繼承自FrameLayout，是我們看到的UI界面的頂級容器，DecorView是PhoneWindow的成員。
DecorView除了是Activity界面的頂級容器以外，DecorView還是key和touch事件從上向下真正分發開始的源頭。事件分發從Activity—》PhoneWindow—》DecorView—》層層向下分發到我們的界面底層。DecorView其實在很多地方都會創建，PhoneWindow內部的getDecorView方法被調用時，要是內部的成員變量mDecor為空的話，就會調用installDecor()方法去創建一個DecorView，最后new 一個DecorView返回，保證調用PhoneWindow的getDecorView獲取 DecorView時永遠不會為空。我看代碼發現PhoneWindow的DecorView第一次調用發生在ActivityThread內的handleResumeActivity方法中，handleResumeActivity方法中還有一個很關鍵的步驟，就是調用了WindowManagerImpl的addView(DecorView，WindowManager.LayoutParams )方法，進去創建了一個跟DecorView關聯的ViewRootImpl類。ViewRootImpl:是一個實現了
ViewParent接口的final類。我前面說到了，ViewRootImpl主要是負責Activity的界面Render繪制的，負責整個窗口界面的ViewTree的繪制更新。ViewRootImpl要負責DecorView的繪制，那么ViewRootImpl就需要持有當前Activity的DecorView的引用，是的，的確如此，前面介紹DecorView的創建的時候我說到了DecorView第一次創建發生在ActivityThread內的handleResumeActivity方法中，handleResumeActivity方法中還有一個很關鍵的步驟，就是調用了WindowManagerImpl的addView(DecorView，WindowManager.LayoutParams )方法，進去創建了一個跟DecorView關聯的ViewRootImpl類。WindowManagerImpl的addView方法其實調用了WindowManagerGlobal的addView方法，在這個方法中創建了ViewRootImpl，并且在這個方法中調用了ViewRootImpl的setView方法，使ViewRootImpl持有DecorView的引用。并且把實現了ViewParent接口的自己設置成了DecorView的Parent。這樣ViewRootImpl就可以肆無忌憚地操作DecorView了。其實我在調用普通view的invalidate()刷新時，其實是經過層層Parent尋找，最終調用了最頂層的ParentViewRootImpl的invalidate()來判斷和處理每次的UI界面刷新的。Surface：一個實現了
Parcelable接口的類，對Parcelable接口不了解的，請看我之前的Binder通信的文章：Android IPC之AIDL看這一篇還不夠。Surface是原始圖像緩沖區（raw buffer）的一個句柄，而原始圖像緩沖區是由屏幕圖像合成器（screen compositor）管理的。得到了Surface這個句柄就可以得到其中的Canvas、原生緩沖器以及其它方面的內容。所以說Surface是生成Canvas的地方，具體就是調用lockCanvas方法獲得Canvas。至于Canvas、Paint 和Bitmap的關系我這里就不講了，后面會有文章來講這個。Surface是ViewRootImpl的一個final成員變量，伴隨ViewRootImpl的創建默認就new一個出來了，但是此時的Surface是一個空的，里面是沒有內容的。Surface的數據填充是要跟WindowManagerService交互的，應用進程端Binder通知WindowManagerService進程端創建一個Surface對象，最后是將WindowManagerService進程端的 Surface對象傳遞到應用進程端并賦值給應用進程的Surface對象，這樣窗口可以使用Surface來繪制UI了。因為Surface對象要夸進程傳遞，所以Surface要實現Parcelable接口。更詳細的介紹關于窗口的Surface創建請看老羅的：Android應用程序窗口（Activity）的繪圖表面（Surface）的創建過程分析
二、Activity窗口創建流程
上面的名詞介紹其實就是按照窗口的創建流程的順序來講的，但是單單是文字不夠直觀，下面以箭頭加方法名的形式展現一下，源碼分析流程基于Android7.1
/**1*/ ApplicationThread的onTransact方法接收到SystemServer進程的SCHEDULE_LAUNCH_ACTIVITY_TRANSACTION啟動Activity的Binder信息
↓
/**2*/ ApplicationThread.scheduleLaunchActivity() //
↓
/**3*/ ActivityThread.scheduleLaunchActivity() //安排啟動Activity
↓
/**4*/ ActivityThread.handleLaunchActivity() //處理啟動Activity
↓
/**5*/ ActivityThread.handleResumeActivity() // Activity 的Resume會使DecorView跟ViewRootImpl關聯
↓
/**6*/ WindowManagerGlobal.addView() //全局保存窗口的信息
↓
/**7*/ ViewRootImpl.setView() //使DecorView和ViewRootImpl關聯并繪制界面
↓
/**8*/ ViewRootImpl.requestLayout() //請求繪制ViewTree
↓
/**9*/ ViewRootImpl.scheduleTraversals() // 安排遍歷
↓
/**10*/ ViewRootImpl.doTraversal() //
↓
/**11*/ ViewRootImpl.performTraversals() //執行遍歷 會根據情況調用relayoutWindow performMeasure performLayout performDraw 等方法 這四個方法跟繪制是緊密相關的
↓
/**12*/ ViewRootImpl.relayoutWindow() //窗口第一次創建或者是窗口大小有變化并且窗口可見就會調用此方法
↓
/**13*/ ViewRootImpl.mWindowSession.relayout() //binder通信通知WindowManagerService創建一個跟應用端關聯的Surface
↓
/**14*/ ViewRootImpl調用performMeasure performLayout performDraw方法繪制UI
其實第五步ActivityThread.handleResumeActivity()方法內會調用到WindowManagerGlobal.addView()方法把窗口繪制完成，緊接著就調用到了activity.makeVisible()方法，其實就是顯示出DecorView，因為DecorView創建繪制前是被設置成了INVISIBLE的，Activity中的makeVisible方法就是把繪制完成的DecorView顯示出來了：
void makeVisible() {
if (!mWindowAdded) {
ViewManager wm = getWindowManager();
wm.addView(mDecor, getWindow().getAttributes());
mWindowAdded = true;
}
mDecor.setVisibility(View.VISIBLE); //把DecorView設置成可見的
}
至此我們就看到Activity界面上的UI了。
關于Activity的繪圖表面（Surface）的創建過程我還想多說一下，以及Surface跟Activity的對應關系。
Surface是ViewRootImpl的一個final成員變量，伴隨ViewRootImpl的創建默認就new一個出來了，但是此時的Surface是一個空的，里面是沒有內容的。Surface的數據填充是要跟
WindowManagerService交互的，應用進程端Binder通知WindowManagerService進程端創建一個Surface對象，最后是將WindowManagerService進程端的 Surface對象傳遞到應用進程端并賦值給應用進程的Surface對象，這樣窗口可以使用Surface來繪制UI了。因為Surface對象要夸進程傳遞，所以Surface要實現Parcelable接口。
從Activity窗口創建的流程我們可以知道：
每一個應用程序窗口都對應有兩個Java層的Surface對象，其中一個是在
WindowManagerService服務這一側創建的，而另外一個是在應用程序進程這一側創建的。在WindowManagerService服務這一側創建的Java層的Surface對象在C++層關聯有一個
SurfaceControl對象，用來設置應用窗口的屬性，例如，大小和位置等。在應用程序進程這一側創建的ava層的
Surface對象在C++層關聯有一個Surface對象，用來繪制應用程序窗品的UI。
三、Activity窗口組件之間的對應關系
一個設備有一個WindowManagerService進程 有一個SystemServer進程
一個App有一個WindowManagerGlobal類 有一個ActivityThread類 有一個ApplicationThread類
一個App可以有很多個Activity
一個 Activity有一個PhoneWindow類
一個PhoneWindow類有一個ViewRootImpl類
一個PhoneWindow類有一個WindowManagerImpl類
一個ViewRootImpl類有一個Surface類 有一個DecorView類
用一張圖表示：
參考文章：
Android應用程序窗口（Activity）的繪圖表面（Surface）的創建過程分析
從源碼看invalidate和requestLayout的區別
Android Render系列規劃篇
Android應用層View繪制流程與源碼分析
