android字符显示流程图,Android应用层View绘制流程与源码分析
1 ?背景
還記得前面《Android應用setContentView與LayoutInflater加載解析機制源碼分析》這篇文章嗎？我們有分析到Activity中界面加載顯示的基本流程原理，記不記得最終分析結果就是下面的關系：
看見沒有，如上圖中id為content的內容就是整個View樹的結構，所以對每個具體View對象的操作，其實就是個遞歸的實現。
前面《Android觸摸屏事件派發機制詳解與源碼分析一(View篇)》文
章的3-1小節說過Android中的任何一個布局、任何一個控件其實都是直接或間接繼承自View實現的，當然也包括我們后面一步一步引出的自定義控件
也不例外，所以說這些View應該都具有相同的繪制流程與機制才能顯示到屏幕上(因為他們都具備相同的父類View，可能每個控件的具體繪制邏輯有差異，
但是主流程都是一樣的)。經過總結發現每一個View的繪制過程都必須經歷三個最主要的過程，也就是measure、layout和draw。
既然一個View的繪制主要流程是這三步，那一定有一個開始地方呀，就像一個類從main函數執行一樣呀。對于View的繪制開始調運地方這里先給出結論，本文后面會反過來分析原因的，先往下看就行。具體結論如下：
整個View樹的繪圖流程是在ViewRootImpl類的performTraversals()方法(這個方法巨長)開始的，該函數做的執行過
程主要是根據之前設置的狀態，判斷是否重新計算視圖大小(measure)、是否重新放置視圖的位置(layout)、以及是否重繪
(draw)，其核心也就是通過判斷來選擇順序執行這三個方法中的哪個，如下：private?void?performTraversals()?{
......
//最外層的根視圖的widthMeasureSpec和heightMeasureSpec由來
//lp.width和lp.height在創建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的。上面傳入參數后這個函數走的是MATCH_PARENT，使用MeasureSpec.makeMeasureSpec方法組裝一個
MeasureSpec，MeasureSpec的specMode等于EXACTLY，specSize等于windowSize，也就是為何根視圖總
是全屏的原因。
其中的mView就是View對象。如下就是整個流程的大致流程圖：
如下我們就依據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)?{
......
//回調onMeasure()方法
onMeasure(widthMeasureSpec,?heightMeasureSpec);
......
}
看見注釋信息沒有，他告訴你了很多重要信息。為整個View樹計算實際的大小，然后設置實際的高和寬，每個View控件的實際寬高都是由父視圖和自
身決定的。實際的測量是在onMeasure方法進行，所以在View的子類需要重寫onMeasure方法，這是因為measure方法是final
的，不允許重載，所以View子類只能通過重載onMeasure來實現自己的測量邏輯。
這個方法的兩個參數都是父View傳遞過來的，也就是代表了父view的規格。他由兩部分組成，高16位表示MODE，定義在
MeasureSpec類(View的內部類)中，有三種類型，MeasureSpec.EXACTLY表示確定大小，
MeasureSpec.AT_MOST表示最大大小，
MeasureSpec.UNSPECIFIED不確定。低16位表示size，也就是父View的大小。對于系統Window類的DecorVIew對
象Mode一般都為MeasureSpec.EXACTLY
，而size分別對應屏幕寬高。對于子View來說大小是由父View和子View共同決定的。
在這里可以看出measure方法最終回調了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默認實現方法
protected?void?onMeasure(int?widthMeasureSpec,?int?heightMeasureSpec)?{
setMeasuredDimension(getDefaultSize(getSuggestedMinimumWidth(),?widthMeasureSpec),
getDefaultSize(getSuggestedMinimumHeight(),?heightMeasureSpec));
}
看見沒有，其實注釋已經很詳細了(自定義View重寫該方法的指導操作注釋都有說明)，不做過多解釋。
對于非ViewGroup的View而言，通過調用上面默認的onMeasure即可完成View的測量，當然你也可以重載onMeasure并調
用setMeasuredDimension來設置任意大小的布局，但一般不這么做，因為這種做法不太好，至于為何不好，后面分析完你就明白了。
我們可以看見onMeasure默認的實現僅僅調用了setMeasuredDimension，setMeasuredDimension函數是
一個很關鍵的函數，它對View的成員變量mMeasuredWidth和mMeasuredHeight變量賦值，measure的主要目的就是對
View樹中的每個View的mMeasuredWidth和mMeasuredHeight進行賦值，所以一旦這兩個變量被賦值意味著該View的測量
工作結束。既然這樣那我們就看看設置的默認尺寸大小吧，可以看見setMeasuredDimension傳入的參數都是通過
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，這就是系統默認的規格。
回過頭繼續看上面onMeasure方法，其中getDefaultSize參數的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尺寸與通過設置View的miniXXX屬性共同決定的。
到此一次最基礎的元素View的measure過程就完成了。上面說了View實際是嵌套的，而且measure是遞歸傳遞的，所以每個View都
需要measure。實際能夠嵌套的View一般都是ViewGroup的子類，所以在ViewGroup中定義了measureChildren,
measureChild,
measureChildWithMargins方法來對子視圖進行測量，measureChildren內部實質只是循環調用
measureChild，measureChild和measureChildWithMargins的區別就是是否把margin和padding也
作為子視圖的大小。如下我們以ViewGroup中稍微復雜的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();
//調整MeasureSpec
//通過這兩個參數以及子視圖本身的LayoutParams來共同決定子視圖的測量規格
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);
//調運子View的measure方法，子View的measure中會回調子View的onMeasure方法
child.measure(childWidthMeasureSpec,?childHeightMeasureSpec);
}
關于該方法的參數等說明注釋已經描述的夠清楚了。該方法就是對父視圖提供的measureSpec參數結合自身的LayoutParams參數進行了調
整，然后再來調用child.measure()方法，具體通過方法getChildMeasureSpec來進行參數調整。所以我們繼續看下
getChildMeasureSpec方法代碼，如下：public?static?int?getChildMeasureSpec(int?spec,?int?padding,?int?childDimension)?{
//獲取當前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;
//依據當前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的數值
//設置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.
//設置child的size為size，mode為EXACTLY
resultSize?=?size;
resultMode?=?MeasureSpec.EXACTLY;
}?else?if?(childDimension?==?LayoutParams.WRAP_CONTENT)?{
//如果child的layout_wOrh屬性在xml或者java中給予WRAP_CONTENT
//設置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位整數返回
return?MeasureSpec.makeMeasureSpec(resultSize,?resultMode);
}
可以看見，getChildMeasureSpec的邏輯是通過其父View提供的MeasureSpec參數得到specMode和
specSize，然后根據計算出來的specMode以及子View的childDimension(layout_width或
layout_height)來計算自身的measureSpec，如果其本身包含子視圖，則計算出來的measureSpec將作為調用其子視圖
measure函數的參數，同時也作為自身調用setMeasuredDimension的參數，如果其不包含子視圖則默認情況下最終會調用
onMeasure的默認實現，并最終調用到setMeasuredDimension。
所以可以看見onMeasure的參數其實就是這么計算出來的。同時從上面的分析可以看出來，最終決定View的measure大小是View的
setMeasuredDimension方法，所以我們可以通過setMeasuredDimension設定死值來設置View的
mMeasuredWidth和mMeasuredHeight的大小，但是一個好的自定義View應該會根據子視圖的measureSpec來設置
mMeasuredWidth和mMeasuredHeight的大小，這樣的靈活性更大，所以這也就是上面分析onMeasure時說View的
onMeasure最好不要重寫死值的原因。
可以看見當通過setMeasuredDimension方法最終設置完成View的measure之后View的mMeasuredWidth和
mMeasuredHeight成員才會有具體的數值，所以如果我們自定義的View或者使用現成的View想通過getMeasuredWidth()
和getMeasuredHeight()方法來獲取View測量的寬高，必須保證這兩個方法在onMeasure流程之后被調用才能返回有效值。
還記得前面《Android應用setContentView與LayoutInflater加載解析機制源碼分析》文章3-3小節探討的inflate方法加載一些布局顯示時指定的大小失效問題嗎？當時只給出了結論，現在給出了詳細原因分析，我想不需要再做過多解釋了吧。
至此整個View繪制流程的第一步就分析完成了，可以看見，相對來說還是比較復雜的，接下來進行小結。
2-2 ?measure原理總結
通過上面分析可以看出measure過程主要就是從頂層父View向子View遞歸調用view.measure方法(measure中又回調onMeasure方法)的過程。具體measure核心主要有如下幾點：MeasureSpec(View的內部類)測量規格為int型，值由高16位規格模式specMode和低16位具體尺寸specSize組成。其中specMode只有三種值：MeasureSpec.EXACTLY?//確定模式，父View希望子View的大小是確定的，由specSize決定；
MeasureSpec.AT_MOST?//最多模式，父View希望子View的大小最多是specSize指定的值；
MeasureSpec.UNSPECIFIED?//未指定模式，父View完全依據子View的設計值來決定；View的measure方法是final的，不允許重載，View子類只能重載onMeasure來完成自己的測量邏輯。
最頂層DecorView測量時的MeasureSpec是由ViewRootImpl中getRootMeasureSpec方法確定的
(LayoutParams寬高參數均為MATCH_PARENT，specMode是EXACTLY，specSize為物理屏幕大小)。
ViewGroup類提供了measureChild，measureChild和measureChildWithMargins方法，簡化了父子View的尺寸計算。
只要是ViewGroup的子類就必須要求LayoutParams繼承子MarginLayoutParams，否則無法使用layout_margin參數。
View的布局大小由父View和子View共同決定。
使用View的getMeasuredWidth()和getMeasuredHeight()方法來獲取View測量的寬高，必須保證這兩個方法在onMeasure流程之后被調用才能返回有效值。
3 View繪制流程第二步：遞歸layout源碼分析
在上面的背景介紹就說過，當ViewRootImpl的performTraversals中measure執行完成以后會接著執行mView.layout，具體如下：private?void?performTraversals()?{
......
mView.layout(0,?0,?mView.getMeasuredWidth(),?mView.getMeasuredHeight());
......
}
可以看見layout方法接收四個參數，這四個參數分別代表相對Parent的左、上、右、下坐標。而且還可以看見左上都為0，右下分別為上面剛剛測量的width和height。
至此又回歸到View的layout(int l, int t, int r, int b)方法中去實現具體邏輯了，所以接下來我們開始分析View的layout過程。
整個View樹的layout遞歸流程圖如下：
3-1 ?layout源碼分析
layout既然也是遞歸結構，那我們先看下ViewGroup的layout方法，如下：@Override
public?final?void?layout(int?l,?int?t,?int?r,?int?b)?{
......
super.layout(l,?t,?r,?b);
......
}
看著沒有？ViewGroup的layout方法實質還是調運了View父類的layout方法，所以我們看下View的layout源碼，如下：public?void?layout(int?l,?int?t,?int?r,?int?b)?{
......
//實質都是調用setFrame方法把參數分別賦值給mLeft、mTop、mRight和mBottom這幾個變量
//判斷View的位置是否發生過變化，以確定有沒有必要對當前的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)?{
//回調onLayout
onLayout(changed,?l,?t,?r,?b);
......
}
......
}
看見沒有，類似measure過程，lauout調運了onLayout方法。
對比上面View的layout和ViewGroup的layout方法可以發現，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方法一起使用可以實現自定義View的復雜布局。自定義View首先調用
onMeasure進行測量，然后調用onLayout方法動態獲取子View和子View的測量大小，然后進行layout布局。重載onLayout
的目的就是安排其children在父View的具體位置，重載onLayout通常做法就是寫一個for循環調用每一個子視圖的layout(l,
t, r, b)函數，傳入不同的參數l, t, r, b來確定每個子視圖在父視圖中的顯示位置。
再看下View的onLayout方法源碼，如下：protected?void?onLayout(boolean?changed,?int?left,?int?top,?int?right,?int?bottom)?{
}
我勒個去！是一個空方法，沒啥可看的。
既然這樣那我們只能分析一個現有的繼承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屬性
設置的，我們為例說明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右側位置
int?childRight?=?width?-?mPaddingRight;
//?Space?available?for?child
//child可使用空間大小
int?childSpace?=?width?-?paddingLeft?-?mPaddingRight;
//通過ViewGroup的getChildCount方法獲取ViewGroup的子View個數
final?int?count?=?getVirtualChildCount();
//獲取Gravity屬性設置
final?int?majorGravity?=?mGravity?&?Gravity.VERTICAL_GRAVITY_MASK;
final?int?minorGravity?=?mGravity?&?Gravity.RELATIVE_HORIZONTAL_GRAVITY_MASK;
//依據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);
//依據不同的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;
//通過垂直排列計算調運child的layout設置child的位置
setChildFrame(child,?childLeft,?childTop?+?getLocationOffset(child),
childWidth,?childHeight);
childTop?+=?childHeight?+?lp.bottomMargin?+?getNextLocationOffset(child);
i?+=?getChildrenSkipCount(child,?i);
}
}
}
從上面分析的ViewGroup子類LinearLayout的onLayout實現代碼可以看出，一般情況下layout過程會參考
measure過程中計算得到的mMeasuredWidth和mMeasuredHeight來安排子View在父View中顯示的位置，但這不是必須
的，measure過程得到的結果可能完全沒有實際用處，特別是對于一些自定義的ViewGroup，其子View的個數、位置和大小都是固定的，這時候
我們可以忽略整個measure過程，只在layout函數中傳入的4個參數來安排每個子View的具體位置。
到這里就不得不提getWidth()、getHeight()和getMeasuredWidth()、getMeasuredHeight()
這兩對方法之間的區別(上面分析measure過程已經說過getMeasuredWidth()、getMeasuredHeight()必須在
onMeasure之后使用才有效)。可以看出來getWidth()與getHeight()方法必須在layout(int l, int t,
int r, int b)執行之后才有效。那我們看下View源碼中這些方法的實現吧，如下：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過程分析就算結束了，接下來進行一些總結工作。
3-2 ?layout原理總結
整個layout過程比較容易理解，從上面分析可以看出layout也是從頂層父View向子View的遞歸調用view.layout方法的過
程，即父View根據上一步measure子View所得到的布局大小和布局參數，將子View放在合適的位置上。具體layout核心主要有以下幾點：View.layout方法可被重載，ViewGroup.layout為final的不可重載，ViewGroup.onLayout為abstract的，子類必須重載實現自己的位置邏輯。
measure操作完成后得到的是對每個View經測量過的measuredWidth和measuredHeight，layout操作
完成之后得到的是對每個View進行位置分配后的mLeft、mTop、mRight、mBottom，這些值都是相對于父View來說的。
凡是layout_XXX的布局屬性基本都針對的是包含子View的ViewGroup的，當對一個沒有父容器的View設置相關layout_XXX屬性是沒有任何意義的(前面《Android應用setContentView與LayoutInflater加載解析機制源碼分析》也有提到過)。
使用View的getWidth()和getHeight()方法來獲取View測量的寬高，必須保證這兩個方法在onLayout流程之后被調用才能返回有效值。
4 View繪制流程第三步：遞歸draw源碼分析
在上面的背景介紹就說過，當ViewRootImpl的performTraversals中measure和layout執行完成以后會接著執行mView.layout，具體如下：private?void?performTraversals()?{
......
final?Rect?dirty?=?mDirty;
......
canvas?=?mSurface.lockCanvas(dirty);
......
mView.draw(canvas);
......
}
draw過程也是在ViewRootImpl的performTraversals()內部調運的，其調用順序在measure()和
layout()之后，這里的mView對于Actiity來說就是PhoneWindow.DecorView，ViewRootImpl中的代碼會創
建一個Canvas對象，然后調用View的draw()方法來執行具體的繪制工。所以又回歸到了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方法很復雜，但是源碼注釋也很明顯。從注釋可以看出整個draw過程分為了6步。源碼注釋說(”skip step 2
& 5 if possible (common case)”)第2和5步可以跳過，所以我們接下來重點剩余四步。如下：
第一步，對View的背景進行繪制。
可以看見，draw方法通過調運drawBackground(canvas);方法實現了背景繪制。我們來看下這個方法源碼，如下：private?void?drawBackground(Canvas?canvas)?{
//獲取xml中通過android:background屬性或者代碼中setBackgroundColor()、setBackgroundResource()等方法進行賦值的背景Drawable
final?Drawable?background?=?mBackground;
......
//根據layout過程確定的View位置來設置背景的繪制區域
if?(mBackgroundSizeChanged)?{
background.setBounds(0,?0,??mRight?-?mLeft,?mBottom?-?mTop);
mBackgroundSizeChanged?=?false;
rebuildOutline();
}
......
//調用Drawable的draw()方法來完成背景的繪制工作
background.draw(canvas);
......
}
第三步，對View的內容進行繪制。
可以看到，這里去調用了一下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的內容部分是各不相同的，所以需要由子類去實現具體邏輯。
第四步，對當前View的所有子View進行繪制，如果當前的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方法源碼(這也就是剛剛說的對當前View的所有子View進行繪制，如果當前的View沒有子View就
不需要進行繪制的原因，因為如果是View調運該方法是空的，而ViewGroup才有實現)，如下：@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()方法，該方法內部會遍歷每個子View，然后調用drawChild()方法，我們可以看下ViewGroup的drawChild方法，如下：protected?boolean?drawChild(Canvas?canvas,?View?child,?long?drawingTime)?{
return?child.draw(canvas,?this,?drawingTime);
}
可以看見drawChild()方法調運了子View的draw()方法。所以說ViewGroup類已經為我們重寫了dispatchDraw()的功能實現，我們一般不需要重寫該方法，但可以重載父類函數實現具體的功能。
第六步，對View的滾動條進行繪制。
可以看到，這里去調用了一下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繪制部分源碼分析完畢，我們接下來進行一些總結。
4-2 ?draw原理總結
可以看見，繪制過程就是把View對象繪制到屏幕上，整個draw過程需要注意如下細節：如果該View是一個ViewGroup，則需要遞歸繪制其所包含的所有子View。
View默認不會繪制任何內容，真正的繪制都需要自己在子類中實現。
View的繪制是借助onDraw方法傳入的Canvas類來進行的。
區分View動畫和ViewGroup布局動畫，前者指的是View自身的動畫，可以通過setAnimation添加，后者是專門針對
ViewGroup顯示內部子視圖時設置的動畫，可以在xml布局文件中對ViewGroup設置layoutAnimation屬性(譬如對
LinearLayout設置子View在顯示時出現逐行、隨機、下等顯示等不同動畫效果)。
在獲取畫布剪切區(每個View的draw中傳入的Canvas)時會自動處理掉padding，子View獲取Canvas不用關注這些邏輯，只用關心如何繪制即可。
默認情況下子View的ViewGroup.drawChild繪制順序和子View被添加的順序一致，但是你也可以重載ViewGroup.getChildDrawingOrder()方法提供不同順序。
5 View的invalidate和postInvalidate方法源碼分析
你可能已經看見了，在上面分析View的三步繪制流程中最后都有調運一個叫invalidate的方法，這個方法是啥玩意？為何出現頻率這么高？很簡單，我們拿出來分析分析不就得了。
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是可見的才有效，回調onDraw方法,針對局部View
public?void?invalidate(Rect?dirty)?{
final?int?scrollX?=?mScrollX;
final?int?scrollY?=?mScrollY;
//實質還是調運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是可見的才有效，回調onDraw方法，針對局部View
public?void?invalidate(int?l,?int?t,?int?r,?int?b)?{
final?int?scrollX?=?mScrollX;
final?int?scrollY?=?mScrollY;
//實質還是調運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是可見的才有效，回調onDraw方法，針對整個View
public?void?invalidate()?{
//invalidate的實質還是調運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的權限，只能在UI?Thread中使用，別的Thread用postInvalidate方法，View是可見的才有效，回調onDraw方法，針對整個View
void?invalidate(boolean?invalidateCache)?{
//實質還是調運invalidateInternal方法
invalidateInternal(0,?0,?mRight?-?mLeft,?mBottom?-?mTop,?invalidateCache,?true);
}
//！！！！！！看見沒有，這是所有invalidate的終極調運方法！！！！！！
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;
//設置刷新區域
damage.set(l,?t,?r,?b);
//傳遞調運Parent?ViewGroup的invalidateChild方法
p.invalidateChild(this,?damage);
}
......
}
看見沒有，View的invalidate(invalidateInternal)方法實質是將要刷新區域直接傳遞給了父ViewGroup的
invalidateChild方法，在invalidate中，調用父View的invalidateChild，這是一個從當前向上級父View回溯
的過程，每一層的父View都將自己的顯示區域與傳入的刷新Rect做交集
。所以我們看下ViewGroup的invalidateChild方法，源碼如下：public?final?void?invalidateChild(View?child,?final?Rect?dirty)?{
ViewParent?parent?=?this;
final?AttachInfo?attachInfo?=?mAttachInfo;
......
do?{
......
//循環層層上級調運，直到ViewRootImpl會返回null
parent?=?parent.invalidateChildInParent(location,?dirty);
......
}?while?(parent?!=?null);
}
這個過程最后傳遞到ViewRootImpl的invalidateChildInParent方法結束，所以我們看下ViewRootImpl的invalidateChildInParent方法，如下：@Override
public?ViewParent?invalidateChildInParent(int[]?location,?Rect?dirty)?{
......
//View調運invalidate最終層層上傳到ViewRootImpl后最終觸發了該方法
scheduleTraversals();
......
return?null;
}
看見沒有？這個ViewRootImpl類的invalidateChildInParent方法直接返回了null，也就是上面
ViewGroup中說的，層層上級傳遞到ViewRootImpl的invalidateChildInParent方法結束了那個do
while循環。看見這里調運的scheduleTraversals這個方法嗎？scheduleTraversals會通過Handler的
Runnable發送一個異步消息，調運doTraversal方法，然后最終調用performTraversals()執行重繪。開頭背景知識介紹說
過的，performTraversals就是整個View數開始繪制的起始調運地方，所以說View調運invalidate方法的實質是層層上傳到父
級，直到傳遞到ViewRootImpl后觸發了scheduleTraversals方法，然后整個View樹開始重新按照上面分析的View繪制流程
進行重繪任務。
到此View的invalidate方法原理就分析完成了。
5-2 ?postInvalidate方法源碼分析
上面分析invalidate方法時注釋中說該方法只能在UI Thread中執行，其他線程中需要使用postInvalidate方法，所以我們來分析分析postInvalidate這個方法源碼。如下：public?void?postInvalidate()?{
postInvalidateDelayed(0);
}
繼續看下他的調運方法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;
//核心，實質就是調運了ViewRootImpl.dispatchInvalidateDelayed方法
if?(attachInfo?!=?null)?{
attachInfo.mViewRootImpl.dispatchInvalidateDelayed(this,?delayMilliseconds);
}
}
我們繼續看他調運的ViewRootImpl類的dispatchInvalidateDelayed方法，如下源碼：public?void?dispatchInvalidateDelayed(View?view,?long?delayMilliseconds)?{
Message?msg?=?mHandler.obtainMessage(MSG_INVALIDATE,?view);
mHandler.sendMessageDelayed(msg,?delayMilliseconds);
}
看見沒有，通過ViewRootImpl類的Handler發送了一條MSG_INVALIDATE消息，繼續追蹤這條消息的處理可以發現：public?void?handleMessage(Message?msg)?{
......
switch?(msg.what)?{
case?MSG_INVALIDATE:
((View)?msg.obj).invalidate();
break;
......
}
......
}
看見沒有，實質就是又在UI Thread中調運了View的invalidate();方法，那接下來View的invalidate();方法我們就不說了，上名已經分析過了。
到此整個View的postInvalidate方法就分析完成了。
5-3 ?invalidate與postInvalidate方法總結
依據上面對View的invalidate分析我總結繪制如下流程圖：
依據上面對View的postInvalidate分析我總結繪制如下流程圖：
關于這兩個方法的具體流程和原理上面也分析過了，流程圖也給出了，相信已經很明確了，沒啥需要解釋的了。所以我們對其做一個整體總結，歸納出重點如下：
invalidate系列方法請求重繪View樹(也就是draw方法)，如果View大小沒有發生變化就不會調用layout過程，并且只繪制那
些“需要重繪的”View，也就是哪個View(View只繪制該View，ViewGroup繪制整個ViewGroup)請求invalidate系
列方法，就繪制該View。
常見的引起invalidate方法操作的原因主要有：直接調用invalidate方法.請求重新draw，但只會繪制調用者本身。
觸發setSelection方法。請求重新draw，但只會繪制調用者本身。
觸發setVisibility方法。
當View可視狀態在INVISIBLE轉換VISIBLE時會間接調用invalidate方法，繼而繪制該View。當View的可視狀態在
INVISIBLE\VISIBLE
轉換為GONE狀態時會間接調用requestLayout和invalidate方法，同時由于View樹大小發生了變化，所以會請求measure過
程以及draw過程，同樣只繪制需要“重新繪制”的視圖。
觸發setEnabled方法。請求重新draw，但不會重新繪制任何View包括該調用者本身。
觸發requestFocus方法。請求View樹的draw過程，只繪制“需要重繪”的View。
5-4 ?通過invalidate方法分析結果回過頭去解決一個背景介紹中的疑惑
分析完invalidate后需要你回過頭去想一個問題。還記不記得這篇文章的開頭背景介紹，我們說整個View繪制流程的最初代碼是在
ViewRootImpl類的performTraversals()方法中開始的。上面當時只是告訴你了這個結論，至于這個ViewRootImpl類
的performTraversals()方法為何會被觸發沒有說明原因。現在我們就來分析一下這個觸發的源頭。
讓我們先把大腦思考暫時挪回到《Android應用setContentView與LayoutInflater加載解析機制源碼分析》這篇博文的setContentView機制分析中(不清楚的請點擊先看這篇文章再回過頭來繼續看)。我們先來看下那篇博文分析的PhoneWindow的setContentView方法源碼，如下：@Override
public?void?setContentView(View?view,?ViewGroup.LayoutParams?params)?{
......
//如果mContentParent為空進行一些初始化，實質mContentParent是通過findViewById(ID_ANDROID_CONTENT);獲取的id為content的FrameLayout的布局(不清楚的請先看《Android應用setContentView與LayoutInflater加載解析機制源碼分析》文章)
if?(mContentParent?==?null)?{
installDecor();
}
......
//把我們的view追加到mContentParent
mContentParent.addView(view,?params);
......
}
這個方法是Activity中setContentView的實現，我們繼續看下這個方法里調運的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();
//重點關注！！！
invalidate(true);
......
}
看見addView調運invalidate方法沒有？這不就真相大白了。當我們寫一個Activity時，我們一定會通過
setContentView方法將我們要展示的界面傳入該方法，該方法會講我們界面通過addView追加到id為content的一個
FrameLayout(ViewGroup)中，然后addView方法中通過調運invalidate(true)去通知觸發
ViewRootImpl類的performTraversals()方法，至此遞歸繪制我們自定義的所有布局。
6 View的requestLayout方法源碼分析
6-1 ?requestLayout方法分析
和invalidate類似，其實在上面分析View繪制流程時或多或少都調運到了這個方法，而且這個方法對于View來說也比較重要，所以我們接下來分析一下他。如下View的requestLayout源碼：public?void?requestLayout()?{
......
if?(mParent?!=?null?&&?!mParent.isLayoutRequested())?{
//由此向ViewParent請求布局
//從這個View開始向上一直requestLayout，最終到達ViewRootImpl的requestLayout
mParent.requestLayout();
}
......
}
看見沒有，當我們觸發View的requestLayout時其實質就是層層向上傳遞，直到ViewRootImpl為止，然后觸發ViewRootImpl的requestLayout方法，如下就是ViewRootImpl的requestLayout方法：@Override
public?void?requestLayout()?{
if?(!mHandlingLayoutInLayoutRequest)?{
checkThread();
mLayoutRequested?=?true;
//View調運requestLayout最終層層上傳到ViewRootImpl后最終觸發了該方法
scheduleTraversals();
}
}
看見沒有，類似于上面分析的invalidate過程，只是設置的標記不同，導致對于View的繪制流程中觸發的方法不同而已。
6-2 ?requestLayout方法總結
可以看見，這些方法都是大同小異。對于requestLayout方法來說總結如下：
requestLayout()方法會調用measure過程和layout過程，不會調用draw過程，也不會重新繪制任何View包括該調用者本身。
7 View繪制流程總結
至此整個關于Android應用程序開發中的View繪制機制及相關重要方法都已經分析完畢。關于各個方法的總結這里不再重復，直接通過該文章前面的目錄索引到相應方法的總結小節進行查閱即可。
總結
以上是生活随笔為你收集整理的android字符显示流程图,Android应用层View绘制流程与源码分析的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Android绘制自定义控件,Andro
- 下一篇： android热更新插件,与Androi