android字符显示流程图,Android应用层View绘制流程与源码分析
1 ?背景
還記得前面《Android應(yīng)用setContentView與LayoutInflater加載解析機制源碼分析》這篇文章嗎？我們有分析到Activity中界面加載顯示的基本流程原理，記不記得最終分析結(jié)果就是下面的關(guān)系：
看見沒有，如上圖中id為content的內(nèi)容就是整個View樹的結(jié)構(gòu)，所以對每個具體View對象的操作，其實就是個遞歸的實現(xiàn)。
前面《Android觸摸屏事件派發(fā)機制詳解與源碼分析一(View篇)》文
章的3-1小節(jié)說過Android中的任何一個布局、任何一個控件其實都是直接或間接繼承自View實現(xiàn)的，當(dāng)然也包括我們后面一步一步引出的自定義控件
也不例外，所以說這些View應(yīng)該都具有相同的繪制流程與機制才能顯示到屏幕上(因為他們都具備相同的父類View，可能每個控件的具體繪制邏輯有差異，
但是主流程都是一樣的)。經(jīng)過總結(jié)發(fā)現(xiàn)每一個View的繪制過程都必須經(jīng)歷三個最主要的過程，也就是measure、layout和draw。
既然一個View的繪制主要流程是這三步，那一定有一個開始地方呀，就像一個類從main函數(shù)執(zhí)行一樣呀。對于View的繪制開始調(diào)運地方這里先給出結(jié)論，本文后面會反過來分析原因的，先往下看就行。具體結(jié)論如下：
整個View樹的繪圖流程是在ViewRootImpl類的performTraversals()方法(這個方法巨長)開始的，該函數(shù)做的執(zhí)行過
程主要是根據(jù)之前設(shè)置的狀態(tài)，判斷是否重新計算視圖大小(measure)、是否重新放置視圖的位置(layout)、以及是否重繪
(draw)，其核心也就是通過判斷來選擇順序執(zhí)行這三個方法中的哪個，如下：private?void?performTraversals()?{
......
//最外層的根視圖的widthMeasureSpec和heightMeasureSpec由來
//lp.width和lp.height在創(chuàng)建ViewGroup實例時等于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;
}
可以看見這個方法的注釋說是用來測Root
View的。上面?zhèn)魅雲(yún)?shù)后這個函數(shù)走的是MATCH_PARENT，使用MeasureSpec.makeMeasureSpec方法組裝一個
MeasureSpec，MeasureSpec的specMode等于EXACTLY，specSize等于windowSize，也就是為何根視圖總
是全屏的原因。
其中的mView就是View對象。如下就是整個流程的大致流程圖：
如下我們就依據(jù)View繪制的這三個主要流程進行詳細剖析(基于Android5.1.1 API 22源碼進行分析)。
2 View繪制流程第一步：遞歸measure源碼分析
整個View樹的源碼measure流程圖如下：
2-1 ?measure源碼分析
先看下View的measure方法源碼，如下：/**
*?
*?This?is?called?to?find?out?how?big?a?view?should?be.?The?parent
*?supplies?constraint?information?in?the?width?and?height?parameters.
*?
*
*?
*?The?actual?measurement?work?of?a?view?is?performed?in
*?[email?protected]?#onMeasure(int,?int)},?called?by?this?method.?Therefore,?only
*?[email?protected]?#onMeasure(int,?int)}?can?and?must?be?overridden?by?subclasses.
*?
*
*
*?@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);
......
}
看見注釋信息沒有，他告訴你了很多重要信息。為整個View樹計算實際的大小，然后設(shè)置實際的高和寬，每個View控件的實際寬高都是由父視圖和自
身決定的。實際的測量是在onMeasure方法進行，所以在View的子類需要重寫onMeasure方法，這是因為measure方法是final
的，不允許重載，所以View子類只能通過重載onMeasure來實現(xiàn)自己的測量邏輯。
這個方法的兩個參數(shù)都是父View傳遞過來的，也就是代表了父view的規(guī)格。他由兩部分組成，高16位表示MODE，定義在
MeasureSpec類(View的內(nèi)部類)中，有三種類型，MeasureSpec.EXACTLY表示確定大小，
MeasureSpec.AT_MOST表示最大大小，
MeasureSpec.UNSPECIFIED不確定。低16位表示size，也就是父View的大小。對于系統(tǒng)Window類的DecorVIew對
象Mode一般都為MeasureSpec.EXACTLY
，而size分別對應(yīng)屏幕寬高。對于子View來說大小是由父View和子View共同決定的。
在這里可以看出measure方法最終回調(diào)了View的onMeasure方法，我們來看下View的onMeasure源碼，如下：/**
*?
*?Measure?the?view?and?its?content?to?determine?the?measured?width?and?the
*?measured?height.?This?method?is?invoked?by?[email?protected]?#measure(int,?int)}?and
*?should?be?overriden?by?subclasses?to?provide?accurate?and?efficient
*?measurement?of?their?contents.
*?
*
*?
*?CONTRACT:?When?overriding?this?method,?you
*?must?call?[email?protected]?#setMeasuredDimension(int,?int)}?to?store?the
*?measured?width?and?height?of?this?view.?Failure?to?do?so?will?trigger?an
*?IllegalStateException,?thrown?by
*?[email?protected]?#measure(int,?int)}.?Calling?the?superclass'
*?[email?protected]?#onMeasure(int,?int)}?is?a?valid?use.
*?
*
*?
*?The?base?class?implementation?of?measure?defaults?to?the?background?size,
*?unless?a?larger?size?is?allowed?by?the?MeasureSpec.?Subclasses?should
*?override?[email?protected]?#onMeasure(int,?int)}?to?provide?better?measurements?of
*?their?content.
*?
*
*?
*?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?([email?protected]?#getSuggestedMinimumHeight()}?and
*?[email?protected]?#getSuggestedMinimumWidth()}).
*?
*
*?@param?widthMeasureSpec?horizontal?space?requirements?as?imposed?by?the?parent.
*?????????????????????????The?requirements?are?encoded?with
*?????????????????????????[email?protected]?android.view.View.MeasureSpec}.
*?@param?heightMeasureSpec?vertical?space?requirements?as?imposed?by?the?parent.
*?????????????????????????The?requirements?are?encoded?with
*?????????????????????????[email?protected]?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默認實現(xiàn)方法
protected?void?onMeasure(int?widthMeasureSpec,?int?heightMeasureSpec)?{
setMeasuredDimension(getDefaultSize(getSuggestedMinimumWidth(),?widthMeasureSpec),
getDefaultSize(getSuggestedMinimumHeight(),?heightMeasureSpec));
}
看見沒有，其實注釋已經(jīng)很詳細了(自定義View重寫該方法的指導(dǎo)操作注釋都有說明)，不做過多解釋。
對于非ViewGroup的View而言，通過調(diào)用上面默認的onMeasure即可完成View的測量，當(dāng)然你也可以重載onMeasure并調(diào)
用setMeasuredDimension來設(shè)置任意大小的布局，但一般不這么做，因為這種做法不太好，至于為何不好，后面分析完你就明白了。
我們可以看見onMeasure默認的實現(xiàn)僅僅調(diào)用了setMeasuredDimension，setMeasuredDimension函數(shù)是
一個很關(guān)鍵的函數(shù)，它對View的成員變量mMeasuredWidth和mMeasuredHeight變量賦值，measure的主要目的就是對
View樹中的每個View的mMeasuredWidth和mMeasuredHeight進行賦值，所以一旦這兩個變量被賦值意味著該View的測量
工作結(jié)束。既然這樣那我們就看看設(shè)置的默認尺寸大小吧，可以看見setMeasuredDimension傳入的參數(shù)都是通過
getDefaultSize返回的，所以再來看下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)默認的規(guī)格。
回過頭繼續(xù)看上面onMeasure方法，其中g(shù)etDefaultSize參數(shù)的widthMeasureSpec和
heightMeasureSpec都是由父View傳遞進來的。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過程就完成了。上面說了View實際是嵌套的，而且measure是遞歸傳遞的，所以每個View都
需要measure。實際能夠嵌套的View一般都是ViewGroup的子類，所以在ViewGroup中定義了measureChildren,
measureChild,
measureChildWithMargins方法來對子視圖進行測量，measureChildren內(nèi)部實質(zhì)只是循環(huán)調(diào)用
measureChild，measureChild和measureChildWithMargins的區(qū)別就是是否把margin和padding也
作為子視圖的大小。如下我們以ViewGroup中稍微復(fù)雜的measureChildWithMargins方法來分析：/**
*?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
//通過這兩個參數(shù)以及子視圖本身的LayoutParams來共同決定子視圖的測量規(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)運子View的measure方法，子View的measure中會回調(diào)子View的onMeasure方法
child.measure(childWidthMeasureSpec,?childHeightMeasureSpec);
}
關(guān)于該方法的參數(shù)等說明注釋已經(jīng)描述的夠清楚了。該方法就是對父視圖提供的measureSpec參數(shù)結(jié)合自身的LayoutParams參數(shù)進行了調(diào)
整，然后再來調(diào)用child.measure()方法，具體通過方法getChildMeasureSpec來進行參數(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);
//定義返回值存儲變量
int?resultSize?=?0;
int?resultMode?=?0;
//依據(jù)當(dāng)前Parent的Mode進行switch分支邏輯
switch?(specMode)?{
//?Parent?has?imposed?an?exact?size?on?us
//默認Root?View的Mode就是EXACTLY
case?MeasureSpec.EXACTLY:
if?(childDimension?>=?0)?{
//如果child的layout_wOrh屬性在xml或者java中給予具體大于等于0的數(shù)值
//設(shè)置child的size為真實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ù)計算出來的specMode以及子View的childDimension(layout_width或
layout_height)來計算自身的measureSpec，如果其本身包含子視圖，則計算出來的measureSpec將作為調(diào)用其子視圖
measure函數(shù)的參數(shù)，同時也作為自身調(diào)用setMeasuredDimension的參數(shù)，如果其不包含子視圖則默認情況下最終會調(diào)用
onMeasure的默認實現(xiàn)，并最終調(diào)用到setMeasuredDimension。
所以可以看見onMeasure的參數(shù)其實就是這么計算出來的。同時從上面的分析可以看出來，最終決定View的measure大小是View的
setMeasuredDimension方法，所以我們可以通過setMeasuredDimension設(shè)定死值來設(shè)置View的
mMeasuredWidth和mMeasuredHeight的大小，但是一個好的自定義View應(yīng)該會根據(jù)子視圖的measureSpec來設(shè)置
mMeasuredWidth和mMeasuredHeight的大小，這樣的靈活性更大，所以這也就是上面分析onMeasure時說View的
onMeasure最好不要重寫死值的原因。
可以看見當(dāng)通過setMeasuredDimension方法最終設(shè)置完成View的measure之后View的mMeasuredWidth和
mMeasuredHeight成員才會有具體的數(shù)值，所以如果我們自定義的View或者使用現(xiàn)成的View想通過getMeasuredWidth()
和getMeasuredHeight()方法來獲取View測量的寬高，必須保證這兩個方法在onMeasure流程之后被調(diào)用才能返回有效值。
還記得前面《Android應(yīng)用setContentView與LayoutInflater加載解析機制源碼分析》文章3-3小節(jié)探討的inflate方法加載一些布局顯示時指定的大小失效問題嗎？當(dāng)時只給出了結(jié)論，現(xiàn)在給出了詳細原因分析，我想不需要再做過多解釋了吧。
至此整個View繪制流程的第一步就分析完成了，可以看見，相對來說還是比較復(fù)雜的，接下來進行小結(jié)。
2-2 ?measure原理總結(jié)
通過上面分析可以看出measure過程主要就是從頂層父View向子View遞歸調(diào)用view.measure方法(measure中又回調(diào)onMeasure方法)的過程。具體measure核心主要有如下幾點：MeasureSpec(View的內(nèi)部類)測量規(guī)格為int型，值由高16位規(guī)格模式specMode和低16位具體尺寸specSize組成。其中specMode只有三種值：MeasureSpec.EXACTLY?//確定模式，父View希望子View的大小是確定的，由specSize決定；
MeasureSpec.AT_MOST?//最多模式，父View希望子View的大小最多是specSize指定的值；
MeasureSpec.UNSPECIFIED?//未指定模式，父View完全依據(jù)子View的設(shè)計值來決定；View的measure方法是final的，不允許重載，View子類只能重載onMeasure來完成自己的測量邏輯。
最頂層DecorView測量時的MeasureSpec是由ViewRootImpl中g(shù)etRootMeasureSpec方法確定的
(LayoutParams寬高參數(shù)均為MATCH_PARENT，specMode是EXACTLY，specSize為物理屏幕大小)。
ViewGroup類提供了measureChild，measureChild和measureChildWithMargins方法，簡化了父子View的尺寸計算。
只要是ViewGroup的子類就必須要求LayoutParams繼承子MarginLayoutParams，否則無法使用layout_margin參數(shù)。
View的布局大小由父View和子View共同決定。
使用View的getMeasuredWidth()和getMeasuredHeight()方法來獲取View測量的寬高，必須保證這兩個方法在onMeasure流程之后被調(diào)用才能返回有效值。
3 View繪制流程第二步：遞歸layout源碼分析
在上面的背景介紹就說過，當(dāng)ViewRootImpl的performTraversals中measure執(zhí)行完成以后會接著執(zhí)行mView.layout，具體如下：private?void?performTraversals()?{
......
mView.layout(0,?0,?mView.getMeasuredWidth(),?mView.getMeasuredHeight());
......
}
可以看見layout方法接收四個參數(shù)，這四個參數(shù)分別代表相對Parent的左、上、右、下坐標(biāo)。而且還可以看見左上都為0，右下分別為上面剛剛測量的width和height。
至此又回歸到View的layout(int l, int t, int r, int b)方法中去實現(xiàn)具體邏輯了，所以接下來我們開始分析View的layout過程。
整個View樹的layout遞歸流程圖如下：
3-1 ?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方法實質(zhì)還是調(diào)運了View父類的layout方法，所以我們看下View的layout源碼，如下：public?void?layout(int?l,?int?t,?int?r,?int?b)?{
......
//實質(zhì)都是調(diào)用setFrame方法把參數(shù)分別賦值給mLeft、mTop、mRight和mBottom這幾個變量
//判斷View的位置是否發(fā)生過變化，以確定有沒有必要對當(dāng)前的View進行重新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)運了onLayout方法。
對比上面View的layout和ViewGroup的layout方法可以發(fā)現(xiàn)，View的layout方法是可以在子類重寫的，而
ViewGroup的layout是不能在子類重寫的，言外之意就是說ViewGroup中只能通過重寫onLayout方法。那我們接下來看下
ViewGroup的onLayout方法，如下：@Override
protected?abstract?void?onLayout(boolean?changed,
int?l,?int?t,?int?r,?int?b);
看見沒有？ViewGroup的onLayout()方法竟然是一個抽象方法，這就是說所有ViewGroup的子類都必須重寫這個方法。所以在自
定義ViewGroup控件中，onLayout配合onMeasure方法一起使用可以實現(xiàn)自定義View的復(fù)雜布局。自定義View首先調(diào)用
onMeasure進行測量，然后調(diào)用onLayout方法動態(tài)獲取子View和子View的測量大小，然后進行l(wèi)ayout布局。重載onLayout
的目的就是安排其children在父View的具體位置，重載onLayout通常做法就是寫一個for循環(huán)調(diào)用每一個子視圖的layout(l,
t, r, b)函數(shù)，傳入不同的參數(shù)l, t, r, b來確定每個子視圖在父視圖中的顯示位置。
再看下View的onLayout方法源碼，如下：protected?void?onLayout(boolean?changed,?int?left,?int?top,?int?right,?int?bottom)?{
}
我勒個去！是一個空方法，沒啥可看的。
既然這樣那我們只能分析一個現(xiàn)有的繼承ViewGroup的控件了，就拿LinearLayout來說吧，如下是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的，這個就是xml布局的orientation屬性
設(shè)置的，我們?yōu)槔f明ViewGroup的onLayout重寫一般步驟就拿這里的VERTICAL模式來解釋吧，如下是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
//計算父窗口推薦的子View寬度
final?int?width?=?right?-?left;
//計算父窗口推薦的子View右側(cè)位置
int?childRight?=?width?-?mPaddingRight;
//?Space?available?for?child
//child可使用空間大小
int?childSpace?=?width?-?paddingLeft?-?mPaddingRight;
//通過ViewGroup的getChildCount方法獲取ViewGroup的子View個數(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計算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;
}
//重點！！！開始遍歷
for?(int?i?=?0;?i?
final?View?child?=?getVirtualChildAt(i);
if?(child?==?null)?{
childTop?+=?measureNullChild(i);
}?else?if?(child.getVisibility()?!=?GONE)?{
//LinearLayout中其子視圖顯示的寬和高由measure過程來決定的，因此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?
gravity?=?minorGravity;
}
final?int?layoutDirection?=?getLayoutDirection();
final?int?absoluteGravity?=?Gravity.getAbsoluteGravity(gravity,?layoutDirection);
//依據(jù)不同的absoluteGravity計算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;
//通過垂直排列計算調(diào)運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實現(xiàn)代碼可以看出，一般情況下layout過程會參考
measure過程中計算得到的mMeasuredWidth和mMeasuredHeight來安排子View在父View中顯示的位置，但這不是必須
的，measure過程得到的結(jié)果可能完全沒有實際用處，特別是對于一些自定義的ViewGroup，其子View的個數(shù)、位置和大小都是固定的，這時候
我們可以忽略整個measure過程，只在layout函數(shù)中傳入的4個參數(shù)來安排每個子View的具體位置。
到這里就不得不提getWidth()、getHeight()和getMeasuredWidth()、getMeasuredHeight()
這兩對方法之間的區(qū)別(上面分析measure過程已經(jīng)說過getMeasuredWidth()、getMeasuredHeight()必須在
onMeasure之后使用才有效)。可以看出來getWidth()與getHeight()方法必須在layout(int l, int t,
int r, int b)執(zhí)行之后才有效。那我們看下View源碼中這些方法的實現(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()會得到不同的值，所以這里不做過多解釋。
到此整個View的layout過程分析就算結(jié)束了，接下來進行一些總結(jié)工作。
3-2 ?layout原理總結(jié)
整個layout過程比較容易理解，從上面分析可以看出layout也是從頂層父View向子View的遞歸調(diào)用view.layout方法的過
程，即父View根據(jù)上一步measure子View所得到的布局大小和布局參數(shù)，將子View放在合適的位置上。具體layout核心主要有以下幾點：View.layout方法可被重載，ViewGroup.layout為final的不可重載，ViewGroup.onLayout為abstract的，子類必須重載實現(xiàn)自己的位置邏輯。
measure操作完成后得到的是對每個View經(jīng)測量過的measuredWidth和measuredHeight，layout操作
完成之后得到的是對每個View進行位置分配后的mLeft、mTop、mRight、mBottom，這些值都是相對于父View來說的。
凡是layout_XXX的布局屬性基本都針對的是包含子View的ViewGroup的，當(dāng)對一個沒有父容器的View設(shè)置相關(guān)layout_XXX屬性是沒有任何意義的(前面《Android應(yīng)用setContentView與LayoutInflater加載解析機制源碼分析》也有提到過)。
使用View的getWidth()和getHeight()方法來獲取View測量的寬高，必須保證這兩個方法在onLayout流程之后被調(diào)用才能返回有效值。
4 View繪制流程第三步：遞歸draw源碼分析
在上面的背景介紹就說過，當(dāng)ViewRootImpl的performTraversals中measure和layout執(zhí)行完成以后會接著執(zhí)行mView.layout，具體如下：private?void?performTraversals()?{
......
final?Rect?dirty?=?mDirty;
......
canvas?=?mSurface.lockCanvas(dirty);
......
mView.draw(canvas);
......
}
draw過程也是在ViewRootImpl的performTraversals()內(nèi)部調(diào)運的，其調(diào)用順序在measure()和
layout()之后，這里的mView對于Actiity來說就是PhoneWindow.DecorView，ViewRootImpl中的代碼會創(chuàng)
建一個Canvas對象，然后調(diào)用View的draw()方法來執(zhí)行具體的繪制工。所以又回歸到了ViewGroup與View的樹狀遞歸draw過程。
先來看下View樹的遞歸draw流程圖，如下：
如下我們詳細分析這一過程。
4-1 ?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);
......
}
看見整個View的draw方法很復(fù)雜，但是源碼注釋也很明顯。從注釋可以看出整個draw過程分為了6步。源碼注釋說(”skip step 2
& 5 if possible (common case)”)第2和5步可以跳過，所以我們接下來重點剩余四步。如下：
第一步，對View的背景進行繪制。
可以看見，draw方法通過調(diào)運drawBackground(canvas);方法實現(xiàn)了背景繪制。我們來看下這個方法源碼，如下：private?void?drawBackground(Canvas?canvas)?{
//獲取xml中通過android:background屬性或者代碼中setBackgroundColor()、setBackgroundResource()等方法進行賦值的背景Drawable
final?Drawable?background?=?mBackground;
......
//根據(jù)layout過程確定的View位置來設(shè)置背景的繪制區(qū)域
if?(mBackgroundSizeChanged)?{
background.setBounds(0,?0,??mRight?-?mLeft,?mBottom?-?mTop);
mBackgroundSizeChanged?=?false;
rebuildOutline();
}
......
//調(diào)用Drawable的draw()方法來完成背景的繪制工作
background.draw(canvas);
......
}
第三步，對View的內(nèi)容進行繪制。
可以看到，這里去調(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)?{
}
可以看見，這是一個空方法。因為每個View的內(nèi)容部分是各不相同的，所以需要由子類去實現(xiàn)具體邏輯。
第四步，對當(dāng)前View的所有子View進行繪制，如果當(dāng)前的View沒有子View就不需要進行繪制。
我們來看下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()方法是一個空方法，而且注釋說明了如果View包含子類需要重寫他，所以我們有必要看下
ViewGroup的dispatchDraw方法源碼(這也就是剛剛說的對當(dāng)前View的所有子View進行繪制，如果當(dāng)前的View沒有子View就
不需要進行繪制的原因，因為如果是View調(diào)運該方法是空的，而ViewGroup才有實現(xiàn))，如下：@Override
protected?void?dispatchDraw(Canvas?canvas)?{
......
final?int?childrenCount?=?mChildrenCount;
final?View[]?children?=?mChildren;
......
for?(int?i?=?0;?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確實重寫了View的dispatchDraw()方法，該方法內(nèi)部會遍歷每個子View，然后調(diào)用drawChild()方法，我們可以看下ViewGroup的drawChild方法，如下：protected?boolean?drawChild(Canvas?canvas,?View?child,?long?drawingTime)?{
return?child.draw(canvas,?this,?drawingTime);
}
可以看見drawChild()方法調(diào)運了子View的draw()方法。所以說ViewGroup類已經(jīng)為我們重寫了dispatchDraw()的功能實現(xiàn)，我們一般不需要重寫該方法，但可以重載父類函數(shù)實現(xiàn)具體的功能。
第六步，對View的滾動條進行繪制。
可以看到，這里去調(diào)用了一下View的onDrawScrollBars()方法，所以我們看下View的onDrawScrollBars(canvas);方法，如下：/**
*?
Request?the?drawing?of?the?horizontal?and?the?vertical?scrollbar.?The
*?scrollbars?are?painted?only?if?they?have?been?awakened?first.
*
*?@param?canvas?the?canvas?on?which?to?draw?the?scrollbars
*
*?@see?#awakenScrollBars(int)
*/
protected?final?void?onDrawScrollBars(Canvas?canvas)?{
//繪制ScrollBars分析不是我們這篇的重點，所以暫時不做分析
......
}
可以看見其實任何一個View都是有(水平垂直)滾動條的，只是一般情況下沒讓它顯示而已。
到此，View的draw繪制部分源碼分析完畢，我們接下來進行一些總結(jié)。
4-2 ?draw原理總結(jié)
可以看見，繪制過程就是把View對象繪制到屏幕上，整個draw過程需要注意如下細節(jié)：如果該View是一個ViewGroup，則需要遞歸繪制其所包含的所有子View。
View默認不會繪制任何內(nèi)容，真正的繪制都需要自己在子類中實現(xiàn)。
View的繪制是借助onDraw方法傳入的Canvas類來進行的。
區(qū)分View動畫和ViewGroup布局動畫，前者指的是View自身的動畫，可以通過setAnimation添加，后者是專門針對
ViewGroup顯示內(nèi)部子視圖時設(shè)置的動畫，可以在xml布局文件中對ViewGroup設(shè)置layoutAnimation屬性(譬如對
LinearLayout設(shè)置子View在顯示時出現(xiàn)逐行、隨機、下等顯示等不同動畫效果)。
在獲取畫布剪切區(qū)(每個View的draw中傳入的Canvas)時會自動處理掉padding，子View獲取Canvas不用關(guān)注這些邏輯，只用關(guān)心如何繪制即可。
默認情況下子View的ViewGroup.drawChild繪制順序和子View被添加的順序一致，但是你也可以重載ViewGroup.getChildDrawingOrder()方法提供不同順序。
5 View的invalidate和postInvalidate方法源碼分析
你可能已經(jīng)看見了，在上面分析View的三步繪制流程中最后都有調(diào)運一個叫invalidate的方法，這個方法是啥玩意？為何出現(xiàn)頻率這么高？很簡單，我們拿出來分析分析不就得了。
5-1 ?invalidate方法源碼分析
來看一下View類中的一些invalidate方法(ViewGroup沒有重寫這些方法)，如下：/**
*?Mark?the?area?defined?by?dirty?as?needing?to?be?drawn.?If?the?view?is
*?visible,?[email?protected]?#onDraw(android.graphics.Canvas)}?will?be?called?at?some
*?point?in?the?future.
*?
*?This?must?be?called?from?a?UI?thread.?To?call?from?a?non-UI?thread,?call
*?[email?protected]?#postInvalidate()}.
*?
*?WARNING:?In?API?19?and?below,?this?method?may?be?destructive?to
*?[email?protected]?dirty}.
*
*?@param?dirty?the?rectangle?representing?the?bounds?of?the?dirty?region
*/
//看見上面注釋沒有？public，只能在UI?Thread中使用，別的Thread用postInvalidate方法，View是可見的才有效，回調(diào)onDraw方法,針對局部View
public?void?invalidate(Rect?dirty)?{
final?int?scrollX?=?mScrollX;
final?int?scrollY?=?mScrollY;
//實質(zhì)還是調(diào)運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,?[email?protected]?#onDraw(android.graphics.Canvas)}?will?be?called?at?some
*?point?in?the?future.
*?
*?This?must?be?called?from?a?UI?thread.?To?call?from?a?non-UI?thread,?call
*?[email?protected]?#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方法，針對局部View
public?void?invalidate(int?l,?int?t,?int?r,?int?b)?{
final?int?scrollX?=?mScrollX;
final?int?scrollY?=?mScrollY;
//實質(zhì)還是調(diào)運invalidateInternal方法
invalidateInternal(l?-?scrollX,?t?-?scrollY,?r?-?scrollX,?b?-?scrollY,?true,?false);
}
/**
*?Invalidate?the?whole?view.?If?the?view?is?visible,
*?[email?protected]?#onDraw(android.graphics.Canvas)}?will?be?called?at?some?point?in
*?the?future.
*?
*?This?must?be?called?from?a?UI?thread.?To?call?from?a?non-UI?thread,?call
*?[email?protected]?#postInvalidate()}.
*/
//看見上面注釋沒有？public，只能在UI?Thread中使用，別的Thread用postInvalidate方法，View是可見的才有效，回調(diào)onDraw方法，針對整個View
public?void?invalidate()?{
//invalidate的實質(zhì)還是調(diào)運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方法，針對整個View
void?invalidate(boolean?invalidateCache)?{
//實質(zhì)還是調(diào)運invalidateInternal方法
invalidateInternal(0,?0,?mRight?-?mLeft,?mBottom?-?mTop,?invalidateCache,?true);
}
//！！！！！！看見沒有，這是所有invalidate的終極調(diào)運方法！！！！！！
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?
final?Rect?damage?=?ai.mTmpInvalRect;
//設(shè)置刷新區(qū)域
damage.set(l,?t,?r,?b);
//傳遞調(diào)運Parent?ViewGroup的invalidateChild方法
p.invalidateChild(this,?damage);
}
......
}
看見沒有，View的invalidate(invalidateInternal)方法實質(zhì)是將要刷新區(qū)域直接傳遞給了父ViewGroup的
invalidateChild方法，在invalidate中，調(diào)用父View的invalidateChild，這是一個從當(dāng)前向上級父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)層層上級調(diào)運，直到ViewRootImpl會返回null
parent?=?parent.invalidateChildInParent(location,?dirty);
......
}?while?(parent?!=?null);
}
這個過程最后傳遞到ViewRootImpl的invalidateChildInParent方法結(jié)束，所以我們看下ViewRootImpl的invalidateChildInParent方法，如下：@Override
public?ViewParent?invalidateChildInParent(int[]?location,?Rect?dirty)?{
......
//View調(diào)運invalidate最終層層上傳到ViewRootImpl后最終觸發(fā)了該方法
scheduleTraversals();
......
return?null;
}
看見沒有？這個ViewRootImpl類的invalidateChildInParent方法直接返回了null，也就是上面
ViewGroup中說的，層層上級傳遞到ViewRootImpl的invalidateChildInParent方法結(jié)束了那個do
while循環(huán)。看見這里調(diào)運的scheduleTraversals這個方法嗎？scheduleTraversals會通過Handler的
Runnable發(fā)送一個異步消息，調(diào)運doTraversal方法，然后最終調(diào)用performTraversals()執(zhí)行重繪。開頭背景知識介紹說
過的，performTraversals就是整個View數(shù)開始繪制的起始調(diào)運地方，所以說View調(diào)運invalidate方法的實質(zhì)是層層上傳到父
級，直到傳遞到ViewRootImpl后觸發(fā)了scheduleTraversals方法，然后整個View樹開始重新按照上面分析的View繪制流程
進行重繪任務(wù)。
到此View的invalidate方法原理就分析完成了。
5-2 ?postInvalidate方法源碼分析
上面分析invalidate方法時注釋中說該方法只能在UI Thread中執(zhí)行，其他線程中需要使用postInvalidate方法，所以我們來分析分析postInvalidate這個方法源碼。如下：public?void?postInvalidate()?{
postInvalidateDelayed(0);
}
繼續(xù)看下他的調(diào)運方法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;
//核心，實質(zhì)就是調(diào)運了ViewRootImpl.dispatchInvalidateDelayed方法
if?(attachInfo?!=?null)?{
attachInfo.mViewRootImpl.dispatchInvalidateDelayed(this,?delayMilliseconds);
}
}
我們繼續(xù)看他調(diào)運的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;
......
}
......
}
看見沒有，實質(zhì)就是又在UI Thread中調(diào)運了View的invalidate();方法，那接下來View的invalidate();方法我們就不說了，上名已經(jīng)分析過了。
到此整個View的postInvalidate方法就分析完成了。
5-3 ?invalidate與postInvalidate方法總結(jié)
依據(jù)上面對View的invalidate分析我總結(jié)繪制如下流程圖：
依據(jù)上面對View的postInvalidate分析我總結(jié)繪制如下流程圖：
關(guān)于這兩個方法的具體流程和原理上面也分析過了，流程圖也給出了，相信已經(jīng)很明確了，沒啥需要解釋的了。所以我們對其做一個整體總結(jié)，歸納出重點如下：
invalidate系列方法請求重繪View樹(也就是draw方法)，如果View大小沒有發(fā)生變化就不會調(diào)用layout過程，并且只繪制那
些“需要重繪的”View，也就是哪個View(View只繪制該View，ViewGroup繪制整個ViewGroup)請求invalidate系
列方法，就繪制該View。
常見的引起invalidate方法操作的原因主要有：直接調(diào)用invalidate方法.請求重新draw，但只會繪制調(diào)用者本身。
觸發(fā)setSelection方法。請求重新draw，但只會繪制調(diào)用者本身。
觸發(fā)setVisibility方法。
當(dāng)View可視狀態(tài)在INVISIBLE轉(zhuǎn)換VISIBLE時會間接調(diào)用invalidate方法，繼而繪制該View。當(dāng)View的可視狀態(tài)在
INVISIBLE\VISIBLE
轉(zhuǎn)換為GONE狀態(tài)時會間接調(diào)用requestLayout和invalidate方法，同時由于View樹大小發(fā)生了變化，所以會請求measure過
程以及draw過程，同樣只繪制需要“重新繪制”的視圖。
觸發(fā)setEnabled方法。請求重新draw，但不會重新繪制任何View包括該調(diào)用者本身。
觸發(fā)requestFocus方法。請求View樹的draw過程，只繪制“需要重繪”的View。
5-4 ?通過invalidate方法分析結(jié)果回過頭去解決一個背景介紹中的疑惑
分析完invalidate后需要你回過頭去想一個問題。還記不記得這篇文章的開頭背景介紹，我們說整個View繪制流程的最初代碼是在
ViewRootImpl類的performTraversals()方法中開始的。上面當(dāng)時只是告訴你了這個結(jié)論，至于這個ViewRootImpl類
的performTraversals()方法為何會被觸發(fā)沒有說明原因。現(xiàn)在我們就來分析一下這個觸發(fā)的源頭。
讓我們先把大腦思考暫時挪回到《Android應(yīng)用setContentView與LayoutInflater加載解析機制源碼分析》這篇博文的setContentView機制分析中(不清楚的請點擊先看這篇文章再回過頭來繼續(xù)看)。我們先來看下那篇博文分析的PhoneWindow的setContentView方法源碼，如下：@Override
public?void?setContentView(View?view,?ViewGroup.LayoutParams?params)?{
......
//如果mContentParent為空進行一些初始化，實質(zhì)mContentParent是通過findViewById(ID_ANDROID_CONTENT);獲取的id為content的FrameLayout的布局(不清楚的請先看《Android應(yīng)用setContentView與LayoutInflater加載解析機制源碼分析》文章)
if?(mContentParent?==?null)?{
installDecor();
}
......
//把我們的view追加到mContentParent
mContentParent.addView(view,?params);
......
}
這個方法是Activity中setContentView的實現(xiàn)，我們繼續(xù)看下這個方法里調(diào)運的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)?{
......
//該方法稍后后面會詳細分析
requestLayout();
//重點關(guān)注！！！
invalidate(true);
......
}
看見addView調(diào)運invalidate方法沒有？這不就真相大白了。當(dāng)我們寫一個Activity時，我們一定會通過
setContentView方法將我們要展示的界面?zhèn)魅朐摲椒?#xff0c;該方法會講我們界面通過addView追加到id為content的一個
FrameLayout(ViewGroup)中，然后addView方法中通過調(diào)運invalidate(true)去通知觸發(fā)
ViewRootImpl類的performTraversals()方法，至此遞歸繪制我們自定義的所有布局。
6 View的requestLayout方法源碼分析
6-1 ?requestLayout方法分析
和invalidate類似，其實在上面分析View繪制流程時或多或少都調(diào)運到了這個方法，而且這個方法對于View來說也比較重要，所以我們接下來分析一下他。如下View的requestLayout源碼：public?void?requestLayout()?{
......
if?(mParent?!=?null?&&?!mParent.isLayoutRequested())?{
//由此向ViewParent請求布局
//從這個View開始向上一直requestLayout，最終到達ViewRootImpl的requestLayout
mParent.requestLayout();
}
......
}
看見沒有，當(dāng)我們觸發(fā)View的requestLayout時其實質(zhì)就是層層向上傳遞，直到ViewRootImpl為止，然后觸發(fā)ViewRootImpl的requestLayout方法，如下就是ViewRootImpl的requestLayout方法：@Override
public?void?requestLayout()?{
if?(!mHandlingLayoutInLayoutRequest)?{
checkThread();
mLayoutRequested?=?true;
//View調(diào)運requestLayout最終層層上傳到ViewRootImpl后最終觸發(fā)了該方法
scheduleTraversals();
}
}
看見沒有，類似于上面分析的invalidate過程，只是設(shè)置的標(biāo)記不同，導(dǎo)致對于View的繪制流程中觸發(fā)的方法不同而已。
6-2 ?requestLayout方法總結(jié)
可以看見，這些方法都是大同小異。對于requestLayout方法來說總結(jié)如下：
requestLayout()方法會調(diào)用measure過程和layout過程，不會調(diào)用draw過程，也不會重新繪制任何View包括該調(diào)用者本身。
7 View繪制流程總結(jié)
至此整個關(guān)于Android應(yīng)用程序開發(fā)中的View繪制機制及相關(guān)重要方法都已經(jīng)分析完畢。關(guān)于各個方法的總結(jié)這里不再重復(fù)，直接通過該文章前面的目錄索引到相應(yīng)方法的總結(jié)小節(jié)進行查閱即可。
總結(jié)
以上是生活随笔為你收集整理的android字符显示流程图,Android应用层View绘制流程与源码分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Android绘制自定义控件,Andro
- 下一篇： android热更新插件,与Androi