前言
Activity中界面加載顯示的基本流程原理淹仑，最終分析結(jié)果就是下面的關(guān)系：
看見沒有磅甩，如上圖中id為content的內(nèi)容就是整個(gè)View樹的結(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)樗麄兌季邆湎嗤母割怴iew躏惋，可能每個(gè)控件的具體繪制邏輯有差異幽污，但是主流程都是一樣的）。經(jīng)過總結(jié)發(fā)現(xiàn)每一個(gè)View的繪制過程都必須經(jīng)歷三個(gè)最主要的過程簿姨，也就是measure距误、layout和draw。
既然一個(gè)View的繪制主要流程是這三步扁位，那一定有一個(gè)開始地方呀准潭，就像一個(gè)類從main函數(shù)執(zhí)行一樣呀。對(duì)于View的繪制開始調(diào)運(yùn)地方這里先給出結(jié)論域仇，本文后面會(huì)反過來(lái)分析原因的刑然，先往下看就行。具體結(jié)論如下：
整個(gè)View樹的繪圖流程是在ViewRootImpl類的performTraversals()方法（這個(gè)方法巨長(zhǎng)）開始的暇务，該函數(shù)做的執(zhí)行過程主要是根據(jù)之前設(shè)置的狀態(tài)泼掠，判斷是否重新計(jì)算視圖大小(measure)、是否重新放置視圖的位置(layout)般卑、以及是否重繪 (draw)武鲁，其核心也就是通過判斷來(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;
}
可以看見這個(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方法订框，子類不可重寫
public final void measure(int widthMeasureSpec, int heightMeasureSpec) {
......
//回調(diào)onMeasure()方法
onMeasure(widthMeasureSpec, heightMeasureSpec);
......
}
看見注釋信息沒有，他告訴你了很多重要信息兜叨。為整個(gè)View樹計(jì)算實(shí)際的大小穿扳，然后設(shè)置實(shí)際的高和寬，每個(gè)View控件的實(shí)際寬高都是由父視圖和自身決定的国旷。實(shí)際的測(cè)量是在onMeasure方法進(jìn)行矛物，所以在View的子類需要重寫onMeasure方法，這是因?yàn)閙easure方法是final的跪但，不允許重載履羞，所以View子類只能通過重載onMeasure來(lái)實(shí)現(xiàn)自己的測(cè)量邏輯。
這個(gè)方法的兩個(gè)參數(shù)都是父View傳遞過來(lái)的屡久，也就是代表了父view的規(guī)格忆首。他由兩部分組成，高2位表示MODE被环，定義在MeasureSpec類（View的內(nèi)部類）中糙及，有三種類型，MeasureSpec.EXACTLY表示確定大小筛欢， MeasureSpec.AT_MOST表示最大大小丁鹉， MeasureSpec.UNSPECIFIED不確定。低30位表示size悴能，也就是父View的大小。對(duì)于系統(tǒng)Window類的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));
}
看見沒有，其實(shí)注釋已經(jīng)很詳細(xì)了（自定義View重寫該方法的指導(dǎo)操作注釋都有說(shuō)明）匈庭，不做過多解釋夫凸。
對(duì)于非ViewGroup的View而言，通過調(diào)用上面默認(rèn)的onMeasure即可完成View的測(cè)量阱持，當(dāng)然你也可以重載onMeasure并調(diào)用setMeasuredDimension來(lái)設(shè)置任意大小的布局夭拌，但一般不這么做，因?yàn)檫@種做法不太好，至于為何不好鸽扁，后面分析完你就明白了蒜绽。
我們可以看見onMeasure默認(rèn)的實(shí)現(xiàn)僅僅調(diào)用了setMeasuredDimension，setMeasuredDimension函數(shù)是一個(gè)很關(guān)鍵的函數(shù)桶现，它對(duì)View的成員變量mMeasuredWidth和mMeasuredHeight變量賦值躲雅，measure的主要目的就是對(duì)View樹中的每個(gè)View的mMeasuredWidth和mMeasuredHeight進(jìn)行賦值，所以一旦這兩個(gè)變量被賦值意味著該View的測(cè)量工作結(jié)束骡和。既然這樣那我們就看看設(shè)置的默認(rèn)尺寸大小吧相赁，可以看見setMeasuredDimension傳入的參數(shù)都是通過getDefaultSize返回的，所以再來(lái)看下getDefaultSize方法源碼慰于，如下：
public static int getDefaultSize(int size, int measureSpec) {
int result = size;
//通過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;
}
看見沒有钮科，如果specMode等于AT_MOST或EXACTLY就返回specSize，這就是系統(tǒng)默認(rèn)的規(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());
}
看見沒有桨嫁，建議的最小寬度和高度都是由View的Background尺寸與通過設(shè)置View的miniXXX屬性共同決定的。
到此一次最基礎(chǔ)的元素View的measure過程就完成了份帐。上面說(shuō)了View實(shí)際是嵌套的璃吧，而且measure是遞歸傳遞的，所以每個(gè)View都需要measure。實(shí)際能夠嵌套的View一般都是ViewGroup的子類沫勿，所以在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
//通過這兩個(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()方法，具體通過方法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直接返回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分支類似
}
//將mode與size通過MeasureSpec方法整合為32位整數(shù)返回
return MeasureSpec.makeMeasureSpec(resultSize, resultMode);
}
可以看見尤辱，getChildMeasureSpec的邏輯是通過其父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娄涩。
所以可以看見onMeasure的參數(shù)其實(shí)就是這么計(jì)算出來(lái)的。同時(shí)從上面的分析可以看出來(lái)映跟，最終決定View的measure大小是View的setMeasuredDimension方法蓄拣，所以我們可以通過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最好不要重寫死值的原因。
可以看見當(dāng)通過setMeasuredDimension方法最終設(shè)置完成View的measure之后View的mMeasuredWidth和mMeasuredHeight成員才會(huì)有具體的數(shù)值荸镊，所以如果我們自定義的View或者使用現(xiàn)成的View想通過getMeasuredWidth()和getMeasuredHeight()方法來(lái)獲取View測(cè)量的寬高咽斧，必須保證這兩個(gè)方法在onMeasure流程之后被調(diào)用才能返回有效值。
inflate方法加載一些布局顯示時(shí)指定的大小失效問題躬存，現(xiàn)在給出了詳細(xì)原因分析张惹，我想不需要再做過多解釋了吧。
至此整個(gè)View繪制流程的第一步就分析完成了岭洲，可以看見宛逗，相對(duì)來(lái)說(shuō)還是比較復(fù)雜的，接下來(lái)進(jìn)行小結(jié)盾剩。
小總結(jié)
通過上面分析可以看出measure過程主要就是從頂層父View向子View遞歸調(diào)用view.measure方法（measure中又回調(diào)onMeasure方法）的過程雷激。具體measure核心主要有如下幾點(diǎn)：
-
MeasureSpec（View的內(nè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子類只能重載onMeasure來(lái)完成自己的測(cè)量邏輯。
最頂層DecorView測(cè)量時(shí)的MeasureSpec是由ViewRootImpl中g(shù)etRootMeasureSpec方法確定的（LayoutParams寬高參數(shù)均為MATCH_PARENT襟衰，specMode是EXACTLY贴铜，specSize為物理屏幕大小）。
ViewGroup類提供了measureChild绍坝，measureChild和measureChildWithMargins方法徘意，簡(jiǎn)化了父子View的尺寸計(jì)算。
只要是ViewGroup的子類就必須要求LayoutParams繼承子MarginLayoutParams轩褐，否則無(wú)法使用layout_margin參數(shù)椎咧。
View的布局大小由父View和子View共同決定。
使用View的getMeasuredWidth()和getMeasuredHeight()方法來(lái)獲取View測(cè)量的寬高把介，必須保證這兩個(gè)方法在onMeasure流程之后被調(diào)用才能返回有效值勤讽。
遞歸layout源碼分析
在上面的背景介紹就說(shuō)過，當(dāng)ViewRootImpl的performTraversals中measure執(zhí)行完成以后會(huì)接著執(zhí)行mView.layout拗踢，具體如下：
private void performTraversals() {
......
mView.layout(0, 0, mView.getMeasuredWidth(), mView.getMeasuredHeight());
......
}
可以看見layout方法接收四個(gè)參數(shù)脚牍，這四個(gè)參數(shù)分別代表相對(duì)Parent的左、上巢墅、右诸狭、下坐標(biāo)。而且還可以看見左上都為0君纫，右下分別為上面剛剛測(cè)量的width和height驯遇。
至此又回歸到View的layout(int l, int t, int r, int b)方法中去實(shí)現(xiàn)具體邏輯了，所以接下來(lái)我們開始分析View的layout過程庵芭。
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);
......
}
看著沒有双吆？ViewGroup的layout方法實(shí)質(zhì)還是調(diào)運(yùn)了View父類的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ā)生過變化，以確定有沒有必要對(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);
......
}
......
}
看見沒有蔚万，類似measure過程岭妖，lauout調(diào)運(yùn)了onLayout方法。
對(duì)比上面View的layout和ViewGroup的layout方法可以發(fā)現(xiàn)反璃，View的layout方法是可以在子類重寫的昵慌，而ViewGroup的layout是不能在子類重寫的，言外之意就是說(shuō)ViewGroup中只能通過重寫onLayout方法淮蜈。那我們接下來(lái)看下ViewGroup的onLayout方法斋攀，如下：
@Override
protected abstract void onLayout(boolean changed,
int l, int t, int r, int b);
看見沒有？ViewGroup的onLayout()方法竟然是一個(gè)抽象方法梧田，這就是說(shuō)所有ViewGroup的子類都必須重寫這個(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通常做法就是寫一個(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è)空方法，沒啥可看的猜憎。
既然這樣那我們只能分析一個(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);
}
}
}
看見沒有胰柑，LinearLayout的layout過程是分Vertical和Horizontal的截亦，這個(gè)就是xml布局的orientation屬性設(shè)置的，我們?yōu)槔f(shuō)明ViewGroup的onLayout重寫一般步驟就拿這里的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;
//通過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)１廊俊！踩官！開始遍歷
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過程來(lái)決定的却桶，因此measure過程的意義就是為layout過程提供視圖顯示范圍的參考值
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;
//通過垂直排列計(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子類LinearLayout的onLayout實(shí)現(xiàn)代碼可以看出，一般情況下layout過程會(huì)參考measure過程中計(jì)算得到的mMeasuredWidth和mMeasuredHeight來(lái)安排子View在父View中顯示的位置蔗牡，但這不是必須的颖系，measure過程得到的結(jié)果可能完全沒有實(shí)際用處，特別是對(duì)于一些自定義的ViewGroup辩越，其子View的個(gè)數(shù)嘁扼、位置和大小都是固定的，這時(shí)候我們可以忽略整個(gè)measure過程黔攒，只在layout函數(shù)中傳入的4個(gè)參數(shù)來(lái)安排每個(gè)子View的具體位置趁啸。
到這里就不得不提getWidth()、getHeight()和getMeasuredWidth()督惰、getMeasuredHeight()這兩對(duì)方法之間的區(qū)別（上面分析measure過程已經(jīng)說(shuō)過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ì)得到不同的值栅哀，所以這里不做過多解釋震肮。
到此整個(gè)View的layout過程分析就算結(jié)束了，接下來(lái)進(jìn)行一些總結(jié)工作留拾。
小總結(jié)
整個(gè)layout過程比較容易理解戳晌，從上面分析可以看出layout也是從頂層父View向子View的遞歸調(diào)用view.layout方法的過程，即父View根據(jù)上一步measure子View所得到的布局大小和布局參數(shù)痴柔，將子View放在合適的位置上沦偎。具體layout核心主要有以下幾點(diǎn)：
View.layout方法可被重載，ViewGroup.layout為final的不可重載咳蔚，ViewGroup.onLayout為abstract的豪嚎，子類必須重載實(shí)現(xiàn)自己的位置邏輯。
measure操作完成后得到的是對(duì)每個(gè)View經(jīng)測(cè)量過的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è)沒有父容器的View設(shè)置相關(guān)layout_XXX屬性是沒有任何意義的革为。
使用View的getWidth()和getHeight()方法來(lái)獲取View測(cè)量的寬高，必須保證這兩個(gè)方法在onLayout流程之后被調(diào)用才能返回有效值舵鳞。
遞歸draw源碼分析
在上面的背景介紹就說(shuō)過震檩，當(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過程也是在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的樹狀遞歸draw過程。
由于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
* 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);
......
}
看見整個(gè)View的draw方法很復(fù)雜错忱，但是源碼注釋也很明顯。從注釋可以看出整個(gè)draw過程分為了6步挂据。源碼注釋說(shuō)（”skip step 2 & 5 if possible (common case)”）第2和5步可以跳過以清，所以我們接下來(lái)重點(diǎn)剩余四步。如下：
第一步：對(duì)View的背景進(jìn)行繪制崎逃。
可以看見掷倔，draw方法通過調(diào)運(yùn)drawBackground(canvas);方法實(shí)現(xiàn)了背景繪制。我們來(lái)看下這個(gè)方法源碼个绍，如下：
private void drawBackground(Canvas canvas) {
//獲取xml中通過android:background屬性或者代碼中setBackgroundColor()勒葱、setBackgroundResource()等方法進(jìn)行賦值的背景Drawable
final Drawable background = mBackground;
......
//根據(jù)layout過程確定的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也沒有重寫該方法），如下：
/**
* Implement this to do your drawing.
*
* @param canvas the canvas on which the background will be drawn
*/
protected void onDraw(Canvas canvas) {
}
可以看見凯旋，這是一個(gè)空方法呀潭。因?yàn)槊總€(gè)View的內(nèi)容部分是各不相同的，所以需要由子類去實(shí)現(xiàn)具體邏輯至非。
第三步钠署，對(duì)當(dāng)前View的所有子View進(jìn)行繪制，如果當(dāng)前的View沒有子View就不需要進(jìn)行繪制荒椭。
我們來(lái)看下View的draw方法中的dispatchDraw(canvas);方法源碼谐鼎，可以看見如下：
/**
* 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) {
}
看見沒有，View的dispatchDraw()方法是一個(gè)空方法戳杀，而且注釋說(shuō)明了如果View包含子類需要重寫他该面，所以我們有必要看下ViewGroup的dispatchDraw方法源碼（這也就是剛剛說(shuō)的對(duì)當(dāng)前View的所有子View進(jìn)行繪制，如果當(dāng)前的View沒有子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);
}
}
......
}
可以看見傍菇，ViewGroup確實(shí)重寫了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);
}
可以看見drawChild()方法調(diào)運(yùn)了子View的draw()方法。所以說(shuō)ViewGroup類已經(jīng)為我們重寫了dispatchDraw()的功能實(shí)現(xiàn)咐低，我們一般不需要重寫該方法揽思，但可以重載父類函數(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í)不做分析
......
}
可以看見其實(shí)任何一個(gè)View都是有（水平垂直）滾動(dòng)條的酒来，只是一般情況下沒讓它顯示而已卢未。
到此，View的draw繪制部分源碼分析完畢，我們接下來(lái)進(jìn)行一些總結(jié)辽社。
小總結(jié)
可以看見伟墙，繪制過程就是把View對(duì)象繪制到屏幕上，整個(gè)draw過程需要注意如下細(xì)節(jié)：
如果該View是一個(gè)ViewGroup滴铅，則需要遞歸繪制其所包含的所有子View远荠。
View默認(rèn)不會(huì)繪制任何內(nèi)容，真正的繪制都需要自己在子類中實(shí)現(xiàn)失息。
View的繪制是借助onDraw方法傳入的Canvas類來(lái)進(jìn)行的。
區(qū)分View動(dòng)畫和ViewGroup布局動(dòng)畫档址，前者指的是View自身的動(dòng)畫盹兢，可以通過setAnimation添加，后者是專門針對(duì)ViewGroup顯示內(nèi)部子視圖時(shí)設(shè)置的動(dòng)畫守伸，可以在xml布局文件中對(duì)ViewGroup設(shè)置layoutAnimation屬性（譬如對(duì)LinearLayout設(shè)置子View在顯示時(shí)出現(xiàn)逐行绎秒、隨機(jī)、下等顯示等不同動(dòng)畫效果）尼摹。
在獲取畫布剪切區(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)看見了和二，在上面分析View的三步繪制流程中最后都有調(diào)運(yùn)一個(gè)叫invalidate的方法徘铝，這個(gè)方法是啥玩意？為何出現(xiàn)頻率這么高惯吕？很簡(jiǎn)單惕它，我們拿出來(lái)分析分析不就得了。
invalidate方法源碼分析
來(lái)看一下View類中的一些invalidate方法（ViewGroup沒有重寫這些方法）废登，如下：
/**
* 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
*/
//看見上面注釋沒有淹魄？public，只能在UI Thread中使用堡距，別的Thread用postInvalidate方法甲锡，View是可見的才有效，回調(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
*/
//看見上面注釋沒有吏颖？public搔体，只能在UI Thread中使用，別的Thread用postInvalidate方法半醉，View是可見的才有效疚俱，回調(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()}.
*/
//看見上面注釋沒有缩多？public呆奕，只能在UI Thread中使用养晋，別的Thread用postInvalidate方法，View是可見的才有效梁钾，回調(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.
*/
//看見上面注釋沒有？default的權(quán)限姆泻，只能在UI Thread中使用零酪，別的Thread用postInvalidate方法，View是可見的才有效拇勃，回調(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);
}
//！７脚亍Ｔ乱浮！０曷浮榆骚！看見沒有，這是所有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);
}
......
}
看見沒有方面，View的invalidate（invalidateInternal）方法實(shí)質(zhì)是將要刷新區(qū)域直接傳遞給了父ViewGroup的invalidateChild方法放钦，在invalidate中，調(diào)用父View的invalidateChild恭金，這是一個(gè)從當(dāng)前向上級(jí)父View回溯的過程操禀，每一層的父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è)過程最后傳遞到ViewRootImpl的invalidateChildInParent方法結(jié)束，所以我們看下ViewRootImpl的invalidateChildInParent方法耿焊，如下：
@Override
public ViewParent invalidateChildInParent(int[] location, Rect dirty) {
......
//View調(diào)運(yùn)invalidate最終層層上傳到ViewRootImpl后最終觸發(fā)了該方法
scheduleTraversals();
......
return null;
}
看見沒有揪惦？這個(gè)ViewRootImpl類的invalidateChildInParent方法直接返回了null，也就是上面ViewGroup中說(shuō)的罗侯，層層上級(jí)傳遞到ViewRootImpl的invalidateChildInParent方法結(jié)束了那個(gè)do while循環(huán)器腋。看見這里調(diào)運(yùn)的scheduleTraversals這個(gè)方法嗎？scheduleTraversals會(huì)通過Handler的Runnable發(fā)送一個(gè)異步消息纫塌，調(diào)運(yùn)doTraversal方法诊县，然后最終調(diào)用performTraversals()執(zhí)行重繪。開頭背景知識(shí)介紹說(shuō)過的措左，performTraversals就是整個(gè)View數(shù)開始繪制的起始調(diào)運(yùn)地方依痊，所以說(shuō)View調(diào)運(yùn)invalidate方法的實(shí)質(zhì)是層層上傳到父級(jí)，直到傳遞到ViewRootImpl后觸發(fā)了scheduleTraversals方法怎披，然后整個(gè)View樹開始重新按照上面分析的View繪制流程進(jìn)行重繪任務(wù)胸嘁。
到此View的invalidate方法原理就分析完成了。
postInvalidate方法源碼分析
上面分析invalidate方法時(shí)注釋中說(shuō)該方法只能在UI Thread中執(zhí)行凉逛，其他線程中需要使用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類的dispatchInvalidateDelayed方法降瞳，如下源碼：
public void dispatchInvalidateDelayed(View view, long delayMilliseconds) {
Message msg = mHandler.obtainMessage(MSG_INVALIDATE, view);
mHandler.sendMessageDelayed(msg, delayMilliseconds);
}
看見沒有吟吝，通過ViewRootImpl類的Handler發(fā)送了一條MSG_INVALIDATE消息，繼續(xù)追蹤這條消息的處理可以發(fā)現(xiàn)：
public void handleMessage(Message msg) {
......
switch (msg.what) {
case MSG_INVALIDATE:
((View) msg.obj).invalidate();
break;
......
}
......
}
看見沒有菩佑，實(shí)質(zhì)就是又在UI Thread中調(diào)運(yùn)了View的invalidate();方法自晰，那接下來(lái)View的invalidate();方法我們就不說(shuō)了，上名已經(jīng)分析過了稍坯。
到此整個(gè)View的postInvalidate方法就分析完成了酬荞。
小總結(jié)
關(guān)于這兩個(gè)方法的具體流程和原理上面也分析過了，相信已經(jīng)很明確了瞧哟，沒啥需要解釋的了混巧。所以我們對(duì)其做一個(gè)整體總結(jié)，歸納出重點(diǎn)如下：
invalidate系列方法請(qǐng)求重繪View樹（也就是draw方法）勤揩，如果View大小沒有發(fā)生變化就不會(huì)調(diào)用layout過程咧党，并且只繪制那些“需要重繪的”View，也就是哪個(gè)View(View只繪制該View陨亡，ViewGroup繪制整個(gè)ViewGroup)請(qǐng)求invalidate系列方法傍衡，就繪制該View。
常見的引起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樹大小發(fā)生了變化，所以會(huì)請(qǐng)求measure過程以及draw過程盼理，同樣只繪制需要“重新繪制”的視圖谈山。
- 觸發(fā)setEnabled方法。請(qǐng)求重新draw宏怔，但不會(huì)重新繪制任何View包括該調(diào)用者本身奏路。
- 觸發(fā)requestFocus方法。請(qǐng)求View樹的draw過程臊诊，只繪制“需要重繪”的View鸽粉。
通過invalidate方法分析結(jié)果回過頭去解決一個(gè)背景介紹中的疑惑
分析完invalidate后需要你回過頭去想一個(gè)問題。還記不記得這篇文章的開頭背景介紹抓艳，我們說(shuō)整個(gè)View繪制流程的最初代碼是在ViewRootImpl類的performTraversals()方法中開始的触机。上面當(dāng)時(shí)只是告訴你了這個(gè)結(jié)論，至于這個(gè)ViewRootImpl類的performTraversals()方法為何會(huì)被觸發(fā)沒有說(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是通過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);
......
}
看見addView調(diào)運(yùn)invalidate方法沒有舞竿？這不就真相大白了。當(dāng)我們寫一個(gè)Activity時(shí)窿冯，我們一定會(huì)通過setContentView方法將我們要展示的界面?zhèn)魅朐摲椒ň婷穑摲椒〞?huì)講我們界面通過addView追加到id為content的一個(gè)FrameLayout（ViewGroup）中，然后addView方法中通過調(diào)運(yùn)invalidate(true)去通知觸發(fā)ViewRootImpl類的performTraversals()方法靡菇，至此遞歸繪制我們自定義的所有布局重归。
View的requestLayout方法源碼分析
和invalidate類似，其實(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開始向上一直requestLayout较鼓，最終到達(dá)ViewRootImpl的requestLayout
mParent.requestLayout();
}
......
}
看見沒有椎木，當(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();
}
}
看見沒有漱竖，類似于上面分析的invalidate過程，只是設(shè)置的標(biāo)記不同畜伐，導(dǎo)致對(duì)于View的繪制流程中觸發(fā)的方法不同而已馍惹。
小總結(jié)
可以看見，這些方法都是大同小異玛界。對(duì)于requestLayout方法來(lái)說(shuō)總結(jié)如下：
requestLayout()方法會(huì)調(diào)用measure過程和layout過程万矾，不會(huì)調(diào)用draw過程，也不會(huì)重新繪制任何View包括該調(diào)用者本身慎框。
總結(jié)
至此整個(gè)關(guān)于Android應(yīng)用程序開發(fā)中的View繪制機(jī)制及相關(guān)重要方法都已經(jīng)分析完畢良狈。關(guān)于各個(gè)方法的總結(jié)這里不再重復(fù)，直接通過該文章前面的目錄索引到相應(yīng)方法的總結(jié)小節(jié)進(jìn)行查閱即可笨枯。
