㈠ android View 事件分發機制
Android 事件機制包含系統啟動流程、輸入管理(InputManager)、系統服務和 UI 的通信(WindowManagerService + ViewRootImpl + Window)、事件分發等一系列的環節。
Android 系統中將輸入事件定義為 InputEvent，根據輸入事件的類型又分為了 KeyEvent（鍵盤事件） 和 MotionEvent（屏幕觸摸事件）。這些事件統一由系統輸入管理器 InputManager 進行分發。
在系統啟動的時候，SystemServer 會啟動 WindowManagerService，WMS 在啟動的時候通過 InputManager 來負責監控鍵盤消息。
InputManager 負責從硬體接收輸入事件，並將事件通過 ViewRootImpl 分發給當前激活的窗口處理，進而分發給 View。
Window 和 InputManagerService 之間通過 InputChannel 來通信，底層通過 socket 進行通信。
Android Touch 事件的基礎知識：
KeyEvent 對應了鍵盤的輸入事件；MotionEvent 就是手勢事件，滑鼠、筆、手指、軌跡球等相關輸入設備的事件都屬於 MotionEvent。
InputEvent 統一由 InputManager 進行分發，負責與硬體通信並接收輸入事件。
system_server 進程啟動時會創建 InputManagerService 服務。
system_server 進程啟動時同時會啟動 WMS，WMS 在啟動的時候就會通過 IMS 啟動 InputManager 來監控鍵盤消息。
App 端與服務端建立了雙向通信之後，InputManager 就能夠將產生的輸入事件從底層硬體分發過來，Android 提供了 InputEventReceiver 類，以接收分發這些消息：
Window 和 IMS 之間通過 InputChannel 通信。InputChannel 是一個 pipe，底層通過 socket 進行通信。在 ViewRootImpl.setView() 過程中注冊 InputChannel。
Android 事件傳遞機制是 先分發再處理 ，先由外部的 View 接收，然後依次傳遞給其內層的 View，再從最內層 View 反向依次向外層傳遞。
三個方法的關系如下：
分發事件：
應用了樹的 深度優先搜索演算法 （Depth-First-Search，簡稱 DFS 演算法），每個 ViewGroup 都持有一個 mFirstTouchTarget, 當接收到 ACTION_DOWN 時，通過遞歸遍歷找到 View 樹中真正對事件進行消費的 Child，並保存在 mFirstTouchTarget 屬性中，依此類推組成一個完整的分發鏈。在這之後，當接收到同一事件序列的其它事件如 ACTION_MOVE、ACTION_UP 時，則會跳過遞歸流程，將事件直接分發給下一級的 Child。
ViewGroup 分發事件的主要的任務是找一個 Target，並且用這個 Target 處理事件，主要邏輯如下 ：
為什麼倒序查找 TouchTarget?
如果按添加順序遍歷，當 View 重疊時（FrameLayout），先添加的 View 總是能消費事件，而後添加的 View 不可能獲取到事件。
攔截事件：
[1] Android 事件分發機制的設計與實現
[2] Android 事件攔截機制的設計與實現
㈡ android的ViewpPger中，如何遍歷得到下面布局問加你中的所有控制項，方便對空間進行統一管理
你可創建一個集合來保存你的幾個布局：private ArrayList<View> pageViews;
pageViews = new ArrayList<View>();
pageViews.add(v1);
pageViews.add(v2);
pageViews.add(v3);
pagerAdapter = new ViewPagerAdapter(pageViews);
這里創建Adapter的時候把這個集合傳進去。
然後：uiControl = new UIControlForIntegrate(handler, OnAppPressedListener,
this);
uiControl.setResource(pageViews);//控制ui的地方也把這個集合傳進去。這樣它們指向的都是一個對象。你可以很方便的控制UI。或者你沒有控制UI的類。直接在你的主類裡面也可直接用這個集合里的View.
㈢ Android寶典|View必考知識點總結
我們知道，Activity 是在 ActivityThread 的 performLaunchActivity 中進行創建的，在創建完成之後就會調用其 attach 方法，它是先於 onCreate、onStart、onResume 等生命周期函數的，因此將 attach 方法作為這篇文章主線的開頭：
attach() 方法就是 new 一個 PhoneWindow 並且關聯 WindowManager。
接下來就到了 onCreate 方法：
這一步就是把我們的布局文件解析成 View 塞到 DecorView 的一個 id 為 R.id.content 的 ContentView 中，DecorView 本身是一個 FrameLayout，它還承載了 StatusBar、NavigationBar 。
然後在 handleResumeActivity 中，通過 WindowManager 的 addView 方法把 DecorView 添加進去，實際實現是 WindowManagerImpl 的 addView 方法，它裡面再通過 WindowManagerGlobal 的實例去 addView 的，在它裡面就會 new 一個 ViewRootImpl，也就是說最後是把 DecorView 傳給了 ViewRootImpl 的 setView 方法。ViewRootImpl 是 DecorView 的管理者，它負責 View 樹的測量、布局、繪制，以及通過 Choreographer 來控制 View 的刷新。
WMS 是所有 Window 窗口的管理員，負責 Window 的添加和刪除、Surface 的管理和事件派發等等，因此每一個 Activity 中的 PhoneWindow 對象如果需要顯示等操作，就必須要與 WMS 交互才能進行。
在 ViewRootImpl 的 setView 方法中，會調用 requestLayout，並且通過 WindowSession 的 addToDisplay 與 WMS 進行交互。WMS 會為每一個 Window 關聯一個 WindowStatus。
SurfaceFlinger 主要是進行 Layer 的合成和渲染。
在 WindowStatus 中，會創建 SurfaceSession，SurfaceSession 會在 Native 層構造一個 SurfaceComposerClient 對象，它是應用程序與 SurfaceFlinger 溝通的橋梁。
經過步驟四和步驟五之後，ViewRootImpl 與 WMS、SurfaceFlinger 都已經建立起連接，但此時 View 還沒顯示出來，我們知道，所有的 UI 最終都要通過 Surface 來顯示，那麼 Surface 是什麼時候創建的呢？
這就要回到前面所說的 ViewRootImpl 的 requestLayout 方法了，首先會 checkThread 檢查是否是主線程，然後調用 scheleTraversals 方法，scheleTraversals 方法會先設置同步屏障，然後通過 Choreographer 類在下一幀到來時去執行 doTraversal 方法。簡單來說，Choreographer 內部會接受來自 SurfaceFlinger 發出的 Vsync 垂直同步信號，這個信號周期一般是 16ms 左右。doTraversal 方法首先會先移除同步屏障，然後 performTraversals 真正進行 View 的繪制流程，即調用 performMeasure、performLayout、performDraw。不過在它們之前，會先調用 relayoutWindow 通過 WindowSession 與 WMS 進行交互，即把 java 層創建的 Surface 與 Native 層的 Surface 關聯起來。
接下來就是正式繪制 View 了，從 performTraversals 開始，Measure、Layout、Draw 三步走。
第一步是獲取 DecorView 的寬高的 MeasureSpec 然後執行 performMeasure 流程。MeasureSpec 簡單來說就是一個 int 值，高 2 位表示測量模式，低 30 位用來表示大小。策略模式有三種，EXACTLY、AT_MOST、UNSPECIFIED。EXACTLY 對應為 match_parent 和具體數值的情況，表示父容器已經確定 View 的大小；AT_MOST 對應 wrap_content，表示父容器規定 View 最大隻能是 SpecSize；UNSPECIFIED 表示不限定測量模式，父容器不對 View 做任何限制，這種適用於系統內部。接著說，performMeasure 中會去調用 DecorView 的 measure 方法，這個是 View 裡面的方法並且是 final 的，它裡面會把參數透傳給 onMeasure 方法，這個方法是可以重寫的，也就是我們可以干預 View 的測量過程。在 onMeasure 中，會通過 getDefaultSize 獲取到寬高的默認值，然後調用 setMeasureDimension 將獲取的值進行設置。在 getDefaultSize 中，無論是 EXACTLY 還是 AT_MOST，都會返回 MeasureSpec 中的大小，這個 SpecSize 就是測量後的最終結果。至於 UNSPECIFIED 的情況，則會返回一個建議的最小值，這個值和子元素設置的最小值以及它的背景大小有關。從這個默認實現來看，如果我們自定義一個 View 不重寫它的 onMeasure 方法，那麼 warp_content 和 match_parent 一樣。所以 DecorView 重寫了 onMeasure 函數，它本身是一個 FrameLayout，所以最後也會調用到 FrameLayout 的 onMeasure 函數，作為一個 ViewGroup，都會遍歷子 View 並調用子 View 的 measure 方法。這樣便實現了層層遞歸調用到了每個子 View 的 onMeasure 方法進行測量。
第二步是執行 performLayout 的流程，也就是調用到 DecorView 的 layout 方法，也就是 View 裡面的方法，如果 View 大小發生變化，則會回調 onSizeChanged 方法，如果 View 狀態發生變化，則會回調 onLayout 方法，這個方法在 View 中是空實現，因此需要看 DecorView 的父容器 FrameLayout 的 onLayout 方法，這個方法就是遍歷子 View 調用其 layout 方法進行布局，子 View 的 layout 方法被調用的時候，它的 onLayout 方法又會被調用，這樣就布局完了所有的 View。
第三步就是 performDraw 方法了，裡面會調用 drawSoftware 方法，這個方法需要先通過 mSurface lockCanvas 獲取一個 Canvas 對象，作為參數傳給 DecorView 的 draw 方法。這個方法調用的是 View 的 draw 方法，先繪制 View 背景，然後繪制 View 的內容，如果有子 View 則會調用子 View 的 draw 方法，層層遞歸調用，最終完成繪制。
完成這三步之後，會在 ActivityThread 的 handleResumeActivity 最後調用 Activity 的 makeVisible，這個方法就是將 DecorView 設置為可見狀態。
https://juejin.im/post/5c67c1e16fb9a04a05403549
https://juejin.im/post/5bf16ff5f265da6141712acc
㈣ Android View知識
1， View是除了Android四大組件外，最常用的東西
2，什麼是View：
View是android中所有控制項的父類，比如TextView,LinearLayout等等
其中LinearLayout繼承自控制項組ViewGroup，當然ViewGroup也是繼承自View
3，View的位置
top：左上角縱坐標
left：左上角橫坐標
right：右下角橫坐標
bottom:右下角縱坐標
如下圖：
4，view的MotionEvent和TouchSlop
4.1MotionEvent：
ACTION_DOWN:手指接觸屏幕
ACTION_MOVE:手指在屏幕上滑動
ACTION_UP:手指離開屏幕。
4.2TouchSlop
處理滑動時的過濾條件，簡單來說就是，手指在屏幕上的一次操作算不算滑動。
系統默認值：ViewConfiguration.get(context).getScaledTouchSlop()
5，getX（）getY（）和getRawX（）和getRawY（）
前兩者相對於父控制項View 後兩者相對於手機屏幕
6，VelocityTracker,GestureDetector,Scroller
6.1VelocityTracker:滑動速度，在view的ontouch事件中，查看速度
6.2 GestureDetector：手勢判斷，比如長按，點擊，雙擊等，很少用，可以用 ontouch事件來代替
6.3Scroller：彈性滑動對象，實現view的位置改變等
7，原始滑動方式
7.1：ScrollerTo和Scroller By（）
實現簡單 但是只能滑動view裡面的子元素
7.2：改變view參數
實現復雜，但是如果view有交互，這種方式比較好
7.3：動畫
適用於沒有交互的，或者動畫復雜的view的滑動
8View的事件分發：
8.1：Activity-window-View
8.2：view中是從父到子，也就是從外到內，都不處理，返回給最頂級
8.3：ViewGroup默認不攔截任何事件，默認返回false
8.4：分發方法：dispatchTouchEvent，OnInterceptTouchEvent，OnTouchEvent
dispatchTouchEvent：分發
OnInterceptTouchEvent：攔截
OnTouchEvent：處理點擊事件
㈤ android基礎-viewgroup的測量，布局，繪制
相關文章
android基礎-view的測量，布局，繪制
viewgroup的作用主要用於管理子view，而在測量的時候可以分兩種情況
關於viewgroup遍歷子view去慧胡測量的方法，android中已經幫我們封裝了兩個常用方法：
protected void measureChildren(int widthMeasureSpec, int heightMeasureSpec)
protected void measureChildWithMargins(View child, int parentWidthMeasureSpec, int widthUsed, int parentHeightMeasureSpec, int heightUsed)
從方法名和方法裡面不難看出這兩個方法的區別，就是後者把子view的padding和margin也考慮了進去，不過他們最終調用的都是子view的 view.measure(int wSpec,int hSpec) 方法該方法回觸發子view的 onMeasure 方法
最後在測量子view之後，就要對自身大小做決定了，同樣是根據不同的測量模式來確定最終的大小，並且最後需要調用
protected final void setMeasuredDimension(int measuredWidth, int measuredHeight)
該方法來設置viewgroup的寬高
viewgroup的測量栗子如下：
在自定義viewgroup的時候，我前埋攔們必須重寫如下方法：
該方法主要就是通知子view去設置他們的布局位置，之前 android基礎-view的測量，布局，繪制 的篇章也已經詳細說明了view.layout方法的過程
viewgroup通知情況下不需要繪制，因為他本身就沒有需要繪制的東西，如果不是指定了viewgroup的背景色，那麼viewgroup的onDraw方法都不會被調用。但是，viewgroup會使用dispatchDraw()方法來繪制其子view，其過程同樣是通過變遍歷所有的子view，並調用子view的繪制方法來完成繪制工作
注意對於viewgroup而言onDraw()先於dispatchDraw()執行,用於本身控制項的繪制,dispatchDraw()用於子控制項的繪制，所以如果想對於viewgroup中繪制完子view之後在對其修改，我們可以在dispatchDraw調用surper方法之前做自己想要的繪制效果，這樣避免了被子view的覆蓋
viewgroup的測量，布局，繪制，其實都只是用來管理和通知子液鎮view去具體實現，可能最主要就是onLayout方法去定義子view的顯示位置，其他的核心都是在view中做處理的，所以先理解清楚view的顯示過程，那麼再來理解viewgroup的顯示過程，就會容易理解許多
《Android群英傳》¬
㈥ android,80+個TextView當時全是黑色，現在想改為字體白色,能用遍歷所有view的方法判斷是否是textView嗎
可以,用instanceof遍歷ViewGroup，如:
//獲取LinearLayout實例
LinearLayoutll=(LinearLayout)findViewById(R.id.ll);
//遍歷LinearLayout中的元素
for(inti=0;i<ll.getChildCount();i++){
if(ll.getChildAt(i)instanceofTextView){
//如果是TextView，做你需要的處理
}
}
㈦ android 遍歷所有控制項
獲取總得TabLayout, 強轉成ViewGroup，傳入下面方法
private void getButtons(ViewGroup viewGroup) {
if (viewGroup == null) {
return;
}
int count = viewGroup.getChildCount();
for (int i = 0; i < count; i++) {
View view = viewGroup.getChildAt(i);
if (view instanceof Button) { // 若是Button記錄下
Button newDtv = (Button) view;
} else if (view instanceof ViewGroup) {
// 若是布局控制項（LinearLayout或RelativeLayout）,繼續查詢子View
this.getButtons((ViewGroup) view);
}
}
}
㈧ Android UI繪制之View繪制的工作原理
這是AndroidUI繪制流程分析的第二篇文章，主要分析界面中View是如何繪制到界面上的具體過程。
ViewRoot 對應於 ViewRootImpl 類，它是連接 WindowManager 和 DecorView 的紐帶，View的三大流程均是通過 ViewRoot 來完成的。在 ActivityThread 中，當 Activity 對象被創建完畢後，會將 DecorView 添加到 Window 中,同時會創建 ViewRootImpl 對象，並將 ViewRootImpl 對象和 DecorView 建立關聯。
measure 過程決定了 View 的寬/高， Measure 完成以後，可以通過 getMeasuredWidth 和 getMeasuredHeight 方法來獲取 View 測量後的寬/高，在幾乎所有的情況下，它等同於View的最終的寬/高，但是特殊情況除外。 Layout 過程決定了 View 的四個頂點的坐標和實際的寬/高，完成以後，可以通過 getTop、getBottom、getLeft 和 getRight 來拿到View的四個頂點的位置，可以通過 getWidth 和 getHeight 方法拿到View的最終寬/高。 Draw 過程決定了 View 的顯示，只有 draw 方法完成後 View 的內容才能呈現在屏幕上。
DecorView 作為頂級 View ，一般情況下，它內部會包含一個豎直方向的 LinearLayout ，在這個 LinearLayout 裡面有上下兩個部分，上面是標題欄，下面是內容欄。在Activity中，我們通過 setContentView 所設置的布局文件其實就是被加到內容欄中的，而內容欄id為 content 。可以通過下面方法得到 content:ViewGroup content = findViewById(R.android.id.content) 。通過 content.getChildAt(0) 可以得到設置的 view 。 DecorView 其實是一個 FrameLayout , View 層的事件都先經過 DecorView ，然後才傳遞給我們的 View 。
MeasureSpec 代表一個32位的int值，高2位代表 SpecMode ,低30位代表 SpecSize , SpecMode 是指測量模式，而 SpecSize 是指在某種測量模式下的規格大小。
SpecMode 有三類，如下所示：
UNSPECIFIED
EXACTLY
AT_MOST
LayoutParams需要和父容器一起才能決定View的MeasureSpec，從而進一步決定View的寬/高。
對於頂級View，即DecorView和普通View來說，MeasureSpec的轉換過程略有不同。對於DecorView，其MeasureSpec由窗口的尺寸和其自身的LayoutParams共同確定；
對於普通View，其MeasureSpec由父容器的MeasureSpec和自身的Layoutparams共同決定；
MeasureSpec一旦確定，onMeasure就可以確定View的測量寬/高。
小結一下
當子 View 的寬高採用 wrap_content 時，不管父容器的模式是精確模式還是最大模式，子 View 的模式總是最大模式+父容器的剩餘空間。
View 的工作流程主要是指 measure 、 layout 、 draw 三大流程，即測量、布局、繪制。其中 measure 確定 View 的測量寬/高， layout 確定 view 的最終寬/高和四個頂點的位置，而 draw 則將 View 繪制在屏幕上。
measure 過程要分情況，如果只是一個原始的 view ，則通過 measure 方法就完成了其測量過程，如果是一個 ViewGroup ，除了完成自己的測量過程外，還會遍歷調用所有子元素的 measure 方法，各個子元素再遞歸去執行這個流程。
如果是一個原始的 View，那麼通過 measure 方法就完成了測量過程，在 measure 方法中會去調用 View 的 onMeasure 方法，View 類裡面定義了 onMeasure 方法的默認實現:
先看一下 getSuggestedMinimumWidth 和 getSuggestedMinimumHeight 方法的源碼：
可以看到， getMinimumWidth 方法獲取的是 Drawable 的原始寬度。如果存在原始寬度（即滿足 intrinsicWidth > 0），那麼直接返回原始寬度即可；如果不存在原始寬度（即不滿足 intrinsicWidth > 0），那麼就返回 0。
接著看最重要的 getDefaultSize 方法：
如果 specMode 為 MeasureSpec.UNSPECIFIED 即未指定模式，那麼返回由方法參數傳遞過來的尺寸作為 View 的測量寬度和高度；
如果 specMode 不是 MeasureSpec.UNSPECIFIED 即是最大模式或者精確模式，那麼返回從 measureSpec 中取出的 specSize 作為 View 測量後的寬度和高度。
看一下剛才的表格：
當 specMode 為 EXACTLY 或者 AT_MOST 時，View 的布局參數為 wrap_content 或者 match_parent 時，給 View 的 specSize 都是 parentSize 。這會比建議的最小寬高要大。這是不符合我們的預期的。因為我們給 View 設置 wrap_content 是希望View的大小剛好可以包裹它的內容。
因此：
如果是一個 ViewGroup，除了完成自己的 measure 過程以外，還會遍歷去調用所有子元素的 measure 方法，各個子元素再遞歸去執行 measure 過程。
ViewGroup 並沒有重寫 View 的 onMeasure 方法，但是它提供了 measureChildren、measureChild、measureChildWithMargins 這幾個方法專門用於測量子元素。
如果是 View 的話，那麼在它的 layout 方法中就確定了自身的位置（具體來說是通過 setFrame 方法來設定 View 的四個頂點的位置，即初始化 mLeft ， mRight ， mTop ， mBottom 這四個值）， layout 過程就結束了。
如果是 ViewGroup 的話，那麼在它的 layout 方法中只是確定了 ViewGroup 自身的位置，要確定子元素的位置，就需要重寫 onLayout 方法；在 onLayout 方法中，會調用子元素的 layout 方法，子元素在它的 layout 方法中確定自己的位置，這樣一層一層地傳遞下去完成整個 View 樹的 layout 過程。
layout 方法的作用是確定 View 本身的位置，即設定 View 的四個頂點的位置，這樣就確定了 View 在父容器中的位置；
onLayout 方法的作用是父容器確定子元素的位置，這個方法在 View 中是空實現，因為 View 沒有子元素了，在 ViewGroup 中則進行抽象化，它的子類必須實現這個方法。
1.繪制背景（ background.draw(canvas); ）；
2.繪制自己（ onDraw ）；
3.繪制 children（ dispatchDraw(canvas) ）；
4.繪制裝飾（ onDrawScrollBars ）。
dispatchDraw 方法的調用是在 onDraw 方法之後，也就是說，總是先繪制自己再繪制子 View 。
對於 View 類來說， dispatchDraw 方法是空實現的，對於 ViewGroup 類來說， dispatchDraw 方法是有具體實現的。
通過 dispatchDraw 來傳遞的。 dispatchDraw 會遍歷調用子元素的 draw 方法，如此 draw 事件就一層一層傳遞了下去。dispatchDraw 在 View 類中是空實現的，在 ViewGroup 類中是真正實現的。
如果一個 View 不需要繪制任何內容，那麼就設置這個標記為 true，系統會進行進一步的優化。
當創建的自定義控制項繼承於 ViewGroup 並且不具備繪制功能時，就可以開啟這個標記，便於系統進行後續的優化；當明確知道一個 ViewGroup 需要通過 onDraw 繪制內容時，需要關閉這個標記。
參考：《Android開發藝術探索》
㈨ Android 自定義View之Layout過程
系列文章：
在上篇文章： Android 自定義View之Measure過程 ，我們分析了Measure過程，本次將會掀開承上啟下的Layout過程神秘面紗，
通過本篇文章，你將了解到：
在上篇文章的比喻里，我們說過：
該ViewGroup 重寫了onMeasure(xx)和onLayout(xx)方法：
同時，當layout 執行結束，清除PFLAG_FORCE_LAYOUT標記，該標記會影響Measure過程是否需要執行onMeasure。
該View 重寫了onMeasure(xx)和onLayout(xx)方法：
MyViewGroup里添加了MyView、Button兩個控制項，最終運行的效果如下：
可以看出，MyViewGroup 里子布局的是橫向擺放的。我們重點關注Layout過程。實際上，MyViewGroup里我們只重寫了onLayout(xx)方法，MyView也是重寫了onLayout(xx)方法。
接下來，分析View Layout過程。
與Measure過程類似，連接ViewGroup onLayout(xx)和View onLayout(xx)之間的橋梁是View layout(xx)。
可以看出，最終都調用了setFrame(xx)方法。
對於Measure過程在onMeasure(xx)里記錄了尺寸的值，而對於Layout過程則在layout(xx)里記錄了坐標值，具體來說是在setFrame(xx)里，該方法兩個重點地方：
View.onLayout(xx)是空實現
從layout(xx)和onLayout(xx)聲明可知，這兩個方法都是可以被重寫的，接下來看看ViewGroup是否重寫了它們。
ViewGroup.layout(xx)雖然重寫了layout(xx)，但是僅僅做了簡單判斷，最後還是調用了View.layout(xx)。
這重寫後將onLayout變為抽象方法，也就是說繼承自ViewGroup的類必須重寫onLayout(xx)方法。
我們以FrameLayout為例，分析其onLayout(xx)做了什麼。
FrameLayout.onLayout(xx)為子布局Layout的時候，起始坐標都是以FrameLayout為基準，並沒有記錄上一個子布局佔了哪塊位置，因此子布局的擺放位置可能會重疊，這也是FrameLayout布局特性的由來。而我們之前的Demo在水平方向上記錄了上一個子布局的擺放位置，下一個擺放時只能在它之後，因此就形成了水平擺放的功能。
由此類推，我們常說的某個子布局在父布局裡的哪個位置，決定這個位置的即是ViewGroup.onLayout(xx)。
上邊我們分析了View.layout(xx)、View.onLayout(xx)、ViewGroup.layout(xx)、ViewGroup.onLayout(xx)，這四者什麼關系呢？
View.layout(xx)
View.onLayout(xx)
ViewGroup.layout(xx)
ViewGroup.onLayout(xx)
View/ViewGroup 子類需要重寫哪些方法：
用圖表示：
通過上述的描述，我們發現Measure過程和Layout過程里定義的方法比較類似：
它倆的套路比較類似：measure(xx)、layout(xx)一般不需要我們重寫，measure(xx)里調用onMeasure(xx)，layout(xx)為調用者設置坐標值。
若是ViewGroup：onMeasure(xx)里遍歷子布局，並測量每個子布局，最後將結果匯總，設置自己測量的尺寸；onLayout(xx)里遍歷子布局，並設置每個子布局的坐標。
若是View：onMeasure(xx)則測量自身，並存儲測量尺寸；onLayout(xx)不需要做什麼。
Measure過程雖然比Layout過程復雜，但仔細分析後就會發現其本質就是為了設置兩個成員變數：
而Layout過程雖然比較簡單，其本質是為了設置坐標值
將Measure設置的變數和Layout設置的變數聯系起來：
此外，Measure過程通過設置PFLAG_LAYOUT_REQUIRED 標記來告訴需要進行onLayout，而Layout過程通過清除 PFLAG_FORCE_LAYOUT來告訴Measure過程不需要執行onMeasure了。
這就是Layout的承上作用
我們知道View的繪制需要依靠Canvas繪制，而Canvas是有作用區域限制的。例如我們使用：
Cavas繪制的起點是哪呢？
對於硬體繪制加速來說：正是通過Layout過程中設置的RenderNode坐標。
而對於軟體繪制來說：
關於硬體繪制加速/軟體繪制 後續文章會分析。
這就是Layout的啟下作用
以上即是Measure、Layout、Draw三者的內在聯系。
當然Layout的"承上"還需要考慮margin、gravity等參數的影響。具體用法參見最開始的Demo。
getMeasuredWidth()/getMeasuredHeight 與 getWidth/getHeight區別
我們以獲取width為例，分別來看看其方法：
getMeasuredWidth()：獲取測量的寬，屬於"臨時值"
getWidth()：獲取View真實的寬
在Layout過程之前，getWidth() 默認為0
何時可以獲取真實的寬、高
下篇將分析Draw()過程，我們將分析"一切都是draw出來的"道理
本篇基於 Android 10.0