深入了解View知識系列二- View底層工作原理以及View的繪制流程

一般我們都知道一個View到展示出來會經過onMeasure、onLayout、onDraw三個方法，但是在分析完了setContentView後發現這幾個方法都還沒有執行，這篇将會上一篇的基礎上繼續分析View的工作原理

深入了解View知識系列一- setContentView和LayoutInflater源碼原理分析

深入了解View知識系列三-Window機制、Canvas的由來、Android事件的由來

深入了解View知識系列四-View的測量規則以及三大方法流程

本篇你會學到什麼？

Activitiy是在哪裡開始準備顯示View的
View的三大方法是在什麼時候開始執行的，又是再哪裡被調用的
我們經常使用的View.post後就可以擷取到View的寬高，為什麼呢？
View的requestLayout,invalidate請求重繪的原理
子線程真的不能更新ui嗎？為什麼

上一篇回顧

我們帶着問題在上一篇的基礎上繼續分析，View的繪制流程及工作原理，在正式分析之前我們先回顧一下上一篇的内容.

setContentView

我們知道了Activity的三個setContentView方法内部全部調用了getWindow.setContentView()
Activity的getWindow類型是PhoneWindow，而且也是Window的唯一實作類，PhoneWindow在Activity的attach方法中被初始化，并且設定了一些回調接口指向自己，例如Window的Callback接口，這個接口中有不少我們熟悉的方法，例如dispatchTouchEvent等。
在PhoneWindow的setContentView方法中主要執行三個邏輯

1.判斷裝在我們設定布局的FrameLayout是否為空，如果為空調用installDecor方法，方法中首先會先執行generateDecor()建立DecorView，接着執行generateLayout()方法設定一些Window的樣式，根據樣式來選擇需要加載的布局，然後将布局添加到DecorView中，最後找到id為content的FrameLayout，也就是來裝我們設定布局的父View。

2.通過LayoutInflater将我們設定的布局添加到id為content的FrameLayout中

3.回調Callback接口的onContentChanged()方法，這個方法在Activity中是個空實作。

LayoutInflater

PhoneWindow中的LayoutInflater是在構造函數中被建立，建立的方式和我們平時使用一樣調用的是LayoutInflater.from(content);
LayoutInflater.from方法中就是封裝了context.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
LayoutInflater中一共有4個inflater方法，其中分為兩類，一類是傳入資源id的，一類是傳入XmlPullParser的，但是最終都會執行帶xml解析器的三參方法中，這裡注意第三個參數源碼中傳入的是root!=null，該參數代表了是否将加載後的View添加到父View中，如果使用了兩個參數的inflater，并且傳入的父view不為空，則預設會将加載後的布局添加到父view，并最後傳回的是父view。
inflater方法中首先會擷取到xml的跟節點，接着判斷該節點是否為merger标簽，如果是merger标簽則繼續判斷傳入的父view是否為空，或者第三個參數是否為flase，如果滿足一項則直接抛出異常，因為merger标簽隻是為了減少布局的嵌套才存在，他并不是View的子類，是以不能單獨存在，反之則會執行rInflate方法進行遞歸加載所有子View。
如果不是merger标簽則會走到else方法中，先活着節點的名稱，根據名稱建立View，在建立View的邏輯中最終全部會調用createView方法,在這之前首先會判斷是否存在自定義的加載工廠，如果存在則調用加載工廠的建立View方法，接着通過名稱中是否包含 . 來判斷是否為Android自帶的控件，如果是Android自帶的控件第二個參數中傳入的值為android.view.,反之傳入null
在createView方法中建立View的時候會執行如下邏輯

1.首先會判斷這個名稱的構造函數是否存在，如果存在則還需要驗證這個函數所屬的ClassLoader是否合法，如果不合法則會置空這個構造函數并清除緩存。

2.接着繼續判斷構造函數是否為空，如果為空則會通過一個三元運算來加載這個名稱的Class對象，這個三元運算主要是用來判斷是否需要拼接要加載Class的名字。

3.然後會判斷是否存在Filter過濾器，這個過濾器是用來判斷是否可以建立這個Class的View對象，通過檢視設定過濾器的RemoteViews和AppWeightHostView都是通過clazz.isAnnotationPresent(RemoteView.class)來判斷的，如果傳回為flase則執行抛出異常。

4.或者該Class的構造函數并存入HashMap中

5.在else邏輯中，主要是用來優化存在過濾器的情況，為了優化性能，系統隻會在第一次的時候去驗證是否允許建立這個View，并将結果存入HashMap中，下次隻會取map中結果進行判斷。

6.通過構造函數執行個體化這個View并傳回

在建立了跟節點的View後，接着同樣會遞歸加載所有的子view，在加載的過程中會根據不同的标簽進行不同的操作，例如merger、include。如果是merger則直接抛出異常，因為merger隻能作為根節點。如果是include則會拿到layout屬性設定的布局檔案,如果未設定這個屬性執行抛出異常，接着也是根據标簽進行遞歸加載邏輯類似。
inflater最後根據傳入的父view和第三個參數的值進行判斷是傳回父view還是傳回剛加載的View

好了，回顧完了，在上一次講的setContentView過程中隻是初始化了PhoneWindow、DecorView并将我們設定的View入到了id為content的FrameLayout中，這時Activity的界面還是不可見的，因為View還沒有開始繪制的流程呢，那麼Activity中DecorView繪制的流程到底在哪裡開始的呢？其實是在ActivityThread中的handleResumeActivity()方法中，下面正式開始分析。

本篇源碼基于Android 7.1.1

1.邏輯開始點：ActivityThread中的handleResumeActivity()

這裡又提到了ActivityThread這個類，簡單說一下這個類，要知道所有的程式都是需要一個入口的，Android也不例外，ActivityThread就是Android應用的入口類，Activity、Service、ContentProvider幾乎都直接或者間接在這裡排程。現在暫時知道這麼多就好了，先不要糾結這個類，後續的會專門在四大元件系列去講。

源碼位置:/frameworks/base/core/java/android/app/ActivityThread.java

2. 上面的代碼中主要執行如下了三個邏輯。

首先調用執行了performResumeActivity方法，在這裡方法中會調用Activity的onResume方法

擷取Activity的PhoneWindow，接着拿到PhoneWindow中的DecorView并設定為隐藏，擷取Activity的中WindowManger并執行addView方法将DecorView添加到Window中。

執行Activity的makeVisible方法展示DecorView，方法中就是調用了View.VISIBLE

而且我們通過上面的可以總結兩個問題。

其實在Activity的onResume方法執行了以後才開始将DecorView添加到Window中，換句話說，也就是在onResume方法中是不能直接擷取View的寬度等參數的，因為這個時候連DecorView都沒有添加到Window中呢，是以這時也還沒有執行View的三大流程呢,又如何産生這是東西。

DecorView最終也是通過WindowManager來添加的，或者說Activity可以顯示内容其實也是通過WindowManager添加View來實作的，其實Android中所有設計View展示的最終全部都是通過WindowManager的addView來添加的，例如PopupWindow、Dialog、Toast等，下一篇會詳細分析

3.在上面的代碼中，使用了ViewManager執行了addView方法，在上一篇我們簡單的說過了，WindowManger是繼承自ViewManger的，而且WindowManger中的addView、updateViewLayout、removeView全部都是ViewManger中的方法,下面先簡單看一下這兩個類的聲明

4.我們可以看到WindowManager也是一個接口，它的具體實作是WindowMangerImpl，那麼我們繼續上面的邏輯去看一下它的addView方法，順便看一下ViewManger中的其餘兩個方法

源碼位置:/frameworks/base/core/java/android/view/WindowManagerImpl.java