標(biāo)簽： Android 源碼解析 View
關(guān)于View的繪制流程雄右，或者說 View 的工作流程（說繪制流程容易讓人誤解成 View 的 draw 流程）自己也在網(wǎng)上看過不少好文渐扮。但每當(dāng)被問到具體的問題的時(shí)候，總感覺有很多知識還是模棱兩可酥馍。因此本篇博客主要是用來梳理和總結(jié)相關(guān)知識逗鸣。如果你也對View的繪制流程似懂非懂贞让，不妨順著我的思路看下去分冈，希望你會有所收獲棍鳖。當(dāng)然，任何不足续镇、不當(dāng)之處也請告訴我～
1.View 繪制流程的開始
當(dāng)我們打開一個(gè) Activity岂丘，呈現(xiàn)在我們面前的就已經(jīng)是繪制好了的 View 了陵究。在我們梳理 View 的繪制流程之前，不妨先思考一個(gè)問題：View是從什么時(shí)候／哪里開始被繪制的奥帘？
預(yù)備知識：
1.1 關(guān)于DecorView
DecorView 繼承 FrameLayout铜邮，一般情況下包含一個(gè) LinearLayout。而這個(gè) LinearLayout 又包含一個(gè) id 為 android.R.id.content 的 ViewGroup 和 一個(gè)titlebar (跟主題相關(guān)寨蹋，也可能沒有)松蒜。DecorView 也被稱作頂級 View，也因此它是最先被繪制的已旧。
1.2 關(guān)于ViewRootImpl
*注：這里涉及到的和 Window 及 WindowManager 相關(guān)知識不作過多解釋秸苗。
ViewRootImpl 顧名思義，它是所有 View 的根运褪，即整個(gè) View 樹的根節(jié)點(diǎn)惊楼。同時(shí)它也是連接WindowManager 和 DecorView 的紐帶玖瘸。但需要注意的是 ViewRootImpl 本身并不是一個(gè) View 。有了這兩點(diǎn)知識檀咙，我們可以回答最開始的問題了：View 的繪制流程是從 ViewRootImpl#performTravels 方法開始的雅倒。這個(gè)方法在 ActivityThread 被執(zhí)行。performTravels 方法主要包含 measure,layout,draw 這三個(gè)過程弧可。一般情況下這里的變量 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 過程
預(yù)備知識
2.1 關(guān)于MeasureSpec
MeasureSpec即測量規(guī)格丸相，它是一個(gè)32位的int值搔确，高2位代表SpecMode，低30位代表SpecSize灭忠。并提供了打包和拆包低方法膳算。
測量模式有三種：
UNSPECIFIED
父視圖不對子視圖有任何約束，它可以達(dá)到所期望的任意尺寸弛作。
EXACTLY
父視圖為子視圖指定一個(gè)確切的尺寸涕蜂，而且無論子視圖期望多大，它都必須在該指定大小的邊界內(nèi)映琳，對應(yīng)的屬性為 match_parent 或具體值机隙。
AT_MOST
父視圖為子視圖指定一個(gè)最大尺寸。子視圖必須確保它自己所有子視圖可以適應(yīng)在該尺寸范圍內(nèi)萨西，對應(yīng)的屬性為 wrap_content 有鹿，這種模式下，父控件無法確定子 View 的尺寸谎脯，只能由子控件自己根據(jù)需求去計(jì)算自己的尺寸葱跋。
理解了 MeasureSpec，我們就知道了要確定 DecorView 的大小源梭，最先要做的事情就是要確定 DecorView 的 MeasureSpec娱俺。那么 DecorView 的 MeasureSpec 是如何確定的呢？讓我們再回到 performTraversals 這個(gè)方法废麻，根據(jù)源碼可以看出荠卷，DecorView 的測量時(shí)所需要的兩個(gè) MeasureSpec 變量是根據(jù) getRootMeasureSpec 方法得到的。同時(shí)脑溢，我們可以發(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;
}
當(dāng) window 的 layout_width / layout_height 為 match_parent 時(shí)：
DecorView 的 size 即為 windowSize赖欣，其 mode 為 EXACTLY。
當(dāng) window 的 layout_width / layout_height 為 wrap_parent 時(shí)：
DecorView 的 size 是不確定的验庙，但其 size 不能超過 windowSize 的大小顶吮，同時(shí)其 mode 為 AT_MOST。
當(dāng) window 的 layout_width / layout_height 為 default (即確定值)時(shí) ：
DecorView 的 size 即為 Window.LayoutParams 中所指定寬高粪薛，同時(shí)其 mode 為 EXACTLY悴了。
至此，DecorView 的兩個(gè) MeasureSpec 都已經(jīng)拿到违寿，一切都交由 DecorView 的 measure 方法去處理了湃交。DecorView 是一個(gè) FrameLayout，其 measure 方法繼承的是 View 的 measure 方法藤巢，在 View 的 measure 方法中又會去調(diào)用 View 的 onMeasure 方法搞莺。而作為一個(gè)父 View 其大小在某些情況也與其子 View 有關(guān)，對于不同的 ViewGroup 來說掂咒，其 onMeasure 方法的實(shí)現(xiàn)也不相同才沧。但在 ViewGroup 中提供了一些通用的測量子 View 的方法：measureChild , measureChildren , measureChildWithMargins。我們選取一個(gè)典型來看一下 measureChildWithMargins 這個(gè)方法：
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);
}
上述方法會對子元素進(jìn)行 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 同時(shí)結(jié)合 View 本身的 LayoutParams 來確定子元素的 MeasureSpec锅移。這里簡單的闡述下該方法的邏輯：
當(dāng) View 的 layout_width / layout_height 是固定寬高的時(shí)候：
不管父容器的 MeasureSpec 是什么，View 的 mode 都是EXACTLY彬檀，size 遵循 LayoutParams 中的大小帆啃。
當(dāng) View 的 layout_width / layout_height 是 match_parent時(shí)：
如果父容器的 mode 是 EXACTLY，那么 View 的 mode 為 EXACTLY窍帝，size 是父 View 的剩余空間努潘。
如果父容器的 mode 是 AT_MOST，那么 View 的 mode 也為 AT_MOST坤学，size 為父 View 的剩余空間疯坤。
當(dāng) View 的 layout_width / layout_height 是 wrap_parent時(shí)：
無論父容器的 mode 是 EXACTLY 還是 AT_MOST ，View 的 mode 總為 AT_MOST深浮，size 不能超過父 View 的剩余空間压怠。
現(xiàn)在我們終于獲得了子 View 的 MeasureSpec，這個(gè)時(shí)候 View 就需要開始測量自己本身了飞苇。
對于不同的 View 來說菌瘫，一般都會重寫 onMeasure 方法以便根據(jù)自己本身的內(nèi)容和 MeasureSpec 來測量自己本身的寬高蜗顽，最后調(diào)用 setMeasuredDimension 方法完成設(shè)置。為了簡明起見雨让，這里我們不妨看一下 View#onMeasure 方法的默認(rèn)實(shí)現(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 這個(gè)方法很好理解雇盖，在 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 的原始寬度脓鹃。當(dāng)然這是在 Drawable 有原始寬度的情況下，否則就返回0属拾。
小結(jié)
現(xiàn)在我們大致明白了整個(gè) View 繪制流程中的 measure 過程将谊。首先頂級 View —— DecorView 會根據(jù) window.size 和 window.layoutParams 來測量自身，同時(shí)作為一個(gè)父 View 它還會確定子 View 的 measureSpec 參數(shù)渐白，并將測量的流程傳遞給自己的子 View。接著逞频，對于普通的 View 來講纯衍，會根據(jù) onMeasure 方法中具體實(shí)現(xiàn)的邏輯，并結(jié)合其父 View 提供的 measureSpec 和 自身的 LayoutParams 這兩個(gè)參數(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());
這個(gè)里的 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 方法的具體實(shí)現(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;
}
整個(gè) layout 方法會通過 setFrame 方法來設(shè)定 View 的四個(gè)頂點(diǎn)的位置，也即是 View 在父容器中的位置耐量。在這里飞蚓，對于 DecorView 來講，其左上角的坐標(biāo)為(0,0)廊蜒，而其右下角的坐標(biāo)則有其在 measure 過程中所確定的寬高來決定趴拧。
回到 View#setFrame 方法中溅漾，有這樣幾條語句：
mLeft = left;
mTop = top;
mRight = right;
mBottom = bottom;
上面說到，在 layout 方法中我們確定了 View 的四個(gè)定點(diǎn)著榴。根據(jù)這四個(gè)頂點(diǎn)我們很容易計(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 的實(shí)際寬高和測量寬高是相等的挂谍，只不過這兩者的形成時(shí)機(jī)不同叔壤。View 的測量寬高實(shí)在 View 的 measure 過程中確定的，而 View 的實(shí)際寬高是在 View 的 layout 過程中確定的口叙。
在確定好自己的位置之后炼绘，同時(shí)作為一個(gè)父 View 的 DecorView 就會調(diào)用 onLayout 方法去布置自己的子 View 了。不同的 ViewGroup 其 onLayout 方法的實(shí)現(xiàn)也不同妄田。這里我們來看看 DecorView 俺亮，即 FrameLayout 的具體實(shí)現(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 這個(gè)方法：
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 屬性的不同來計(jì)算子元素左上角的位置即 childLeft 和 childTop 的值启具。最后本讥，由于在之前的 measure 方法中我們已經(jīng)確定了子元素的寬高，所以每個(gè)子元素所在的矩形區(qū)域也就相應(yīng)的確定了鲁冯。這里只需要調(diào)用子元素的 layout 方法拷沸，來確定子元素的位置，并將 layout 流程傳遞下去即可薯演。
小結(jié)
到這里撞芍，View 的 layout 過程就完成了。layout 過程的作用是 ViewGroup 用來確定子元素的位置的跨扮。整個(gè)過程也是從 DecorView 開始的序无，DecorView 會根據(jù)自己在 measure 過程中計(jì)算出的 MeasuredWidth 和 MeasuredHeight 來確定自己的位置。同時(shí) DecorView 作為一個(gè) ViewGroup 也會負(fù)責(zé)去確定自己的子元素的位置好港，并將 layout 的流程傳遞下去愉镰。
3.View 的 Draw 流程
最后只剩下 View 的繪制過程了，整個(gè)過程比較簡單钧汹。我們依然從 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);
}
注釋寫的如此詳細(xì)拔莱，看來有必要為之配圖了：
這里我們再來看看 dispatchDraw 這個(gè)方法它是如何將 View 的繪制過程傳遞下去的碗降。顯然對于普通的 View 來講隘竭，它只需要繪制好自身就可以了，因此 View#dispatchDraw 方法的實(shí)現(xiàn)為空讼渊。而作為 ViewGroup 在繪制自身的同時(shí)還需要將繪制流程傳遞給子元素动看。期中涉及到的相關(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 的時(shí)候爪幻，一般只需要去重寫 View#onDraw 方法來繪制 View 的具體內(nèi)容就可以了菱皆。而 View#draw 這個(gè)方法還幫我們做了很多其它的事情。
4.總結(jié)
Measure 過程
自上而下遍歷挨稿，DecorView 根據(jù) window.size 和 window.LayoutParams 這兩個(gè)參數(shù)先確定自身的 MeasureSpec仇轻。同時(shí)作一個(gè)父 View 它會根據(jù)自身的 MeasureSpec 和子 View 的 LayoutParams 獲取 ChildView 的 MeasureSpec，回調(diào) ChildView.measure 方法奶甘，最終調(diào)用 setMeasuredDimension 得到 ChildView 的尺寸：mMeasuredWidth 和 mMeasuredHeight
Layout 過程
自上而下遍歷篷店，根據(jù) Measure 過程中得到的每個(gè) View 的 mMeasuredWidth 和 mMeasuredHeight 與計(jì)算得到的每個(gè) ChildView 的 ChildLeft,ChildTop 進(jìn)行布局：child.layout(left,top,left + width,top + height);
Draw 過程
自上而下遍歷，父 View 除了繪制自身外臭家，還需要將整個(gè)繪制過程傳遞給自己的子元素疲陕。
最后，整個(gè) View 的繪制流程我們總結(jié)為如下一張流程圖钉赁，需要說明的是蹄殃，用戶主動調(diào)用 request，只會出發(fā) measure 和 layout 過程你踩，而不會執(zhí)行 draw 過程窃爷。
