標簽： Android 源碼解析 View
關(guān)于View的繪制流程，或者說 View 的工作流程（說繪制流程容易讓人誤解成 View 的 draw 流程）自己也在網(wǎng)上看過不少好文。但每當被問到具體的問題的時候，總感覺有很多知識還是模棱兩可。因此本篇博客主要是用來梳理和總結(jié)相關(guān)知識。如果你也對View的繪制流程似懂非懂，不妨順著我的思路看下去，希望你會有所收獲。當然，任何不足、不當之處也請告訴我～
1.View 繪制流程的開始
當我們打開一個 Activity，呈現(xiàn)在我們面前的就已經(jīng)是繪制好了的 View 了。在我們梳理 View 的繪制流程之前，不妨先思考一個問題：View是從什么時候／哪里開始被繪制的？
預備知識：
1.1 關(guān)于DecorView
DecorView 繼承 FrameLayout，一般情況下包含一個 LinearLayout。而這個 LinearLayout 又包含一個 id 為 android.R.id.content 的 ViewGroup 和 一個titlebar (跟主題相關(guān)，也可能沒有)。DecorView 也被稱作頂級 View，也因此它是最先被繪制的。
1.2 關(guān)于ViewRootImpl
*注：這里涉及到的和 Window 及 WindowManager 相關(guān)知識不作過多解釋。
ViewRootImpl 顧名思義，它是所有 View 的根，即整個 View 樹的根節(jié)點。同時它也是連接WindowManager 和 DecorView 的紐帶。但需要注意的是 ViewRootImpl 本身并不是一個 View 。有了這兩點知識，我們可以回答最開始的問題了：View 的繪制流程是從 ViewRootImpl#performTravels 方法開始的。這個方法在 ActivityThread 被執(zhí)行。performTravels 方法主要包含 measure,layout,draw 這三個過程。一般情況下這里的變量 mView 就是 DecorView。
private void performTraversals() {
//......
int childWidthMeasureSpec = getRootMeasureSpec(mWidth, lp.width);
int childHeightMeasureSpec = getRootMeasureSpec(mHeight, lp.height); //......
mView.measure(childWidthMeasureSpec, childHeightMeasureSpec);
//......
mView.layout(0, 0, mView.getMeasuredWidth(), mView.getMeasuredHeight());
//......
mView.draw(canvas);
......
}
OK，一切的繪制都是從DecorView開始的啊。那么現(xiàn)在要繪制DecorView了，首先被執(zhí)行的是它的measure方法，即確定DecorView的大小，那么 DecorView 的大小是如何確定的呢？
2.View 的 measure 過程
預備知識
2.1 關(guān)于MeasureSpec
MeasureSpec即測量規(guī)格，它是一個32位的int值，高2位代表SpecMode，低30位代表SpecSize。并提供了打包和拆包低方法。
測量模式有三種：
UNSPECIFIED
父視圖不對子視圖有任何約束，它可以達到所期望的任意尺寸。
EXACTLY
父視圖為子視圖指定一個確切的尺寸，而且無論子視圖期望多大，它都必須在該指定大小的邊界內(nèi)，對應的屬性為 match_parent 或具體值。
AT_MOST
父視圖為子視圖指定一個最大尺寸。子視圖必須確保它自己所有子視圖可以適應在該尺寸范圍內(nèi)，對應的屬性為 wrap_content ，這種模式下，父控件無法確定子 View 的尺寸，只能由子控件自己根據(jù)需求去計算自己的尺寸。
理解了 MeasureSpec，我們就知道了要確定 DecorView 的大小，最先要做的事情就是要確定 DecorView 的 MeasureSpec。那么 DecorView 的 MeasureSpec 是如何確定的呢？讓我們再回到 performTraversals 這個方法，根據(jù)源碼可以看出，DecorView 的測量時所需要的兩個 MeasureSpec 變量是根據(jù) getRootMeasureSpec 方法得到的。同時，我們可以發(fā)現(xiàn)：DecorView 的 MeasureSpec 是由 windowSize 和 Window.LayoutParams 共同決定的。 具體規(guī)則如下：
private static int getRootMeasureSpec(int windowSize, int rootDimension) {
int measureSpec;
switch (rootDimension) {
case ViewGroup.LayoutParams.MATCH_PARENT:
// Window can't resize. Force root view to be windowSize.
measureSpec = MeasureSpec.makeMeasureSpec(windowSize, MeasureSpec.EXACTLY);
break;
case ViewGroup.LayoutParams.WRAP_CONTENT:
// Window can resize. Set max size for root view.
measureSpec = MeasureSpec.makeMeasureSpec(windowSize, MeasureSpec.AT_MOST);
break;
default:
// Window wants to be an exact size. Force root view to be that size.
measureSpec = MeasureSpec.makeMeasureSpec(rootDimension, MeasureSpec.EXACTLY);
break;
}
return measureSpec;
}
當 window 的 layout_width / layout_height 為 match_parent 時：
DecorView 的 size 即為 windowSize，其 mode 為 EXACTLY。
當 window 的 layout_width / layout_height 為 wrap_parent 時：
DecorView 的 size 是不確定的，但其 size 不能超過 windowSize 的大小，同時其 mode 為 AT_MOST。
當 window 的 layout_width / layout_height 為 default (即確定值)時 ：
DecorView 的 size 即為 Window.LayoutParams 中所指定寬高，同時其 mode 為 EXACTLY。
至此，DecorView 的兩個 MeasureSpec 都已經(jīng)拿到，一切都交由 DecorView 的 measure 方法去處理了。DecorView 是一個 FrameLayout，其 measure 方法繼承的是 View 的 measure 方法，在 View 的 measure 方法中又會去調(diào)用 View 的 onMeasure 方法。而作為一個父 View 其大小在某些情況也與其子 View 有關(guān)，對于不同的 ViewGroup 來說，其 onMeasure 方法的實現(xiàn)也不相同。但在 ViewGroup 中提供了一些通用的測量子 View 的方法：measureChild , measureChildren , measureChildWithMargins。我們選取一個典型來看一下 measureChildWithMargins 這個方法：
protected void measureChildWithMargins(View child,
int parentWidthMeasureSpec, int widthUsed,
int parentHeightMeasureSpec, int heightUsed) {
final MarginLayoutParams lp = (MarginLayoutParams) child.getLayoutParams();
final int childWidthMeasureSpec = getChildMeasureSpec(parentWidthMeasureSpec,
mPaddingLeft + mPaddingRight + lp.leftMargin + lp.rightMargin
+ widthUsed, lp.width);
final int childHeightMeasureSpec = getChildMeasureSpec(parentHeightMeasureSpec,
mPaddingTop + mPaddingBottom + lp.topMargin + lp.bottomMargin
+ heightUsed, lp.height);
child.measure(childWidthMeasureSpec, childHeightMeasureSpec);
}
上述方法會對子元素進行 measure，在調(diào)用子元素的 measure 方法之前會先通過 getChildMeasureSpec 方法來得到子元素的 MeasureSpec 。根據(jù)方法參數(shù)來看，很顯然，子元素的 MeasureSpec 的創(chuàng)建與父容器的 MeasureSpec 和子元素本身的 LayoutParams 有關(guān)，此外與父 View 的 padding 和子 View 的 margin 也有關(guān)。具體情況我們可以看一下 ViewGroup 的 getChildMeasureSpec 方法。
public static int getChildMeasureSpec(int spec, int padding, int childDimension) {
int specMode = MeasureSpec.getMode(spec);
int specSize = MeasureSpec.getSize(spec);
int size = Math.max(0, specSize - padding);
int resultSize = 0;
int resultMode = 0;
switch (specMode) {
// Parent has imposed an exact size on us
case MeasureSpec.EXACTLY:
if (childDimension >= 0) {
resultSize = childDimension;
resultMode = MeasureSpec.EXACTLY;
} else if (childDimension == LayoutParams.MATCH_PARENT) {
// Child wants to be our size. So be it.
resultSize = size;
resultMode = MeasureSpec.EXACTLY;
} else if (childDimension == LayoutParams.WRAP_CONTENT) {
// Child wants to determine its own size. It can't be
// bigger than us.
resultSize = size;
resultMode = MeasureSpec.AT_MOST;
}
break;
// Parent has imposed a maximum size on us
case MeasureSpec.AT_MOST:
if (childDimension >= 0) {
// Child wants a specific size... so be it
resultSize = childDimension;
resultMode = MeasureSpec.EXACTLY;
} else if (childDimension == LayoutParams.MATCH_PARENT) {
// Child wants to be our size, but our size is not fixed.
// Constrain child to not be bigger than us.
resultSize = size;
resultMode = MeasureSpec.AT_MOST;
} else if (childDimension == LayoutParams.WRAP_CONTENT) {
// Child wants to determine its own size. It can't be
// bigger than us.
resultSize = size;
resultMode = MeasureSpec.AT_MOST;
}
break;
// Parent asked to see how big we want to be
case MeasureSpec.UNSPECIFIED:
if (childDimension >= 0) {
// Child wants a specific size... let him have it
resultSize = childDimension;
resultMode = MeasureSpec.EXACTLY;
} else if (childDimension == LayoutParams.MATCH_PARENT) {
// Child wants to be our size... find out how big it should
// be
resultSize = View.sUseZeroUnspecifiedMeasureSpec ? 0 : size;
resultMode = MeasureSpec.UNSPECIFIED;
} else if (childDimension == LayoutParams.WRAP_CONTENT) {
// Child wants to determine its own size.... find out how
// big it should be
resultSize = View.sUseZeroUnspecifiedMeasureSpec ? 0 : size;
resultMode = MeasureSpec.UNSPECIFIED;
}
break;
}
return MeasureSpec.makeMeasureSpec(resultSize, resultMode);
}
上述方法的主要作用是根據(jù)父容器的 MeasureSpec 同時結(jié)合 View 本身的 LayoutParams 來確定子元素的 MeasureSpec。這里簡單的闡述下該方法的邏輯：
當 View 的 layout_width / layout_height 是固定寬高的時候：
不管父容器的 MeasureSpec 是什么，View 的 mode 都是EXACTLY，size 遵循 LayoutParams 中的大小。
當 View 的 layout_width / layout_height 是 match_parent時：
如果父容器的 mode 是 EXACTLY，那么 View 的 mode 為 EXACTLY，size 是父 View 的剩余空間。
如果父容器的 mode 是 AT_MOST，那么 View 的 mode 也為 AT_MOST，size 為父 View 的剩余空間。
當 View 的 layout_width / layout_height 是 wrap_parent時：
無論父容器的 mode 是 EXACTLY 還是 AT_MOST ，View 的 mode 總為 AT_MOST，size 不能超過父 View 的剩余空間。
現(xiàn)在我們終于獲得了子 View 的 MeasureSpec，這個時候 View 就需要開始測量自己本身了。
對于不同的 View 來說，一般都會重寫 onMeasure 方法以便根據(jù)自己本身的內(nèi)容和 MeasureSpec 來測量自己本身的寬高，最后調(diào)用 setMeasuredDimension 方法完成設(shè)置。為了簡明起見，這里我們不妨看一下 View#onMeasure 方法的默認實現(xiàn)：
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
setMeasuredDimension(
getDefaultSize(getSuggestedMinimumWidth(),
widthMeasureSpec),
getDefaultSize(getSuggestedMinimumHeight(),
heightMeasureSpec)
);
}
public static int getDefaultSize(int size, int measureSpec) {
int result = size;
int specMode = MeasureSpec.getMode(measureSpec);
int specSize = MeasureSpec.getSize(measureSpec);
switch (specMode) {
case MeasureSpec.UNSPECIFIED:
result = size;
break;
case MeasureSpec.AT_MOST:
case MeasureSpec.EXACTLY:
result = specSize;
break;
}
return result;
}
getDefaultSize 這個方法很好理解，在 AT_MOST 和 EXACTLY 模式下，getDefaultSize 返回的大小就是 measureSpec 中的 specSize。在 UNSPECIFIED 這中情況下，View 的大小為 getSuggestedMinimunWidth/Height的返回指。我們選取 getSuggestedMinimumWidth 看一下它的源碼：
protected int getSuggestedMinimumWidth() {
return (mBackground == null) ? mMinWidth : max(mMinWidth, mBackground.getMinimumWidth());
}
可見如果設(shè)置了 minWidth 屬性，則為 mMinWidth。如果沒有設(shè)置則跟 View 的 background 有關(guān)。我們再來看一下 Drawable#getMinimumWidth 方法：
public int getMinimumWidth() {
final int intrinsicWidth = getIntrinsicWidth();
return intrinsicWidth > 0 ? intrinsicWidth : 0;
}
可見，getMinimumWidth 返回的就是 Drawable 的原始寬度。當然這是在 Drawable 有原始寬度的情況下，否則就返回0。
小結(jié)
現(xiàn)在我們大致明白了整個 View 繪制流程中的 measure 過程。首先頂級 View —— DecorView 會根據(jù) window.size 和 window.layoutParams 來測量自身，同時作為一個父 View 它還會確定子 View 的 measureSpec 參數(shù)，并將測量的流程傳遞給自己的子 View。接著，對于普通的 View 來講，會根據(jù) onMeasure 方法中具體實現(xiàn)的邏輯，并結(jié)合其父 View 提供的 measureSpec 和 自身的 LayoutParams 這兩個參數(shù)完成自身的測量。最后會調(diào)用 setMeasuredDimension 方法來設(shè)置自身測量后的寬高。
3.View 的 layout 流程
根據(jù)之前的分析可知，View 的 layout 也是從 ViewRootImpl 中的 performTraversals 開始的。最先被調(diào)用的依然是 DecorView 的 layout 方法，那么 DecorView 是如何確定自己的位置的？在 ViewRootImpl#performTraversals 方法中，直接調(diào)用了 DecorView 的 layout 方法：
mView.layout(0, 0, mView.getMeasuredWidth(), mView.getMeasuredHeight());
這個里的 getMeasuredWidth / getMeasuredHeight 獲取的正是在 measure 過程中測量后的寬高。我們再來看看 DecorView#layout 方法，由于 DecorView 繼承自 ViewGroup ，DecorView#layout 方法也即是 ViewGroup#layout 方法：
@Override
public final void layout(int l, int t, int r, int b) {
if (!mSuppressLayout && (mTransition == null || !mTransition.isChangingLayout())) {
if (mTransition != null) {
mTransition.layoutChange(this);
}
super.layout(l, t, r, b);
} else {
// record the fact that we noop'd it; request layout when transition finishes
mLayoutCalledWhileSuppressed = true;
}
}
可見ViewGroup#layout 方法又調(diào)用 View#layout 方法，而 View#layout 方法的具體實現(xiàn)如下：
public void layout(int l, int t, int r, int b) {
if ((mPrivateFlags3 & PFLAG3_MEASURE_NEEDED_BEFORE_LAYOUT) != 0) {
onMeasure(mOldWidthMeasureSpec, mOldHeightMeasureSpec);
mPrivateFlags3 &= ~PFLAG3_MEASURE_NEEDED_BEFORE_LAYOUT;
}
int oldL = mLeft;
int oldT = mTop;
int oldB = mBottom;
int oldR = mRight;
boolean changed = isLayoutModeOptical(mParent) ?
setOpticalFrame(l, t, r, b) : setFrame(l, t, r, b);
if (changed || (mPrivateFlags & PFLAG_LAYOUT_REQUIRED) == PFLAG_LAYOUT_REQUIRED) {
onLayout(changed, l, t, r, b);
mPrivateFlags &= ~PFLAG_LAYOUT_REQUIRED;
ListenerInfo li = mListenerInfo;
if (li != null && li.mOnLayoutChangeListeners != null) {
ArrayList<OnLayoutChangeListener> listenersCopy =
(ArrayList<OnLayoutChangeListener>)li.mOnLayoutChangeListeners.clone();
int numListeners = listenersCopy.size();
for (int i = 0; i < numListeners; ++i) {
listenersCopy.get(i).onLayoutChange(this, l, t, r, b, oldL, oldT, oldR, oldB);
}
}
}
mPrivateFlags &= ~PFLAG_FORCE_LAYOUT;
mPrivateFlags3 |= PFLAG3_IS_LAID_OUT;
}
整個 layout 方法會通過 setFrame 方法來設(shè)定 View 的四個頂點的位置，也即是 View 在父容器中的位置。在這里，對于 DecorView 來講，其左上角的坐標為(0,0)，而其右下角的坐標則有其在 measure 過程中所確定的寬高來決定。
回到 View#setFrame 方法中，有這樣幾條語句：
mLeft = left;
mTop = top;
mRight = right;
mBottom = bottom;
上面說到，在 layout 方法中我們確定了 View 的四個定點。根據(jù)這四個頂點我們很容易計算出 View 的寬高:
public final int getWidth() {
return mRight - mLeft;
}
public final int getHeight() {
return mBottom - mTop;
}
看到這，可能就會有疑問：View 的寬高不是在 measure 過程中就已經(jīng)確定了的嗎？這里獲得的寬高又是什么呢？或者說 getWidth / getHeight 和 getMeasuredWidth / getMeasuredHeight 有什么區(qū)別？
在一般情況下，View 的實際寬高和測量寬高是相等的，只不過這兩者的形成時機不同。View 的測量寬高實在 View 的 measure 過程中確定的，而 View 的實際寬高是在 View 的 layout 過程中確定的。
在確定好自己的位置之后，同時作為一個父 View 的 DecorView 就會調(diào)用 onLayout 方法去布置自己的子 View 了。不同的 ViewGroup 其 onLayout 方法的實現(xiàn)也不同。這里我們來看看 DecorView ，即 FrameLayout 的具體實現(xiàn)。在 FrameLayout#onLayout 中，調(diào)用了 layoutChildren 方法：
@Override
protected void onLayout(boolean changed, int left, int top, int right, int bottom) {
layoutChildren(left, top, right, bottom, false /* no force left gravity */);
}
再來看看 FrameLayout#layoutChildren 這個方法：
void layoutChildren(int left, int top, int right, int bottom,
boolean forceLeftGravity) {
final int count = getChildCount();
final int parentLeft = getPaddingLeftWithForeground();
final int parentRight = right - left - getPaddingRightWithForeground();
final int parentTop = getPaddingTopWithForeground();
final int parentBottom = bottom - top - getPaddingBottomWithForeground();
for (int i = 0; i < count; i++) {
final View child = getChildAt(i);
if (child.getVisibility() != GONE) {
final LayoutParams lp = (LayoutParams) child.getLayoutParams();
final int width = child.getMeasuredWidth();
final int height = child.getMeasuredHeight();
int childLeft;
int childTop;
int gravity = lp.gravity;
if (gravity == -1) {
gravity = DEFAULT_CHILD_GRAVITY;
}
final int layoutDirection = getLayoutDirection();
final int absoluteGravity = Gravity.getAbsoluteGravity(gravity, layoutDirection);
final int verticalGravity = gravity & Gravity.VERTICAL_GRAVITY_MASK;
switch (absoluteGravity & Gravity.HORIZONTAL_GRAVITY_MASK) {
case Gravity.CENTER_HORIZONTAL:
childLeft = parentLeft + (parentRight - parentLeft - width) / 2 +
lp.leftMargin - lp.rightMargin;
break;
case Gravity.RIGHT:
if (!forceLeftGravity) {
childLeft = parentRight - width - lp.rightMargin;
break;
}
case Gravity.LEFT:
default:
childLeft = parentLeft + lp.leftMargin;
}
switch (verticalGravity) {
case Gravity.TOP:
childTop = parentTop + lp.topMargin;
break;
case Gravity.CENTER_VERTICAL:
childTop = parentTop + (parentBottom - parentTop - height) / 2 +
lp.topMargin - lp.bottomMargin;
break;
case Gravity.BOTTOM:
childTop = parentBottom - height - lp.bottomMargin;
break;
default:
childTop = parentTop + lp.topMargin;
}
child.layout(childLeft, childTop, childLeft + width, childTop + height);
}
}
}
這里簡單分析下 layoutChildren 的代碼邏輯：
首先5～9行確定了父容器的邊界，接著遍歷所有的子元素，根據(jù)子元素的 Gravity 屬性的不同來計算子元素左上角的位置即 childLeft 和 childTop 的值。最后，由于在之前的 measure 方法中我們已經(jīng)確定了子元素的寬高，所以每個子元素所在的矩形區(qū)域也就相應的確定了。這里只需要調(diào)用子元素的 layout 方法，來確定子元素的位置，并將 layout 流程傳遞下去即可。
小結(jié)
到這里，View 的 layout 過程就完成了。layout 過程的作用是 ViewGroup 用來確定子元素的位置的。整個過程也是從 DecorView 開始的，DecorView 會根據(jù)自己在 measure 過程中計算出的 MeasuredWidth 和 MeasuredHeight 來確定自己的位置。同時 DecorView 作為一個 ViewGroup 也會負責去確定自己的子元素的位置，并將 layout 的流程傳遞下去。
3.View 的 Draw 流程
最后只剩下 View 的繪制過程了，整個過程比較簡單。我們依然從 DecorView 開始分析。由于 ViewGroup 并沒有重寫 view#draw 方法，因此我們直接來看 view#draw 的原理
public void draw(Canvas canvas) {
/ * Draw traversal performs several drawing steps which must be executed
* in the appropriate order:
*
* 1. Draw the background if need
* 2. If necessary, save the canvas' layers to prepare for fading
* 3. Draw view's content
* 4. Draw children (dispatchDraw)
* 5. If necessary, draw the fading edges and restore layers
* 6. Draw decorations (scrollbars for instance)
*/
// Step 1, draw the background, if needed
if (!dirtyOpaque) {
drawBackground(canvas);
}
// skip step 2 & 5 if possible (common case)
final int viewFlags = mViewFlags;
if (!verticalEdges && !horizontalEdges) {
// Step 3, draw the content
if (!dirtyOpaque) onDraw(canvas);
// Step 4, draw the children
dispatchDraw(canvas);
// Step 6, draw decorations (scrollbars)
onDrawScrollBars(canvas);
if (mOverlay != null && !mOverlay.isEmpty()) {
mOverlay.getOverlayView().dispatchDraw(canvas);
}
// we're done...
return;
}
// Step 2, save the canvas' layers
...
// Step 3, draw the content
if (!dirtyOpaque)
onDraw(canvas);
// Step 4, draw the children
dispatchDraw(canvas);
// Step 5, draw the fade effect and restore layers
// Step 6, draw decorations (scrollbars)
onDrawScrollBars(canvas);
}
注釋寫的如此詳細，看來有必要為之配圖了：
這里我們再來看看 dispatchDraw 這個方法它是如何將 View 的繪制過程傳遞下去的。顯然對于普通的 View 來講，它只需要繪制好自身就可以了，因此 View#dispatchDraw 方法的實現(xiàn)為空。而作為 ViewGroup 在繪制自身的同時還需要將繪制流程傳遞給子元素。期中涉及到的相關(guān)方法如下：
dispatchDraw(Canvas canvas){
...
if ((flags & FLAG_RUN_ANIMATION) != 0 && canAnimate()) {
final boolean buildCache = !isHardwareAccelerated();
for (int i = 0; i < childrenCount; i++) {
final View child = children[i];
if ((child.mViewFlags & VISIBILITY_MASK) == VISIBLE) {
final LayoutParams params = child.getLayoutParams();
attachLayoutAnimationParameters(child, params, i, childrenCount);
bindLayoutAnimation(child);
if (cache) {
child.setDrawingCacheEnabled(true);
if (buildCache) {
child.buildDrawingCache(true);
}
}
}
}
final LayoutAnimationController controller = mLayoutAnimationController;
if (controller.willOverlap()) {
mGroupFlags |= FLAG_OPTIMIZE_INVALIDATE;
}
controller.start();
}
//draw children
for (int i = 0; i < childrenCount; i++) {
int childIndex = customOrder ? getChildDrawingOrder(childrenCount, i) : i;
final View child = (preorderedList == null)
? children[childIndex] : preorderedList.get(childIndex);
if ((child.mViewFlags & VISIBILITY_MASK) == VISIBLE || child.getAnimation() != null) {
more |= drawChild(canvas, child, drawingTime);
}
}
...
}
protected boolean drawChild(Canvas canvas, View child, long drawingTime) {
return child.draw(canvas, this, drawingTime);
}
通過上面的源碼我們也可以知道，在我們自定義 View 的時候，一般只需要去重寫 View#onDraw 方法來繪制 View 的具體內(nèi)容就可以了。而 View#draw 這個方法還幫我們做了很多其它的事情。
4.總結(jié)
Measure 過程
自上而下遍歷，DecorView 根據(jù) window.size 和 window.LayoutParams 這兩個參數(shù)先確定自身的 MeasureSpec。同時作一個父 View 它會根據(jù)自身的 MeasureSpec 和子 View 的 LayoutParams 獲取 ChildView 的 MeasureSpec，回調(diào) ChildView.measure 方法，最終調(diào)用 setMeasuredDimension 得到 ChildView 的尺寸：mMeasuredWidth 和 mMeasuredHeight
Layout 過程
自上而下遍歷，根據(jù) Measure 過程中得到的每個 View 的 mMeasuredWidth 和 mMeasuredHeight 與計算得到的每個 ChildView 的 ChildLeft,ChildTop 進行布局：child.layout(left,top,left + width,top + height);
Draw 過程
自上而下遍歷，父 View 除了繪制自身外，還需要將整個繪制過程傳遞給自己的子元素。
最后，整個 View 的繪制流程我們總結(jié)為如下一張流程圖，需要說明的是，用戶主動調(diào)用 request，只會出發(fā) measure 和 layout 過程，而不會執(zhí)行 draw 過程。
