前言
Activity中界面加載顯示的基本流程原理，最終分析結(jié)果就是下面的關(guān)系：
看見(jiàn)沒(méi)有，如上圖中id為content的內(nèi)容就是整個(gè)View樹(shù)的結(jié)構(gòu)，所以對(duì)每個(gè)具體View對(duì)象的操作，其實(shí)就是個(gè)遞歸的實(shí)現(xiàn)。
Android中的任何一個(gè)布局、任何一個(gè)控件其實(shí)都是直接或間接繼承自View實(shí)現(xiàn)的，當(dāng)然也包括我們后面一步一步引出的自定義控件也不例外，所以說(shuō)這些View應(yīng)該都具有相同的繪制流程與機(jī)制才能顯示到屏幕上（因?yàn)樗麄兌季邆湎嗤母割?lèi)View，可能每個(gè)控件的具體繪制邏輯有差異，但是主流程都是一樣的）。經(jīng)過(guò)總結(jié)發(fā)現(xiàn)每一個(gè)View的繪制過(guò)程都必須經(jīng)歷三個(gè)最主要的過(guò)程，也就是measure、layout和draw。
既然一個(gè)View的繪制主要流程是這三步，那一定有一個(gè)開(kāi)始地方呀，就像一個(gè)類(lèi)從main函數(shù)執(zhí)行一樣呀。對(duì)于View的繪制開(kāi)始調(diào)運(yùn)地方這里先給出結(jié)論，本文后面會(huì)反過(guò)來(lái)分析原因的，先往下看就行。具體結(jié)論如下：
整個(gè)View樹(shù)的繪圖流程是在ViewRootImpl類(lèi)的performTraversals()方法（這個(gè)方法巨長(zhǎng)）開(kāi)始的，該函數(shù)做的執(zhí)行過(guò)程主要是根據(jù)之前設(shè)置的狀態(tài)，判斷是否重新計(jì)算視圖大小(measure)、是否重新放置視圖的位置(layout)、以及是否重繪 (draw)，其核心也就是通過(guò)判斷來(lái)選擇順序執(zhí)行這三個(gè)方法中的哪個(gè)，如下：
private void performTraversals() {
......
//最外層的根視圖的widthMeasureSpec和heightMeasureSpec由來(lái)
//lp.width和lp.height在創(chuàng)建ViewGroup實(shí)例時(shí)等于MATCH_PARENT
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);
......
}
/**
* Figures out the measure spec for the root view in a window based on it's
* layout params.
*
* @param windowSize
* The available width or height of the window
*
* @param rootDimension
* The layout params for one dimension (width or height) of the
* window.
*
* @return The measure spec to use to measure the root view.
*/
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;
......
}
return measureSpec;
}
可以看見(jiàn)這個(gè)方法的注釋說(shuō)是用來(lái)測(cè)Root View的。上面?zhèn)魅雲(yún)?shù)后這個(gè)函數(shù)走的是MATCH_PARENT，使用MeasureSpec.makeMeasureSpec方法組裝一個(gè)MeasureSpec，MeasureSpec的specMode等于EXACTLY，specSize等于windowSize，也就是為何根視圖總是全屏的原因。
其中的mView就是View對(duì)象。如下就是整個(gè)流程的大致流程圖：
如下我們就依據(jù)View繪制的這三個(gè)主要流程進(jìn)行詳細(xì)剖析
遞歸measure源碼解析
先看下View的measure方法源碼，如下：
/**
* <p>
* This is called to find out how big a view should be. The parent
* supplies constraint information in the width and height parameters.
* </p>
*
* <p>
* The actual measurement work of a view is performed in
* {@link #onMeasure(int, int)}, called by this method. Therefore, only
* {@link #onMeasure(int, int)} can and must be overridden by subclasses.
* </p>
*
*
* @param widthMeasureSpec Horizontal space requirements as imposed by the
* parent
* @param heightMeasureSpec Vertical space requirements as imposed by the
* parent
*
* @see #onMeasure(int, int)
*/
//final方法，子類(lèi)不可重寫(xiě)
public final void measure(int widthMeasureSpec, int heightMeasureSpec) {
......
//回調(diào)onMeasure()方法
onMeasure(widthMeasureSpec, heightMeasureSpec);
......
}
看見(jiàn)注釋信息沒(méi)有，他告訴你了很多重要信息。為整個(gè)View樹(shù)計(jì)算實(shí)際的大小，然后設(shè)置實(shí)際的高和寬，每個(gè)View控件的實(shí)際寬高都是由父視圖和自身決定的。實(shí)際的測(cè)量是在onMeasure方法進(jìn)行，所以在View的子類(lèi)需要重寫(xiě)onMeasure方法，這是因?yàn)閙easure方法是final的，不允許重載，所以View子類(lèi)只能通過(guò)重載onMeasure來(lái)實(shí)現(xiàn)自己的測(cè)量邏輯。
這個(gè)方法的兩個(gè)參數(shù)都是父View傳遞過(guò)來(lái)的，也就是代表了父view的規(guī)格。他由兩部分組成，高2位表示MODE，定義在MeasureSpec類(lèi)（View的內(nèi)部類(lèi)）中，有三種類(lèi)型，MeasureSpec.EXACTLY表示確定大小， MeasureSpec.AT_MOST表示最大大小， MeasureSpec.UNSPECIFIED不確定。低30位表示size，也就是父View的大小。對(duì)于系統(tǒng)Window類(lèi)的DecorVIew對(duì)象Mode一般都為MeasureSpec.EXACTLY ，而size分別對(duì)應(yīng)屏幕寬高。對(duì)于子View來(lái)說(shuō)大小是由父View和子View共同決定的。
在這里可以看出measure方法最終回調(diào)了View的onMeasure方法，我們來(lái)看下View的onMeasure源碼，如下：
/**
* <p>
* Measure the view and its content to determine the measured width and the
* measured height. This method is invoked by {@link #measure(int, int)} and
* should be overriden by subclasses to provide accurate and efficient
* measurement of their contents.
* </p>
*
* <p>
* <strong>CONTRACT:</strong> When overriding this method, you
* <em>must</em> call {@link #setMeasuredDimension(int, int)} to store the
* measured width and height of this view. Failure to do so will trigger an
* <code>IllegalStateException</code>, thrown by
* {@link #measure(int, int)}. Calling the superclass'
* {@link #onMeasure(int, int)} is a valid use.
* </p>
*
* <p>
* The base class implementation of measure defaults to the background size,
* unless a larger size is allowed by the MeasureSpec. Subclasses should
* override {@link #onMeasure(int, int)} to provide better measurements of
* their content.
* </p>
*
* <p>
* If this method is overridden, it is the subclass's responsibility to make
* sure the measured height and width are at least the view's minimum height
* and width ({@link #getSuggestedMinimumHeight()} and
* {@link #getSuggestedMinimumWidth()}).
* </p>
*
* @param widthMeasureSpec horizontal space requirements as imposed by the parent.
* The requirements are encoded with
* {@link android.view.View.MeasureSpec}.
* @param heightMeasureSpec vertical space requirements as imposed by the parent.
* The requirements are encoded with
* {@link android.view.View.MeasureSpec}.
*
* @see #getMeasuredWidth()
* @see #getMeasuredHeight()
* @see #setMeasuredDimension(int, int)
* @see #getSuggestedMinimumHeight()
* @see #getSuggestedMinimumWidth()
* @see android.view.View.MeasureSpec#getMode(int)
* @see android.view.View.MeasureSpec#getSize(int)
*/
//View的onMeasure默認(rèn)實(shí)現(xiàn)方法
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
setMeasuredDimension(getDefaultSize(getSuggestedMinimumWidth(), widthMeasureSpec),
getDefaultSize(getSuggestedMinimumHeight(), heightMeasureSpec));
}
看見(jiàn)沒(méi)有，其實(shí)注釋已經(jīng)很詳細(xì)了（自定義View重寫(xiě)該方法的指導(dǎo)操作注釋都有說(shuō)明），不做過(guò)多解釋。
對(duì)于非ViewGroup的View而言，通過(guò)調(diào)用上面默認(rèn)的onMeasure即可完成View的測(cè)量，當(dāng)然你也可以重載onMeasure并調(diào)用setMeasuredDimension來(lái)設(shè)置任意大小的布局，但一般不這么做，因?yàn)檫@種做法不太好，至于為何不好，后面分析完你就明白了。
我們可以看見(jiàn)onMeasure默認(rèn)的實(shí)現(xiàn)僅僅調(diào)用了setMeasuredDimension，setMeasuredDimension函數(shù)是一個(gè)很關(guān)鍵的函數(shù)，它對(duì)View的成員變量mMeasuredWidth和mMeasuredHeight變量賦值，measure的主要目的就是對(duì)View樹(shù)中的每個(gè)View的mMeasuredWidth和mMeasuredHeight進(jìn)行賦值，所以一旦這兩個(gè)變量被賦值意味著該View的測(cè)量工作結(jié)束。既然這樣那我們就看看設(shè)置的默認(rèn)尺寸大小吧，可以看見(jiàn)setMeasuredDimension傳入的參數(shù)都是通過(guò)getDefaultSize返回的，所以再來(lái)看下getDefaultSize方法源碼，如下：
public static int getDefaultSize(int size, int measureSpec) {
int result = size;
//通過(guò)MeasureSpec解析獲取mode與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;
}
看見(jiàn)沒(méi)有，如果specMode等于AT_MOST或EXACTLY就返回specSize，這就是系統(tǒng)默認(rèn)的規(guī)格。
回過(guò)頭繼續(xù)看上面onMeasure方法，其中g(shù)etDefaultSize參數(shù)的widthMeasureSpec和heightMeasureSpec都是由父View傳遞進(jìn)來(lái)的。getSuggestedMinimumWidth與getSuggestedMinimumHeight都是View的方法，具體如下：
protected int getSuggestedMinimumWidth() {
return (mBackground == null) ? mMinWidth : max(mMinWidth, mBackground.getMinimumWidth());
}
protected int getSuggestedMinimumHeight() {
return (mBackground == null) ? mMinHeight : max(mMinHeight, mBackground.getMinimumHeight());
}
看見(jiàn)沒(méi)有，建議的最小寬度和高度都是由View的Background尺寸與通過(guò)設(shè)置View的miniXXX屬性共同決定的。
到此一次最基礎(chǔ)的元素View的measure過(guò)程就完成了。上面說(shuō)了View實(shí)際是嵌套的，而且measure是遞歸傳遞的，所以每個(gè)View都需要measure。實(shí)際能夠嵌套的View一般都是ViewGroup的子類(lèi)，所以在ViewGroup中定義了measureChildren, measureChild, measureChildWithMargins方法來(lái)對(duì)子視圖進(jìn)行測(cè)量，measureChildren內(nèi)部實(shí)質(zhì)只是循環(huán)調(diào)用measureChild，measureChild和measureChildWithMargins的區(qū)別就是是否把margin和padding也作為子視圖的大小。如下我們以ViewGroup中稍微復(fù)雜的measureChildWithMargins方法來(lái)分析：
/**
* Ask one of the children of this view to measure itself, taking into
* account both the MeasureSpec requirements for this view and its padding
* and margins. The child must have MarginLayoutParams The heavy lifting is
* done in getChildMeasureSpec.
*
* @param child The child to measure
* @param parentWidthMeasureSpec The width requirements for this view
* @param widthUsed Extra space that has been used up by the parent
* horizontally (possibly by other children of the parent)
* @param parentHeightMeasureSpec The height requirements for this view
* @param heightUsed Extra space that has been used up by the parent
* vertically (possibly by other children of the parent)
*/
protected void measureChildWithMargins(View child,
int parentWidthMeasureSpec, int widthUsed,
int parentHeightMeasureSpec, int heightUsed) {
//獲取子視圖的LayoutParams
final MarginLayoutParams lp = (MarginLayoutParams) child.getLayoutParams();
//調(diào)整MeasureSpec
//通過(guò)這兩個(gè)參數(shù)以及子視圖本身的LayoutParams來(lái)共同決定子視圖的測(cè)量規(guī)格
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);
//調(diào)運(yùn)子View的measure方法，子View的measure中會(huì)回調(diào)子View的onMeasure方法
child.measure(childWidthMeasureSpec, childHeightMeasureSpec);
}
關(guān)于該方法的參數(shù)等說(shuō)明注釋已經(jīng)描述的夠清楚了。該方法就是對(duì)父視圖提供的measureSpec參數(shù)結(jié)合自身的LayoutParams參數(shù)進(jìn)行了調(diào)整，然后再來(lái)調(diào)用child.measure()方法，具體通過(guò)方法getChildMeasureSpec來(lái)進(jìn)行參數(shù)調(diào)整。所以我們繼續(xù)看下getChildMeasureSpec方法代碼，如下：
public static int getChildMeasureSpec(int spec, int padding, int childDimension) {
//獲取當(dāng)前Parent View的Mode和Size
int specMode = MeasureSpec.getMode(spec);
int specSize = MeasureSpec.getSize(spec);
//獲取Parent size與padding差值（也就是Parent剩余大?。舨钪敌∮?直接返回0
int size = Math.max(0, specSize - padding);
//定義返回值存儲(chǔ)變量
int resultSize = 0;
int resultMode = 0;
//依據(jù)當(dāng)前Parent的Mode進(jìn)行switch分支邏輯
switch (specMode) {
// Parent has imposed an exact size on us
//默認(rèn)Root View的Mode就是EXACTLY
case MeasureSpec.EXACTLY:
if (childDimension >= 0) {
//如果child的layout_wOrh屬性在xml或者java中給予具體大于等于0的數(shù)值
//設(shè)置child的size為真實(shí)layout_wOrh屬性值，mode為EXACTLY
resultSize = childDimension;
resultMode = MeasureSpec.EXACTLY;
} else if (childDimension == LayoutParams.MATCH_PARENT) {
//如果child的layout_wOrh屬性在xml或者java中給予MATCH_PARENT
// Child wants to be our size. So be it.
//設(shè)置child的size為size，mode為EXACTLY
resultSize = size;
resultMode = MeasureSpec.EXACTLY;
} else if (childDimension == LayoutParams.WRAP_CONTENT) {
//如果child的layout_wOrh屬性在xml或者java中給予WRAP_CONTENT
//設(shè)置child的size為size，mode為AT_MOST
// Child wants to determine its own size. It can't be
// bigger than us.
resultSize = size;
resultMode = MeasureSpec.AT_MOST;
}
break;
......
//其他Mode分支類(lèi)似
}
//將mode與size通過(guò)MeasureSpec方法整合為32位整數(shù)返回
return MeasureSpec.makeMeasureSpec(resultSize, resultMode);
}
可以看見(jiàn)，getChildMeasureSpec的邏輯是通過(guò)其父View提供的MeasureSpec參數(shù)得到specMode和specSize，然后根據(jù)計(jì)算出來(lái)的specMode以及子View的childDimension（layout_width或layout_height）來(lái)計(jì)算自身的measureSpec，如果其本身包含子視圖，則計(jì)算出來(lái)的measureSpec將作為調(diào)用其子視圖measure函數(shù)的參數(shù)，同時(shí)也作為自身調(diào)用setMeasuredDimension的參數(shù)，如果其不包含子視圖則默認(rèn)情況下最終會(huì)調(diào)用onMeasure的默認(rèn)實(shí)現(xiàn)，并最終調(diào)用到setMeasuredDimension。
所以可以看見(jiàn)onMeasure的參數(shù)其實(shí)就是這么計(jì)算出來(lái)的。同時(shí)從上面的分析可以看出來(lái)，最終決定View的measure大小是View的setMeasuredDimension方法，所以我們可以通過(guò)setMeasuredDimension設(shè)定死值來(lái)設(shè)置View的mMeasuredWidth和mMeasuredHeight的大小，但是一個(gè)好的自定義View應(yīng)該會(huì)根據(jù)子視圖的measureSpec來(lái)設(shè)置mMeasuredWidth和mMeasuredHeight的大小，這樣的靈活性更大，所以這也就是上面分析onMeasure時(shí)說(shuō)View的onMeasure最好不要重寫(xiě)死值的原因。
可以看見(jiàn)當(dāng)通過(guò)setMeasuredDimension方法最終設(shè)置完成View的measure之后View的mMeasuredWidth和mMeasuredHeight成員才會(huì)有具體的數(shù)值，所以如果我們自定義的View或者使用現(xiàn)成的View想通過(guò)getMeasuredWidth()和getMeasuredHeight()方法來(lái)獲取View測(cè)量的寬高，必須保證這兩個(gè)方法在onMeasure流程之后被調(diào)用才能返回有效值。
inflate方法加載一些布局顯示時(shí)指定的大小失效問(wèn)題，現(xiàn)在給出了詳細(xì)原因分析，我想不需要再做過(guò)多解釋了吧。
至此整個(gè)View繪制流程的第一步就分析完成了，可以看見(jiàn)，相對(duì)來(lái)說(shuō)還是比較復(fù)雜的，接下來(lái)進(jìn)行小結(jié)。
小總結(jié)
通過(guò)上面分析可以看出measure過(guò)程主要就是從頂層父View向子View遞歸調(diào)用view.measure方法（measure中又回調(diào)onMeasure方法）的過(guò)程。具體measure核心主要有如下幾點(diǎn)：
-
MeasureSpec（View的內(nèi)部類(lèi)）測(cè)量規(guī)格為int型，值由高2位規(guī)格模式specMode和低30位具體尺寸specSize組成。其中specMode只有三種值：
MeasureSpec.EXACTLY //確定模式，父View希望子View的大小是確定的，由specSize決定； MeasureSpec.AT_MOST //最多模式，父View希望子View的大小最多是specSize指定的值； MeasureSpec.UNSPECIFIED //未指定模式，父View完全依據(jù)子View的設(shè)計(jì)值來(lái)決定； View的measure方法是final的，不允許重載，View子類(lèi)只能重載onMeasure來(lái)完成自己的測(cè)量邏輯。
最頂層DecorView測(cè)量時(shí)的MeasureSpec是由ViewRootImpl中g(shù)etRootMeasureSpec方法確定的（LayoutParams寬高參數(shù)均為MATCH_PARENT，specMode是EXACTLY，specSize為物理屏幕大?。?。
ViewGroup類(lèi)提供了measureChild，measureChild和measureChildWithMargins方法，簡(jiǎn)化了父子View的尺寸計(jì)算。
只要是ViewGroup的子類(lèi)就必須要求LayoutParams繼承子MarginLayoutParams，否則無(wú)法使用layout_margin參數(shù)。
View的布局大小由父View和子View共同決定。
使用View的getMeasuredWidth()和getMeasuredHeight()方法來(lái)獲取View測(cè)量的寬高，必須保證這兩個(gè)方法在onMeasure流程之后被調(diào)用才能返回有效值。
遞歸layout源碼分析
在上面的背景介紹就說(shuō)過(guò)，當(dāng)ViewRootImpl的performTraversals中measure執(zhí)行完成以后會(huì)接著執(zhí)行mView.layout，具體如下：
private void performTraversals() {
......
mView.layout(0, 0, mView.getMeasuredWidth(), mView.getMeasuredHeight());
......
}
可以看見(jiàn)layout方法接收四個(gè)參數(shù)，這四個(gè)參數(shù)分別代表相對(duì)Parent的左、上、右、下坐標(biāo)。而且還可以看見(jiàn)左上都為0，右下分別為上面剛剛測(cè)量的width和height。
至此又回歸到View的layout(int l, int t, int r, int b)方法中去實(shí)現(xiàn)具體邏輯了，所以接下來(lái)我們開(kāi)始分析View的layout過(guò)程。
layout既然也是遞歸結(jié)構(gòu)，那我們先看下ViewGroup的layout方法，如下：
@Override
public final void layout(int l, int t, int r, int b) {
......
super.layout(l, t, r, b);
......
}
看著沒(méi)有？ViewGroup的layout方法實(shí)質(zhì)還是調(diào)運(yùn)了View父類(lèi)的layout方法，所以我們看下View的layout源碼，如下：
public void layout(int l, int t, int r, int b) {
......
//實(shí)質(zhì)都是調(diào)用setFrame方法把參數(shù)分別賦值給mLeft、mTop、mRight和mBottom這幾個(gè)變量
//判斷View的位置是否發(fā)生過(guò)變化，以確定有沒(méi)有必要對(duì)當(dāng)前的View進(jìn)行重新layout
boolean changed = isLayoutModeOptical(mParent) ?
setOpticalFrame(l, t, r, b) : setFrame(l, t, r, b);
//需要重新layout
if (changed || (mPrivateFlags & PFLAG_LAYOUT_REQUIRED) == PFLAG_LAYOUT_REQUIRED) {
//回調(diào)onLayout
onLayout(changed, l, t, r, b);
......
}
......
}
看見(jiàn)沒(méi)有，類(lèi)似measure過(guò)程，lauout調(diào)運(yùn)了onLayout方法。
對(duì)比上面View的layout和ViewGroup的layout方法可以發(fā)現(xiàn)，View的layout方法是可以在子類(lèi)重寫(xiě)的，而ViewGroup的layout是不能在子類(lèi)重寫(xiě)的，言外之意就是說(shuō)ViewGroup中只能通過(guò)重寫(xiě)onLayout方法。那我們接下來(lái)看下ViewGroup的onLayout方法，如下：
@Override
protected abstract void onLayout(boolean changed,
int l, int t, int r, int b);
看見(jiàn)沒(méi)有？ViewGroup的onLayout()方法竟然是一個(gè)抽象方法，這就是說(shuō)所有ViewGroup的子類(lèi)都必須重寫(xiě)這個(gè)方法。所以在自定義ViewGroup控件中，onLayout配合onMeasure方法一起使用可以實(shí)現(xiàn)自定義View的復(fù)雜布局。自定義View首先調(diào)用onMeasure進(jìn)行測(cè)量，然后調(diào)用onLayout方法動(dòng)態(tài)獲取子View和子View的測(cè)量大小，然后進(jìn)行l(wèi)ayout布局。重載onLayout的目的就是安排其children在父View的具體位置，重載onLayout通常做法就是寫(xiě)一個(gè)for循環(huán)調(diào)用每一個(gè)子視圖的layout(l, t, r, b)函數(shù)，傳入不同的參數(shù)l, t, r, b來(lái)確定每個(gè)子視圖在父視圖中的顯示位置。
再看下View的onLayout方法源碼，如下：
protected void onLayout(boolean changed, int left, int top, int right, int bottom) {
}
我勒個(gè)去！是一個(gè)空方法，沒(méi)啥可看的。
既然這樣那我們只能分析一個(gè)現(xiàn)有的繼承ViewGroup的控件了，就拿LinearLayout來(lái)說(shuō)吧，如下是LinearLayout中onLayout的一些代碼：
public class LinearLayout extends ViewGroup {
@Override
protected void onLayout(boolean changed, int l, int t, int r, int b) {
if (mOrientation == VERTICAL) {
layoutVertical(l, t, r, b);
} else {
layoutHorizontal(l, t, r, b);
}
}
}
看見(jiàn)沒(méi)有，LinearLayout的layout過(guò)程是分Vertical和Horizontal的，這個(gè)就是xml布局的orientation屬性設(shè)置的，我們?yōu)槔f(shuō)明ViewGroup的onLayout重寫(xiě)一般步驟就拿這里的VERTICAL模式來(lái)解釋吧，如下是layoutVertical方法源碼：
void layoutVertical(int left, int top, int right, int bottom) {
final int paddingLeft = mPaddingLeft;
int childTop;
int childLeft;
// Where right end of child should go
//計(jì)算父窗口推薦的子View寬度
final int width = right - left;
//計(jì)算父窗口推薦的子View右側(cè)位置
int childRight = width - mPaddingRight;
// Space available for child
//child可使用空間大小
int childSpace = width - paddingLeft - mPaddingRight;
//通過(guò)ViewGroup的getChildCount方法獲取ViewGroup的子View個(gè)數(shù)
final int count = getVirtualChildCount();
//獲取Gravity屬性設(shè)置
final int majorGravity = mGravity & Gravity.VERTICAL_GRAVITY_MASK;
final int minorGravity = mGravity & Gravity.RELATIVE_HORIZONTAL_GRAVITY_MASK;
//依據(jù)majorGravity計(jì)算childTop的位置值
switch (majorGravity) {
case Gravity.BOTTOM:
// mTotalLength contains the padding already
childTop = mPaddingTop + bottom - top - mTotalLength;
break;
// mTotalLength contains the padding already
case Gravity.CENTER_VERTICAL:
childTop = mPaddingTop + (bottom - top - mTotalLength) / 2;
break;
case Gravity.TOP:
default:
childTop = mPaddingTop;
break;
}
//重點(diǎn)?。。￠_(kāi)始遍歷
for (int i = 0; i < count; i++) {
final View child = getVirtualChildAt(i);
if (child == null) {
childTop += measureNullChild(i);
} else if (child.getVisibility() != GONE) {
//LinearLayout中其子視圖顯示的寬和高由measure過(guò)程來(lái)決定的，因此measure過(guò)程的意義就是為layout過(guò)程提供視圖顯示范圍的參考值
final int childWidth = child.getMeasuredWidth();
final int childHeight = child.getMeasuredHeight();
//獲取子View的LayoutParams
final LinearLayout.LayoutParams lp =
(LinearLayout.LayoutParams) child.getLayoutParams();
int gravity = lp.gravity;
if (gravity < 0) {
gravity = minorGravity;
}
final int layoutDirection = getLayoutDirection();
final int absoluteGravity = Gravity.getAbsoluteGravity(gravity, layoutDirection);
//依據(jù)不同的absoluteGravity計(jì)算childLeft位置
switch (absoluteGravity & Gravity.HORIZONTAL_GRAVITY_MASK) {
case Gravity.CENTER_HORIZONTAL:
childLeft = paddingLeft + ((childSpace - childWidth) / 2)
+ lp.leftMargin - lp.rightMargin;
break;
case Gravity.RIGHT:
childLeft = childRight - childWidth - lp.rightMargin;
break;
case Gravity.LEFT:
default:
childLeft = paddingLeft + lp.leftMargin;
break;
}
if (hasDividerBeforeChildAt(i)) {
childTop += mDividerHeight;
}
childTop += lp.topMargin;
//通過(guò)垂直排列計(jì)算調(diào)運(yùn)child的layout設(shè)置child的位置
setChildFrame(child, childLeft, childTop + getLocationOffset(child),
childWidth, childHeight);
childTop += childHeight + lp.bottomMargin + getNextLocationOffset(child);
i += getChildrenSkipCount(child, i);
}
}
}
從上面分析的ViewGroup子類(lèi)LinearLayout的onLayout實(shí)現(xiàn)代碼可以看出，一般情況下layout過(guò)程會(huì)參考measure過(guò)程中計(jì)算得到的mMeasuredWidth和mMeasuredHeight來(lái)安排子View在父View中顯示的位置，但這不是必須的，measure過(guò)程得到的結(jié)果可能完全沒(méi)有實(shí)際用處，特別是對(duì)于一些自定義的ViewGroup，其子View的個(gè)數(shù)、位置和大小都是固定的，這時(shí)候我們可以忽略整個(gè)measure過(guò)程，只在layout函數(shù)中傳入的4個(gè)參數(shù)來(lái)安排每個(gè)子View的具體位置。
到這里就不得不提getWidth()、getHeight()和getMeasuredWidth()、getMeasuredHeight()這兩對(duì)方法之間的區(qū)別（上面分析measure過(guò)程已經(jīng)說(shuō)過(guò)getMeasuredWidth()、getMeasuredHeight()必須在onMeasure之后使用才有效）?？梢钥闯鰜?lái)getWidth()與getHeight()方法必須在layout(int l, int t, int r, int b)執(zhí)行之后才有效。那我們看下View源碼中這些方法的實(shí)現(xiàn)吧，如下：
public final int getMeasuredWidth() {
return mMeasuredWidth & MEASURED_SIZE_MASK;
}
public final int getMeasuredHeight() {
return mMeasuredHeight & MEASURED_SIZE_MASK;
}
public final int getWidth() {
return mRight - mLeft;
}
public final int getHeight() {
return mBottom - mTop;
}
public final int getLeft() {
return mLeft;
}
public final int getRight() {
return mRight;
}
public final int getTop() {
return mTop;
}
public final int getBottom() {
return mBottom;
}
這也解釋了為什么有些情況下getWidth()和getMeasuredWidth()以及getHeight()和getMeasuredHeight()會(huì)得到不同的值，所以這里不做過(guò)多解釋。
到此整個(gè)View的layout過(guò)程分析就算結(jié)束了，接下來(lái)進(jìn)行一些總結(jié)工作。
小總結(jié)
整個(gè)layout過(guò)程比較容易理解，從上面分析可以看出layout也是從頂層父View向子View的遞歸調(diào)用view.layout方法的過(guò)程，即父View根據(jù)上一步measure子View所得到的布局大小和布局參數(shù)，將子View放在合適的位置上。具體layout核心主要有以下幾點(diǎn)：
View.layout方法可被重載，ViewGroup.layout為final的不可重載，ViewGroup.onLayout為abstract的，子類(lèi)必須重載實(shí)現(xiàn)自己的位置邏輯。
measure操作完成后得到的是對(duì)每個(gè)View經(jīng)測(cè)量過(guò)的measuredWidth和measuredHeight，layout操作完成之后得到的是對(duì)每個(gè)View進(jìn)行位置分配后的mLeft、mTop、mRight、mBottom，這些值都是相對(duì)于父View來(lái)說(shuō)的。
凡是layout_XXX的布局屬性基本都針對(duì)的是包含子View的ViewGroup的，當(dāng)對(duì)一個(gè)沒(méi)有父容器的View設(shè)置相關(guān)layout_XXX屬性是沒(méi)有任何意義的。
使用View的getWidth()和getHeight()方法來(lái)獲取View測(cè)量的寬高，必須保證這兩個(gè)方法在onLayout流程之后被調(diào)用才能返回有效值。
遞歸draw源碼分析
在上面的背景介紹就說(shuō)過(guò)，當(dāng)ViewRootImpl的performTraversals中measure和layout執(zhí)行完成以后會(huì)接著執(zhí)行mView.layout，具體如下：
private void performTraversals() {
......
final Rect dirty = mDirty;
......
canvas = mSurface.lockCanvas(dirty);
......
mView.draw(canvas);
......
}
draw過(guò)程也是在ViewRootImpl的performTraversals()內(nèi)部調(diào)運(yùn)的，其調(diào)用順序在measure()和layout()之后，這里的mView對(duì)于Actiity來(lái)說(shuō)就是PhoneWindow.DecorView，ViewRootImpl中的代碼會(huì)創(chuàng)建一個(gè)Canvas對(duì)象，然后調(diào)用View的draw()方法來(lái)執(zhí)行具體的繪制工。所以又回歸到了ViewGroup與View的樹(shù)狀遞歸draw過(guò)程。
由于ViewGroup沒(méi)有重寫(xiě)View的draw方法，所以如下直接從View的draw方法開(kāi)始分析：
public void draw(Canvas canvas) {
......
/*
* Draw traversal performs several drawing steps which must be executed
* in the appropriate order:
*
* 1. Draw the background
* 2. If necessary, save the canvas' layers to prepare for fading
* 3. Draw view's content
* 4. Draw children
* 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)
......
// Step 2, save the canvas' layers
......
if (drawTop) {
canvas.saveLayer(left, top, right, top + length, null, flags);
}
......
// 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
......
if (drawTop) {
matrix.setScale(1, fadeHeight * topFadeStrength);
matrix.postTranslate(left, top);
fade.setLocalMatrix(matrix);
p.setShader(fade);
canvas.drawRect(left, top, right, top + length, p);
}
......
// Step 6, draw decorations (scrollbars)
onDrawScrollBars(canvas);
......
}
看見(jiàn)整個(gè)View的draw方法很復(fù)雜，但是源碼注釋也很明顯。從注釋可以看出整個(gè)draw過(guò)程分為了6步。源碼注釋說(shuō)（”skip step 2 & 5 if possible (common case)”）第2和5步可以跳過(guò)，所以我們接下來(lái)重點(diǎn)剩余四步。如下：
第一步：對(duì)View的背景進(jìn)行繪制。
可以看見(jiàn)，draw方法通過(guò)調(diào)運(yùn)drawBackground(canvas);方法實(shí)現(xiàn)了背景繪制。我們來(lái)看下這個(gè)方法源碼，如下：
private void drawBackground(Canvas canvas) {
//獲取xml中通過(guò)android:background屬性或者代碼中setBackgroundColor()、setBackgroundResource()等方法進(jìn)行賦值的背景Drawable
final Drawable background = mBackground;
......
//根據(jù)layout過(guò)程確定的View位置來(lái)設(shè)置背景的繪制區(qū)域
if (mBackgroundSizeChanged) {
background.setBounds(0, 0, mRight - mLeft, mBottom - mTop);
mBackgroundSizeChanged = false;
rebuildOutline();
}
......
//調(diào)用Drawable的draw()方法來(lái)完成背景的繪制工作
background.draw(canvas);
......
}
第二步，對(duì)View的內(nèi)容進(jìn)行繪制。
可以看到，這里去調(diào)用了一下View的onDraw()方法，所以我們看下View的onDraw方法（ViewGroup也沒(méi)有重寫(xiě)該方法），如下：
/**
* Implement this to do your drawing.
*
* @param canvas the canvas on which the background will be drawn
*/
protected void onDraw(Canvas canvas) {
}
可以看見(jiàn)，這是一個(gè)空方法。因?yàn)槊總€(gè)View的內(nèi)容部分是各不相同的，所以需要由子類(lèi)去實(shí)現(xiàn)具體邏輯。
第三步，對(duì)當(dāng)前View的所有子View進(jìn)行繪制，如果當(dāng)前的View沒(méi)有子View就不需要進(jìn)行繪制。
我們來(lái)看下View的draw方法中的dispatchDraw(canvas);方法源碼，可以看見(jiàn)如下：
/**
* Called by draw to draw the child views. This may be overridden
* by derived classes to gain control just before its children are drawn
* (but after its own view has been drawn).
* @param canvas the canvas on which to draw the view
*/
protected void dispatchDraw(Canvas canvas) {
}
看見(jiàn)沒(méi)有，View的dispatchDraw()方法是一個(gè)空方法，而且注釋說(shuō)明了如果View包含子類(lèi)需要重寫(xiě)他，所以我們有必要看下ViewGroup的dispatchDraw方法源碼（這也就是剛剛說(shuō)的對(duì)當(dāng)前View的所有子View進(jìn)行繪制，如果當(dāng)前的View沒(méi)有子View就不需要進(jìn)行繪制的原因，因?yàn)槿绻荲iew調(diào)運(yùn)該方法是空的，而ViewGroup才有實(shí)現(xiàn)），如下：
@Override
protected void dispatchDraw(Canvas canvas) {
......
final int childrenCount = mChildrenCount;
final View[] children = mChildren;
......
for (int i = 0; i < childrenCount; i++) {
......
if ((child.mViewFlags & VISIBILITY_MASK) == VISIBLE || child.getAnimation() != null) {
more |= drawChild(canvas, child, drawingTime);
}
}
......
// Draw any disappearing views that have animations
if (mDisappearingChildren != null) {
......
for (int i = disappearingCount; i >= 0; i--) {
......
more |= drawChild(canvas, child, drawingTime);
}
}
......
}
可以看見(jiàn)，ViewGroup確實(shí)重寫(xiě)了View的dispatchDraw()方法，該方法內(nèi)部會(huì)遍歷每個(gè)子View，然后調(diào)用drawChild()方法，我們可以看下ViewGroup的drawChild方法，如下：
protected boolean drawChild(Canvas canvas, View child, long drawingTime) {
return child.draw(canvas, this, drawingTime);
}
可以看見(jiàn)drawChild()方法調(diào)運(yùn)了子View的draw()方法。所以說(shuō)ViewGroup類(lèi)已經(jīng)為我們重寫(xiě)了dispatchDraw()的功能實(shí)現(xiàn)，我們一般不需要重寫(xiě)該方法，但可以重載父類(lèi)函數(shù)實(shí)現(xiàn)具體的功能。
第四步，對(duì)View的滾動(dòng)條進(jìn)行繪制。
可以看到，這里去調(diào)用了一下View的onDrawScrollBars()方法，所以我們看下View的onDrawScrollBars(canvas);方法，如下：
/**
* <p>Request the drawing of the horizontal and the vertical scrollbar. The
* scrollbars are painted only if they have been awakened first.</p>
*
* @param canvas the canvas on which to draw the scrollbars
*
* @see #awakenScrollBars(int)
*/
protected final void onDrawScrollBars(Canvas canvas) {
//繪制ScrollBars分析不是我們這篇的重點(diǎn)，所以暫時(shí)不做分析
......
}
可以看見(jiàn)其實(shí)任何一個(gè)View都是有（水平垂直）滾動(dòng)條的，只是一般情況下沒(méi)讓它顯示而已。
到此，View的draw繪制部分源碼分析完畢，我們接下來(lái)進(jìn)行一些總結(jié)。
小總結(jié)
可以看見(jiàn)，繪制過(guò)程就是把View對(duì)象繪制到屏幕上，整個(gè)draw過(guò)程需要注意如下細(xì)節(jié)：
如果該View是一個(gè)ViewGroup，則需要遞歸繪制其所包含的所有子View。
View默認(rèn)不會(huì)繪制任何內(nèi)容，真正的繪制都需要自己在子類(lèi)中實(shí)現(xiàn)。
View的繪制是借助onDraw方法傳入的Canvas類(lèi)來(lái)進(jìn)行的。
區(qū)分View動(dòng)畫(huà)和ViewGroup布局動(dòng)畫(huà)，前者指的是View自身的動(dòng)畫(huà)，可以通過(guò)setAnimation添加，后者是專(zhuān)門(mén)針對(duì)ViewGroup顯示內(nèi)部子視圖時(shí)設(shè)置的動(dòng)畫(huà)，可以在xml布局文件中對(duì)ViewGroup設(shè)置layoutAnimation屬性（譬如對(duì)LinearLayout設(shè)置子View在顯示時(shí)出現(xiàn)逐行、隨機(jī)、下等顯示等不同動(dòng)畫(huà)效果）。
在獲取畫(huà)布剪切區(qū)（每個(gè)View的draw中傳入的Canvas）時(shí)會(huì)自動(dòng)處理掉padding，子View獲取Canvas不用關(guān)注這些邏輯，只用關(guān)心如何繪制即可。
默認(rèn)情況下子View的ViewGroup.drawChild繪制順序和子View被添加的順序一致，但是你也可以重載ViewGroup.getChildDrawingOrder()方法提供不同順序。
invalidate和postInvalidate方法源碼分析
你可能已經(jīng)看見(jiàn)了，在上面分析View的三步繪制流程中最后都有調(diào)運(yùn)一個(gè)叫invalidate的方法，這個(gè)方法是啥玩意？為何出現(xiàn)頻率這么高？很簡(jiǎn)單，我們拿出來(lái)分析分析不就得了。
invalidate方法源碼分析
來(lái)看一下View類(lèi)中的一些invalidate方法（ViewGroup沒(méi)有重寫(xiě)這些方法），如下：
/**
* Mark the area defined by dirty as needing to be drawn. If the view is
* visible, {@link #onDraw(android.graphics.Canvas)} will be called at some
* point in the future.
* <p>
* This must be called from a UI thread. To call from a non-UI thread, call
* {@link #postInvalidate()}.
* <p>
* <b>WARNING:</b> In API 19 and below, this method may be destructive to
* {@code dirty}.
*
* @param dirty the rectangle representing the bounds of the dirty region
*/
//看見(jiàn)上面注釋沒(méi)有？public，只能在UI Thread中使用，別的Thread用postInvalidate方法，View是可見(jiàn)的才有效，回調(diào)onDraw方法,針對(duì)局部View
public void invalidate(Rect dirty) {
final int scrollX = mScrollX;
final int scrollY = mScrollY;
//實(shí)質(zhì)還是調(diào)運(yùn)invalidateInternal方法
invalidateInternal(dirty.left - scrollX, dirty.top - scrollY,
dirty.right - scrollX, dirty.bottom - scrollY, true, false);
}
/**
* Mark the area defined by the rect (l,t,r,b) as needing to be drawn. The
* coordinates of the dirty rect are relative to the view. If the view is
* visible, {@link #onDraw(android.graphics.Canvas)} will be called at some
* point in the future.
* <p>
* This must be called from a UI thread. To call from a non-UI thread, call
* {@link #postInvalidate()}.
*
* @param l the left position of the dirty region
* @param t the top position of the dirty region
* @param r the right position of the dirty region
* @param b the bottom position of the dirty region
*/
//看見(jiàn)上面注釋沒(méi)有？public，只能在UI Thread中使用，別的Thread用postInvalidate方法，View是可見(jiàn)的才有效，回調(diào)onDraw方法，針對(duì)局部View
public void invalidate(int l, int t, int r, int b) {
final int scrollX = mScrollX;
final int scrollY = mScrollY;
//實(shí)質(zhì)還是調(diào)運(yùn)invalidateInternal方法
invalidateInternal(l - scrollX, t - scrollY, r - scrollX, b - scrollY, true, false);
}
/**
* Invalidate the whole view. If the view is visible,
* {@link #onDraw(android.graphics.Canvas)} will be called at some point in
* the future.
* <p>
* This must be called from a UI thread. To call from a non-UI thread, call
* {@link #postInvalidate()}.
*/
//看見(jiàn)上面注釋沒(méi)有？public，只能在UI Thread中使用，別的Thread用postInvalidate方法，View是可見(jiàn)的才有效，回調(diào)onDraw方法，針對(duì)整個(gè)View
public void invalidate() {
//invalidate的實(shí)質(zhì)還是調(diào)運(yùn)invalidateInternal方法
invalidate(true);
}
/**
* This is where the invalidate() work actually happens. A full invalidate()
* causes the drawing cache to be invalidated, but this function can be
* called with invalidateCache set to false to skip that invalidation step
* for cases that do not need it (for example, a component that remains at
* the same dimensions with the same content).
*
* @param invalidateCache Whether the drawing cache for this view should be
* invalidated as well. This is usually true for a full
* invalidate, but may be set to false if the View's contents or
* dimensions have not changed.
*/
//看見(jiàn)上面注釋沒(méi)有？default的權(quán)限，只能在UI Thread中使用，別的Thread用postInvalidate方法，View是可見(jiàn)的才有效，回調(diào)onDraw方法，針對(duì)整個(gè)View
void invalidate(boolean invalidateCache) {
//實(shí)質(zhì)還是調(diào)運(yùn)invalidateInternal方法
invalidateInternal(0, 0, mRight - mLeft, mBottom - mTop, invalidateCache, true);
}
//！?。。。?！看見(jiàn)沒(méi)有，這是所有invalidate的終極調(diào)運(yùn)方法?。。。。。? void invalidateInternal(int l, int t, int r, int b, boolean invalidateCache,
boolean fullInvalidate) {
......
// Propagate the damage rectangle to the parent view.
final AttachInfo ai = mAttachInfo;
final ViewParent p = mParent;
if (p != null && ai != null && l < r && t < b) {
final Rect damage = ai.mTmpInvalRect;
//設(shè)置刷新區(qū)域
damage.set(l, t, r, b);
//傳遞調(diào)運(yùn)Parent ViewGroup的invalidateChild方法
p.invalidateChild(this, damage);
}
......
}
看見(jiàn)沒(méi)有，View的invalidate（invalidateInternal）方法實(shí)質(zhì)是將要刷新區(qū)域直接傳遞給了父ViewGroup的invalidateChild方法，在invalidate中，調(diào)用父View的invalidateChild，這是一個(gè)從當(dāng)前向上級(jí)父View回溯的過(guò)程，每一層的父View都將自己的顯示區(qū)域與傳入的刷新Rect做交集 。所以我們看下ViewGroup的invalidateChild方法，源碼如下：
public final void invalidateChild(View child, final Rect dirty) {
ViewParent parent = this;
final AttachInfo attachInfo = mAttachInfo;
......
do {
......
//循環(huán)層層上級(jí)調(diào)運(yùn)，直到ViewRootImpl會(huì)返回null
parent = parent.invalidateChildInParent(location, dirty);
......
} while (parent != null);
}
這個(gè)過(guò)程最后傳遞到ViewRootImpl的invalidateChildInParent方法結(jié)束，所以我們看下ViewRootImpl的invalidateChildInParent方法，如下：
@Override
public ViewParent invalidateChildInParent(int[] location, Rect dirty) {
......
//View調(diào)運(yùn)invalidate最終層層上傳到ViewRootImpl后最終觸發(fā)了該方法
scheduleTraversals();
......
return null;
}
看見(jiàn)沒(méi)有？這個(gè)ViewRootImpl類(lèi)的invalidateChildInParent方法直接返回了null，也就是上面ViewGroup中說(shuō)的，層層上級(jí)傳遞到ViewRootImpl的invalidateChildInParent方法結(jié)束了那個(gè)do while循環(huán)?？匆?jiàn)這里調(diào)運(yùn)的scheduleTraversals這個(gè)方法嗎？scheduleTraversals會(huì)通過(guò)Handler的Runnable發(fā)送一個(gè)異步消息，調(diào)運(yùn)doTraversal方法，然后最終調(diào)用performTraversals()執(zhí)行重繪。開(kāi)頭背景知識(shí)介紹說(shuō)過(guò)的，performTraversals就是整個(gè)View數(shù)開(kāi)始繪制的起始調(diào)運(yùn)地方，所以說(shuō)View調(diào)運(yùn)invalidate方法的實(shí)質(zhì)是層層上傳到父級(jí)，直到傳遞到ViewRootImpl后觸發(fā)了scheduleTraversals方法，然后整個(gè)View樹(shù)開(kāi)始重新按照上面分析的View繪制流程進(jìn)行重繪任務(wù)。
到此View的invalidate方法原理就分析完成了。
postInvalidate方法源碼分析
上面分析invalidate方法時(shí)注釋中說(shuō)該方法只能在UI Thread中執(zhí)行，其他線(xiàn)程中需要使用postInvalidate方法，所以我們來(lái)分析分析postInvalidate這個(gè)方法源碼。如下：
public void postInvalidate() {
postInvalidateDelayed(0);
}
繼續(xù)看下他的調(diào)運(yùn)方法postInvalidateDelayed，如下：
public void postInvalidateDelayed(long delayMilliseconds) {
// We try only with the AttachInfo because there's no point in invalidating
// if we are not attached to our window
final AttachInfo attachInfo = mAttachInfo;
//核心，實(shí)質(zhì)就是調(diào)運(yùn)了ViewRootImpl.dispatchInvalidateDelayed方法
if (attachInfo != null) {
attachInfo.mViewRootImpl.dispatchInvalidateDelayed(this, delayMilliseconds);
}
}
我們繼續(xù)看他調(diào)運(yùn)的ViewRootImpl類(lèi)的dispatchInvalidateDelayed方法，如下源碼：
public void dispatchInvalidateDelayed(View view, long delayMilliseconds) {
Message msg = mHandler.obtainMessage(MSG_INVALIDATE, view);
mHandler.sendMessageDelayed(msg, delayMilliseconds);
}
看見(jiàn)沒(méi)有，通過(guò)ViewRootImpl類(lèi)的Handler發(fā)送了一條MSG_INVALIDATE消息，繼續(xù)追蹤這條消息的處理可以發(fā)現(xiàn)：
public void handleMessage(Message msg) {
......
switch (msg.what) {
case MSG_INVALIDATE:
((View) msg.obj).invalidate();
break;
......
}
......
}
看見(jiàn)沒(méi)有，實(shí)質(zhì)就是又在UI Thread中調(diào)運(yùn)了View的invalidate();方法，那接下來(lái)View的invalidate();方法我們就不說(shuō)了，上名已經(jīng)分析過(guò)了。
到此整個(gè)View的postInvalidate方法就分析完成了。
小總結(jié)
關(guān)于這兩個(gè)方法的具體流程和原理上面也分析過(guò)了，相信已經(jīng)很明確了，沒(méi)啥需要解釋的了。所以我們對(duì)其做一個(gè)整體總結(jié)，歸納出重點(diǎn)如下：
invalidate系列方法請(qǐng)求重繪View樹(shù)（也就是draw方法），如果View大小沒(méi)有發(fā)生變化就不會(huì)調(diào)用layout過(guò)程，并且只繪制那些“需要重繪的”View，也就是哪個(gè)View(View只繪制該View，ViewGroup繪制整個(gè)ViewGroup)請(qǐng)求invalidate系列方法，就繪制該View。
常見(jiàn)的引起invalidate方法操作的原因主要有：
- 直接調(diào)用invalidate方法.請(qǐng)求重新draw，但只會(huì)繪制調(diào)用者本身。
- 觸發(fā)setSelection方法。請(qǐng)求重新draw，但只會(huì)繪制調(diào)用者本身。
- 觸發(fā)setVisibility方法。 當(dāng)View可視狀態(tài)在INVISIBLE轉(zhuǎn)換VISIBLE時(shí)會(huì)間接調(diào)用invalidate方法，繼而繪制該View。當(dāng)View的可視狀態(tài)在INVISIBLE\VISIBLE 轉(zhuǎn)換為GONE狀態(tài)時(shí)會(huì)間接調(diào)用requestLayout和invalidate方法，同時(shí)由于View樹(shù)大小發(fā)生了變化，所以會(huì)請(qǐng)求measure過(guò)程以及draw過(guò)程，同樣只繪制需要“重新繪制”的視圖。
- 觸發(fā)setEnabled方法。請(qǐng)求重新draw，但不會(huì)重新繪制任何View包括該調(diào)用者本身。
- 觸發(fā)requestFocus方法。請(qǐng)求View樹(shù)的draw過(guò)程，只繪制“需要重繪”的View。
通過(guò)invalidate方法分析結(jié)果回過(guò)頭去解決一個(gè)背景介紹中的疑惑
分析完invalidate后需要你回過(guò)頭去想一個(gè)問(wèn)題。還記不記得這篇文章的開(kāi)頭背景介紹，我們說(shuō)整個(gè)View繪制流程的最初代碼是在ViewRootImpl類(lèi)的performTraversals()方法中開(kāi)始的。上面當(dāng)時(shí)只是告訴你了這個(gè)結(jié)論，至于這個(gè)ViewRootImpl類(lèi)的performTraversals()方法為何會(huì)被觸發(fā)沒(méi)有說(shuō)明原因。現(xiàn)在我們就來(lái)分析一下這個(gè)觸發(fā)的源頭。
讓我們先把大腦思考暫時(shí)挪回到PhoneWindow的setContentView方法源碼，如下：
@Override
public void setContentView(View view, ViewGroup.LayoutParams params) {
......
//如果mContentParent為空進(jìn)行一些初始化，實(shí)質(zhì)mContentParent是通過(guò)findViewById(ID_ANDROID_CONTENT);獲取的id為content的FrameLayout的布局
if (mContentParent == null) {
installDecor();
}
......
//把我們的view追加到mContentParent
mContentParent.addView(view, params);
......
}
這個(gè)方法是Activity中setContentView的實(shí)現(xiàn)，我們繼續(xù)看下這個(gè)方法里調(diào)運(yùn)的addView方法，也就是ViewGroup的addView方法，如下：
public void addView(View child) {
addView(child, -1);
}
public void addView(View child, int index) {
......
addView(child, index, params);
}
public void addView(View child, int index, LayoutParams params) {
......
//該方法稍后后面會(huì)詳細(xì)分析
requestLayout();
//重點(diǎn)關(guān)注！??！
invalidate(true);
......
}
看見(jiàn)addView調(diào)運(yùn)invalidate方法沒(méi)有？這不就真相大白了。當(dāng)我們寫(xiě)一個(gè)Activity時(shí)，我們一定會(huì)通過(guò)setContentView方法將我們要展示的界面?zhèn)魅朐摲椒?，該方法?huì)講我們界面通過(guò)addView追加到id為content的一個(gè)FrameLayout（ViewGroup）中，然后addView方法中通過(guò)調(diào)運(yùn)invalidate(true)去通知觸發(fā)ViewRootImpl類(lèi)的performTraversals()方法，至此遞歸繪制我們自定義的所有布局。
View的requestLayout方法源碼分析
和invalidate類(lèi)似，其實(shí)在上面分析View繪制流程時(shí)或多或少都調(diào)運(yùn)到了這個(gè)方法，而且這個(gè)方法對(duì)于View來(lái)說(shuō)也比較重要，所以我們接下來(lái)分析一下他。如下View的requestLayout源碼：
public void requestLayout() {
......
if (mParent != null && !mParent.isLayoutRequested()) {
//由此向ViewParent請(qǐng)求布局
//從這個(gè)View開(kāi)始向上一直requestLayout，最終到達(dá)ViewRootImpl的requestLayout
mParent.requestLayout();
}
......
}
看見(jiàn)沒(méi)有，當(dāng)我們觸發(fā)View的requestLayout時(shí)其實(shí)質(zhì)就是層層向上傳遞，直到ViewRootImpl為止，然后觸發(fā)ViewRootImpl的requestLayout方法，如下就是ViewRootImpl的requestLayout方法：
@Override
public void requestLayout() {
if (!mHandlingLayoutInLayoutRequest) {
checkThread();
mLayoutRequested = true;
//View調(diào)運(yùn)requestLayout最終層層上傳到ViewRootImpl后最終觸發(fā)了該方法
scheduleTraversals();
}
}
看見(jiàn)沒(méi)有，類(lèi)似于上面分析的invalidate過(guò)程，只是設(shè)置的標(biāo)記不同，導(dǎo)致對(duì)于View的繪制流程中觸發(fā)的方法不同而已。
小總結(jié)
可以看見(jiàn)，這些方法都是大同小異。對(duì)于requestLayout方法來(lái)說(shuō)總結(jié)如下：
requestLayout()方法會(huì)調(diào)用measure過(guò)程和layout過(guò)程，不會(huì)調(diào)用draw過(guò)程，也不會(huì)重新繪制任何View包括該調(diào)用者本身。
總結(jié)
至此整個(gè)關(guān)于Android應(yīng)用程序開(kāi)發(fā)中的View繪制機(jī)制及相關(guān)重要方法都已經(jīng)分析完畢。關(guān)于各個(gè)方法的總結(jié)這里不再重復(fù)，直接通過(guò)該文章前面的目錄索引到相應(yīng)方法的總結(jié)小節(jié)進(jìn)行查閱即可。
