android字符显示流程图,Android应用层View绘制流程与源码分析
1 ?背景
還記得前面《Android應(yīng)用setContentView與LayoutInflater加載解析機(jī)制源碼分析》這篇文章嗎？我們有分析到Activity中界面加載顯示的基本流程原理，記不記得最終分析結(jié)果就是下面的關(guān)系：
看見沒有，如上圖中id為content的內(nèi)容就是整個(gè)View樹的結(jié)構(gòu)，所以對(duì)每個(gè)具體View對(duì)象的操作，其實(shí)就是個(gè)遞歸的實(shí)現(xiàn)。
前面《Android觸摸屏事件派發(fā)機(jī)制詳解與源碼分析一(View篇)》文
章的3-1小節(jié)說過Android中的任何一個(gè)布局、任何一個(gè)控件其實(shí)都是直接或間接繼承自View實(shí)現(xiàn)的，當(dāng)然也包括我們后面一步一步引出的自定義控件
也不例外，所以說這些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ì)反過來分析原因的，先往下看就行。具體結(jié)論如下：
整個(gè)View樹的繪圖流程是在ViewRootImpl類的performTraversals()方法(這個(gè)方法巨長)開始的，該函數(shù)做的執(zhí)行過
程主要是根據(jù)之前設(shè)置的狀態(tài)，判斷是否重新計(jì)算視圖大小(measure)、是否重新放置視圖的位置(layout)、以及是否重繪
(draw)，其核心也就是通過判斷來選擇順序執(zhí)行這三個(gè)方法中的哪個(gè)，如下：private?void?performTraversals()?{
......
//最外層的根視圖的widthMeasureSpec和heightMeasureSpec由來
//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è)方法的注釋說是用來測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ì)剖析(基于Android5.1.1 API 22源碼進(jìn)行分析)。
2 View繪制流程第一步：遞歸measure源碼分析
整個(gè)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);
......
}
看見注釋信息沒有，他告訴你了很多重要信息。為整個(gè)View樹計(jì)算實(shí)際的大小，然后設(shè)置實(shí)際的高和寬，每個(gè)View控件的實(shí)際寬高都是由父視圖和自
身決定的。實(shí)際的測量是在onMeasure方法進(jìn)行，所以在View的子類需要重寫onMeasure方法，這是因?yàn)閙easure方法是final
的，不允許重載，所以View子類只能通過重載onMeasure來實(shí)現(xiàn)自己的測量邏輯。
這個(gè)方法的兩個(gè)參數(shù)都是父View傳遞過來的，也就是代表了父view的規(guī)格。他由兩部分組成，高16位表示MODE，定義在
MeasureSpec類(View的內(nèi)部類)中，有三種類型，MeasureSpec.EXACTLY表示確定大小，
MeasureSpec.AT_MOST表示最大大小，
MeasureSpec.UNSPECIFIED不確定。低16位表示size，也就是父View的大小。對(duì)于系統(tǒng)Window類的DecorVIew對(duì)
象Mode一般都為MeasureSpec.EXACTLY
，而size分別對(duì)應(yīng)屏幕寬高。對(duì)于子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默認(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)操作注釋都有說明)，不做過多解釋。
對(duì)于非ViewGroup的View而言，通過調(diào)用上面默認(rèn)的onMeasure即可完成View的測量，當(dāng)然你也可以重載onMeasure并調(diào)
用setMeasuredDimension來設(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的測量
工作結(jié)束。既然這樣那我們就看看設(shè)置的默認(rèn)尺寸大小吧，可以看見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)默認(rèn)的規(guī)格。
回過頭繼續(xù)看上面onMeasure方法，其中g(shù)etDefaultSize參數(shù)的widthMeasureSpec和
heightMeasureSpec都是由父View傳遞進(jìn)來的。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實(shí)際是嵌套的，而且measure是遞歸傳遞的，所以每個(gè)View都
需要measure。實(shí)際能夠嵌套的View一般都是ViewGroup的子類，所以在ViewGroup中定義了measureChildren,
measureChild,
measureChildWithMargins方法來對(duì)子視圖進(jìn)行測量，measureChildren內(nèi)部實(shí)質(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
//通過這兩個(gè)參數(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)運(yùn)子View的measure方法，子View的measure中會(huì)回調(diào)子View的onMeasure方法
child.measure(childWidthMeasureSpec,?childHeightMeasureSpec);
}
關(guān)于該方法的參數(shù)等說明注釋已經(jīng)描述的夠清楚了。該方法就是對(duì)父視圖提供的measureSpec參數(shù)結(jié)合自身的LayoutParams參數(shù)進(jìn)行了調(diào)
整，然后再來調(diào)用child.measure()方法，具體通過方法getChildMeasureSpec來進(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ì)算出來的specMode以及子View的childDimension(layout_width或
layout_height)來計(jì)算自身的measureSpec，如果其本身包含子視圖，則計(jì)算出來的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ì)算出來的。同時(shí)從上面的分析可以看出來，最終決定View的measure大小是View的
setMeasuredDimension方法，所以我們可以通過setMeasuredDimension設(shè)定死值來設(shè)置View的
mMeasuredWidth和mMeasuredHeight的大小，但是一個(gè)好的自定義View應(yīng)該會(huì)根據(jù)子視圖的measureSpec來設(shè)置
mMeasuredWidth和mMeasuredHeight的大小，這樣的靈活性更大，所以這也就是上面分析onMeasure時(shí)說View的
onMeasure最好不要重寫死值的原因。
可以看見當(dāng)通過setMeasuredDimension方法最終設(shè)置完成View的measure之后View的mMeasuredWidth和
mMeasuredHeight成員才會(huì)有具體的數(shù)值，所以如果我們自定義的View或者使用現(xiàn)成的View想通過getMeasuredWidth()
和getMeasuredHeight()方法來獲取View測量的寬高，必須保證這兩個(gè)方法在onMeasure流程之后被調(diào)用才能返回有效值。
還記得前面《Android應(yīng)用setContentView與LayoutInflater加載解析機(jī)制源碼分析》文章3-3小節(jié)探討的inflate方法加載一些布局顯示時(shí)指定的大小失效問題嗎？當(dāng)時(shí)只給出了結(jié)論，現(xiàn)在給出了詳細(xì)原因分析，我想不需要再做過多解釋了吧。
至此整個(gè)View繪制流程的第一步就分析完成了，可以看見，相對(duì)來說還是比較復(fù)雜的，接下來進(jìn)行小結(jié)。
2-2 ?measure原理總結(jié)
通過上面分析可以看出measure過程主要就是從頂層父View向子View遞歸調(diào)用view.measure方法(measure中又回調(diào)onMeasure方法)的過程。具體measure核心主要有如下幾點(diǎn)：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è)計(jì)值來決定；View的measure方法是final的，不允許重載，View子類只能重載onMeasure來完成自己的測量邏輯。
最頂層DecorView測量時(shí)的MeasureSpec是由ViewRootImpl中g(shù)etRootMeasureSpec方法確定的
(LayoutParams寬高參數(shù)均為MATCH_PARENT，specMode是EXACTLY，specSize為物理屏幕大小)。
ViewGroup類提供了measureChild，measureChild和measureChildWithMargins方法，簡化了父子View的尺寸計(jì)算。
只要是ViewGroup的子類就必須要求LayoutParams繼承子MarginLayoutParams，否則無法使用layout_margin參數(shù)。
View的布局大小由父View和子View共同決定。
使用View的getMeasuredWidth()和getMeasuredHeight()方法來獲取View測量的寬高，必須保證這兩個(gè)方法在onMeasure流程之后被調(diào)用才能返回有效值。
3 View繪制流程第二步：遞歸layout源碼分析
在上面的背景介紹就說過，當(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，右下分別為上面剛剛測量的width和height。
至此又回歸到View的layout(int l, int t, int r, int b)方法中去實(shí)現(xiàn)具體邏輯了，所以接下來我們開始分析View的layout過程。
整個(gè)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方法實(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是不能在子類重寫的，言外之意就是說ViewGroup中只能通過重寫onLayout方法。那我們接下來看下
ViewGroup的onLayout方法，如下：@Override
protected?abstract?void?onLayout(boolean?changed,
int?l,?int?t,?int?r,?int?b);
看見沒有？ViewGroup的onLayout()方法竟然是一個(gè)抽象方法，這就是說所有ViewGroup的子類都必須重寫這個(gè)方法。所以在自
定義ViewGroup控件中，onLayout配合onMeasure方法一起使用可以實(shí)現(xiàn)自定義View的復(fù)雜布局。自定義View首先調(diào)用
onMeasure進(jìn)行測量，然后調(diào)用onLayout方法動(dòng)態(tài)獲取子View和子View的測量大小，然后進(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來確定每個(gè)子視圖在父視圖中的顯示位置。
再看下View的onLayout方法源碼，如下：protected?void?onLayout(boolean?changed,?int?left,?int?top,?int?right,?int?bottom)?{
}
我勒個(gè)去！是一個(gè)空方法，沒啥可看的。
既然這樣那我們只能分析一個(gè)現(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的，這個(gè)就是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
//計(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?
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計(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來安排子View在父View中顯示的位置，但這不是必須
的，measure過程得到的結(jié)果可能完全沒有實(shí)際用處，特別是對(duì)于一些自定義的ViewGroup，其子View的個(gè)數(shù)、位置和大小都是固定的，這時(shí)候
我們可以忽略整個(gè)measure過程，只在layout函數(shù)中傳入的4個(gè)參數(shù)來安排每個(gè)子View的具體位置。
到這里就不得不提getWidth()、getHeight()和getMeasuredWidth()、getMeasuredHeight()
這兩對(duì)方法之間的區(qū)別(上面分析measure過程已經(jīng)說過getMeasuredWidth()、getMeasuredHeight()必須在
onMeasure之后使用才有效)。可以看出來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é)束了，接下來進(jìn)行一些總結(jié)工作。
3-2 ?layout原理總結(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)測量過的measuredWidth和measuredHeight，layout操作
完成之后得到的是對(duì)每個(gè)View進(jìn)行位置分配后的mLeft、mTop、mRight、mBottom，這些值都是相對(duì)于父View來說的。
凡是layout_XXX的布局屬性基本都針對(duì)的是包含子View的ViewGroup的，當(dāng)對(duì)一個(gè)沒有父容器的View設(shè)置相關(guān)layout_XXX屬性是沒有任何意義的(前面《Android應(yīng)用setContentView與LayoutInflater加載解析機(jī)制源碼分析》也有提到過)。
使用View的getWidth()和getHeight()方法來獲取View測量的寬高，必須保證這兩個(gè)方法在onLayout流程之后被調(diào)用才能返回有效值。
4 View繪制流程第三步：遞歸draw源碼分析
在上面的背景介紹就說過，當(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來說就是PhoneWindow.DecorView，ViewRootImpl中的代碼會(huì)創(chuàng)
建一個(gè)Canvas對(duì)象，然后調(diào)用View的draw()方法來執(zhí)行具體的繪制工。所以又回歸到了ViewGroup與View的樹狀遞歸draw過程。
先來看下View樹的遞歸draw流程圖，如下：
如下我們詳細(xì)分析這一過程。
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);
......
}
看見整個(gè)View的draw方法很復(fù)雜，但是源碼注釋也很明顯。從注釋可以看出整個(gè)draw過程分為了6步。源碼注釋說(”skip step 2
& 5 if possible (common case)”)第2和5步可以跳過，所以我們接下來重點(diǎn)剩余四步。如下：
第一步，對(duì)View的背景進(jìn)行繪制。
可以看見，draw方法通過調(diào)運(yùn)drawBackground(canvas);方法實(shí)現(xiàn)了背景繪制。我們來看下這個(gè)方法源碼，如下：private?void?drawBackground(Canvas?canvas)?{
//獲取xml中通過android:background屬性或者代碼中setBackgroundColor()、setBackgroundResource()等方法進(jìn)行賦值的背景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);
......
}
第三步，對(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)行繪制。
我們來看下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è)空方法，而且注釋說明了如果View包含子類需要重寫他，所以我們有必要看下
ViewGroup的dispatchDraw方法源碼(這也就是剛剛說的對(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?
......
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()方法。所以說ViewGroup類已經(jīng)為我們重寫了dispatchDraw()的功能實(shí)現(xiàn)，我們一般不需要重寫該方法，但可以重載父類函數(shù)實(shí)現(xiàn)具體的功能。
第六步，對(duì)View的滾動(dòng)條進(jìn)行繪制。
可以看到，這里去調(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分析不是我們這篇的重點(diǎn)，所以暫時(shí)不做分析
......
}
可以看見其實(shí)任何一個(gè)View都是有(水平垂直)滾動(dòng)條的，只是一般情況下沒讓它顯示而已。
到此，View的draw繪制部分源碼分析完畢，我們接下來進(jìn)行一些總結(jié)。
4-2 ?draw原理總結(jié)
可以看見，繪制過程就是把View對(duì)象繪制到屏幕上，整個(gè)draw過程需要注意如下細(xì)節(jié)：如果該View是一個(gè)ViewGroup，則需要遞歸繪制其所包含的所有子View。
View默認(rèn)不會(huì)繪制任何內(nèi)容，真正的繪制都需要自己在子類中實(shí)現(xiàn)。
View的繪制是借助onDraw方法傳入的Canvas類來進(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()方法提供不同順序。
5 View的invalidate和postInvalidate方法源碼分析
你可能已經(jīng)看見了，在上面分析View的三步繪制流程中最后都有調(diào)運(yùn)一個(gè)叫invalidate的方法，這個(gè)方法是啥玩意？為何出現(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方法,針對(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,?[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方法，針對(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,
*?[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方法，針對(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?
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中說的，層層上級(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í)介紹說
過的，performTraversals就是整個(gè)View數(shù)開始繪制的起始調(diào)運(yùn)地方，所以說View調(diào)運(yùn)invalidate方法的實(shí)質(zhì)是層層上傳到父
級(jí)，直到傳遞到ViewRootImpl后觸發(fā)了scheduleTraversals方法，然后整個(gè)View樹開始重新按照上面分析的View繪制流程
進(jìn)行重繪任務(wù)。
到此View的invalidate方法原理就分析完成了。
5-2 ?postInvalidate方法源碼分析
上面分析invalidate方法時(shí)注釋中說該方法只能在UI Thread中執(zhí)行，其他線程中需要使用postInvalidate方法，所以我們來分析分析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();方法，那接下來View的invalidate();方法我們就不說了，上名已經(jīng)分析過了。
到此整個(gè)View的postInvalidate方法就分析完成了。
5-3 ?invalidate與postInvalidate方法總結(jié)
依據(jù)上面對(duì)View的invalidate分析我總結(jié)繪制如下流程圖：
依據(jù)上面對(duì)View的postInvalidate分析我總結(jié)繪制如下流程圖：
關(guān)于這兩個(gè)方法的具體流程和原理上面也分析過了，流程圖也給出了，相信已經(jīng)很明確了，沒啥需要解釋的了。所以我們對(duì)其做一個(gè)整體總結(jié)，歸納出重點(diǎn)如下：
invalidate系列方法請求重繪View樹(也就是draw方法)，如果View大小沒有發(fā)生變化就不會(huì)調(diào)用layout過程，并且只繪制那
些“需要重繪的”View，也就是哪個(gè)View(View只繪制該View，ViewGroup繪制整個(gè)ViewGroup)請求invalidate系
列方法，就繪制該View。
常見的引起invalidate方法操作的原因主要有：直接調(diào)用invalidate方法.請求重新draw，但只會(huì)繪制調(diào)用者本身。
觸發(fā)setSelection方法。請求重新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ì)請求measure過
程以及draw過程，同樣只繪制需要“重新繪制”的視圖。
觸發(fā)setEnabled方法。請求重新draw，但不會(huì)重新繪制任何View包括該調(diào)用者本身。
觸發(fā)requestFocus方法。請求View樹的draw過程，只繪制“需要重繪”的View。
5-4 ?通過invalidate方法分析結(jié)果回過頭去解決一個(gè)背景介紹中的疑惑
分析完invalidate后需要你回過頭去想一個(gè)問題。還記不記得這篇文章的開頭背景介紹，我們說整個(gè)View繪制流程的最初代碼是在
ViewRootImpl類的performTraversals()方法中開始的。上面當(dāng)時(shí)只是告訴你了這個(gè)結(jié)論，至于這個(gè)ViewRootImpl類
的performTraversals()方法為何會(huì)被觸發(fā)沒有說明原因。現(xiàn)在我們就來分析一下這個(gè)觸發(fā)的源頭。
讓我們先把大腦思考暫時(shí)挪回到《Android應(yīng)用setContentView與LayoutInflater加載解析機(jī)制源碼分析》這篇博文的setContentView機(jī)制分析中(不清楚的請點(diǎn)擊先看這篇文章再回過頭來繼續(xù)看)。我們先來看下那篇博文分析的PhoneWindow的setContentView方法源碼，如下：@Override
public?void?setContentView(View?view,?ViewGroup.LayoutParams?params)?{
......
//如果mContentParent為空進(jìn)行一些初始化，實(shí)質(zhì)mContentParent是通過findViewById(ID_ANDROID_CONTENT);獲取的id為content的FrameLayout的布局(不清楚的請先看《Android應(yīng)用setContentView與LayoutInflater加載解析機(jī)制源碼分析》文章)
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)魅朐摲椒?#xff0c;該方法會(huì)講我們界面通過addView追加到id為content的一個(gè)
FrameLayout(ViewGroup)中，然后addView方法中通過調(diào)運(yùn)invalidate(true)去通知觸發(fā)
ViewRootImpl類的performTraversals()方法，至此遞歸繪制我們自定義的所有布局。
6 View的requestLayout方法源碼分析
6-1 ?requestLayout方法分析
和invalidate類似，其實(shí)在上面分析View繪制流程時(shí)或多或少都調(diào)運(yùn)到了這個(gè)方法，而且這個(gè)方法對(duì)于View來說也比較重要，所以我們接下來分析一下他。如下View的requestLayout源碼：public?void?requestLayout()?{
......
if?(mParent?!=?null?&&?!mParent.isLayoutRequested())?{
//由此向ViewParent請求布局
//從這個(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ā)的方法不同而已。
6-2 ?requestLayout方法總結(jié)
可以看見，這些方法都是大同小異。對(duì)于requestLayout方法來說總結(jié)如下：
requestLayout()方法會(huì)調(diào)用measure過程和layout過程，不會(huì)調(diào)用draw過程，也不會(huì)重新繪制任何View包括該調(diào)用者本身。
7 View繪制流程總結(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)行查閱即可。
總結(jié)
以上是生活随笔為你收集整理的android字符显示流程图,Android应用层View绘制流程与源码分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Android绘制自定义控件,Andro
- 下一篇： android热更新插件,与Androi