View的工作流程主要是指measure、layout、draw這三大流程，即測量、佈局和繪製，其中measure確定View的測量寬高，layout確定View的最終寬高和四個頂點的位置，而draw則將View繪製到屏幕上。
1.measure過程
measure過程要分情況來看，如果只是一個原始的View，那麼通過measure方法就完成了其測量過程，如果是一個ViewGroup，出了完成自己的測量過程外，還會遍歷去調用所有的子元素的measure方法，各個子元素再遞歸去執行這個流程，下面針對這兩種情況分別討論。
1.1View的measure過程
View的measure過程由其measure方法來完成，measure方法是一個final類型的方法，這意味着子類不能重寫此方法，在View的onMeasure方法，因此只需要看onMeasure的實現即可，View的onMeasure方法如下所示。
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
setMeasuredDimension(getDefaultSize(getSuggestedMinimumWidth(), widthMeasureSpec),
getDefaultSize(getSuggestedMinimumHeight(), heightMeasureSpec));
}上述代碼很簡潔，但是簡潔並不代表簡單，setMeasuredDimension方法會設置View寬高的測量值，因此我們只需要看getDefaultSize這個方法即可：
public static int getDefaultSize(int size, int measureSpec) {
int result = 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;
}可以看出，getDefaultSize這個方法的邏輯很簡單，對於我們來說，我們只需要看AT_MOST和EXACTLY這兩種情況。簡單地理解，其實getDefaultSize返回的大小就是measureSpec中的specSize，而這個specSize就是View測量後的大小，這裏多次提到測量後的大小，是因爲View最終的大小是在layout階段確定，所以這裏必須要加以區分，但是幾乎所有情況下View的測量大小和最終大小是相等的。
至於UNSPECIFIED這種情況，一般用於系統內部的測量過程，在這種情況下，View的大小爲getDefaultSize的第一個參數size，即寬高分別爲getSuggestedMinimumWidth和getSuggestedMinimumHeight這兩個方法的返回值，看一下它們的源碼：
protected int getSuggestedMinimumHeight() {
return (mBackground == null) ? mMinHeight : max(mMinHeight, mBackground.getMinimumHeight());
}
protected int getSuggestedMinimumWidth() {
return (mBackground == null) ? mMinWidth : max(mMinWidth, mBackground.getMinimumWidth());
}這裏只分析getSuggestedMinimumWidth方法的實現，getSuggestedMinimumHeight和它實現原理是一樣的。getSuggestedMinimumWidth的代碼可以看出，如果View沒有設置背景，那麼View的寬度爲mMinWidth，而mMinWidth對應於android:minWidth這個屬性所指的值，因此View的寬度即爲android:minWidth屬性所指定的值。這個屬性如果不指定，那麼mMinWidth則默認爲0；如果View指定了背景，則View的寬度爲max(mMinWidth,mBackground.getMinimumWidth())。mMinWidth的含義我們已經知道了，那麼mBackground.getMinimumWidth()是什麼呢？我們看一下Drawable的getMinimunWidth方法，如下所示。
public int getMinimumWidth() {
final int intrinsicWidth = getIntrinsicWidth();
return intrinsicWidth > 0 ? intrinsicWidth : 0;
}可以看出，getMinimumWidth()返回的就是Drawable的原始寬度，前提是這個Drawable有原始寬度，否則就返回0。那麼Drawable在什麼情況下有原始寬度呢？這裏先舉個例子說明一下，ShapeDrawable無原始寬高，而BitmapDrawable有原始寬高(圖片的尺寸)，詳細內容會在後續章節進行介紹。
這裏再總結一下getSuggestedMinimumWidth的邏輯：如果View沒有設置背景，那麼返回android:minWidth這個屬性所指定的值，這個值可以爲0；如果View設置了背景，則返回android:minWidth和背景的最小寬度這兩種中的最大值，getSuggestedMinimumWidth和getSuggestedMinimumHeight的返回值就是View再UNSPECIFIED情況下的測量寬高。
從getDefaultSize方法的實現來看，View的寬高由specSize決定，所以我們可以得出如下結論：直接繼承View的自定義控件需要重寫onMeasure方法並設置wrap_content時的自身大小，否則再佈局中使用wrap_content就相當於使用match_parent。爲什麼呢？這個原因需要結合上述代碼和上表才能更好地理解。從上述代碼中我們知道，如果View在佈局中使用wrap_content，那麼它的specMode是AT_MOST模式，在這種模式下，它的寬高等於specSize；查看上表可以知道，這種情況下View的specSize是parentSize，而parentSize是父容器中目前可以使用的帶線啊哦，也就是父容器當前剩餘的控件大小。很顯然，View的寬高就等於父容器當前剩餘的控件大小，這種效果和在佈局中使用match_parent完全一致。如何解決這個問題呢？也很簡單，如下所示。
@Override
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
super.onMeasure(widthMeasureSpec, heightMeasureSpec);
int widthSpecMode = MeasureSpec.getMode(widthMeasureSpec);
int widthSpecSize = MeasureSpec.getSize(widthMeasureSpec);
int heightSpecMode = MeasureSpec.getMode(heightMeasureSpec);
int heightSpecSize = MeasureSpec.getSize(heightMeasureSpec);
if (widthSpecMode == MeasureSpec.AT_MOST && heightSpecMode == MeasureSpec.AT_MOST){
setMeasuredDimension(mWidth,mHeight);
} else if (widthSpecMode == MeasureSpec.AT_MOST) {
setMeasuredDimension(mWidth,heightSpecSize);
} else if (heightSpecMode == MeasureSpec.AT_MOST) {
setMeasuredDimension(widthSpecSize,mHeight);
}
}在上面的代碼中，我們只需要給View指定一個默認的內部跨高(mWidth和mHeight)，並在wrap_content時設置此寬高即可。對於非wrap_content情形，我們沿用系統的測量值即可，至於這個默認的內部寬高的大小如何指定，這個沒有固定的依據，根基需要靈活指定即可。如果查看TextView、ImageView等源碼就可以知道，針對wrap_content情形，它們的onMeasure方法均做了特殊處理，讀者可以自行查看它們的源碼。
1.2.ViewGroup的measure過程
對於ViewGroup來說，除了完成自己的measure過程外，還會遍歷去調用所有子元素的measure方法，各個子元素再遞歸去執行這個過程。和View不同的是，ViewGroup是一個抽象類，因此它沒有重寫View的onMeasure方法，但它提供了一個角measureChildren的方法，如下所示。
protected void measureChildren(int widthMeasureSpec, int heightMeasureSpec) {
final int size = mChildrenCount;
final View[] children = mChildren;
for (int i = 0; i < size; ++i) {
final View child = children[i];
if ((child.mViewFlags & VISIBILITY_MASK) != GONE) {
measureChild(child, widthMeasureSpec, heightMeasureSpec);
}
}
}從上述代碼來看，ViewGroup在measure時，會對每一個子元素進行measure，measureChild這個方法的實現也很好理解，如下所示。
protected void measureChild(View child, int parentWidthMeasureSpec,
int parentHeightMeasureSpec) {
final LayoutParams lp = child.getLayoutParams();
final int childWidthMeasureSpec = getChildMeasureSpec(parentWidthMeasureSpec,
mPaddingLeft + mPaddingRight, lp.width);
final int childHeightMeasureSpec = getChildMeasureSpec(parentHeightMeasureSpec,
mPaddingTop + mPaddingBottom, lp.height);
child.measure(childWidthMeasureSpec, childHeightMeasureSpec);
}很顯然，measureChild的思想就是取出子元素的LayoutParams，然後通過getChildMeasureSpec來創建子元素的MeasureSpec，接着將MeasureSpec直接傳遞給View的measure方法來進行測量。getChildMeasureSpec的工作過程已經在上面進行了詳細分析，通過上表可以更清晰地瞭解它地邏輯。
我們知道，ViewGroup並沒有定義其測量地具體過程，這是因爲ViewGroup是一個抽象類，其測量過程地onMeasure方法需要各個子類去具體實現，比如LinearLayout、RelativeLayout等，爲什麼ViewGroup不像View一樣對其onMeasure方法做統一的實現呢？那是因爲不同的ViewGroup子類有不同的佈局特性，這導致它們的測量細節各不相同，比如LinearLayout和RelativeLayout這兩者的佈局特性顯然不同，因此ViewGroup無法做統一實現。下面就通過LinearLayout的onMeasure方法來分析ViewGroup的Measure過程，其他Layout類型可以自行分析。
首先來看LinearLayout的onMeasure方法，如下所示。
@Override
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
if (mOrientation == VERTICAL) {
measureVertical(widthMeasureSpec, heightMeasureSpec);
} else {
measureHorizontal(widthMeasureSpec, heightMeasureSpec);
}
}上述代碼很簡單，我們選擇一個來看一下，比如選擇查看豎直佈局的LinearLayout的測量過程，即measureVertical方法，measureVertical的源碼比較長，下面只描述其大概邏輯，首先看一段代碼：
void measureVertical(int widthMeasureSpec, int heightMeasureSpec) {
// See how tall everyone is. Also remember max width.
for (int i = 0; i < count; ++i) {
final View child = getVirtualChildAt(i);
...
// Determine how big this child would like to be. If this or
// previous children have given a weight, then we allow it to
// use all available space (and we will shrink things later
// if needed).
final int usedHeight = totalWeight == 0 ? mTotalLength : 0;
measureChildBeforeLayout(child, i, widthMeasureSpec, 0,
heightMeasureSpec, usedHeight);
final int childHeight = child.getMeasuredHeight();
if (useExcessSpace) {
// Restore the original height and record how much space
// we've allocated to excess-only children so that we can
// match the behavior of EXACTLY measurement.
lp.height = 0;
consumedExcessSpace += childHeight;
}
final int totalLength = mTotalLength;
mTotalLength = Math.max(totalLength, totalLength + childHeight + lp.topMargin +
lp.bottomMargin + getNextLocationOffset(child));
if (useLargestChild) {
largestChildHeight = Math.max(childHeight, largestChildHeight);
}
}
...
}從上面的代碼可以看出，系統會遍歷子元素並對每個子元素執行measureChildBeforeLayout方法，這個方法內部會調用子元素的measure方法，這樣各個子元素就開始依次進入measure方法，這樣各個子元素就開始依次進入measure過程，並且系統會通過mTotalLength這個變量來存儲LinearLayout在豎直方向的初步高度。每測量一個子元素，mTotalLength就會增加，增加的部分主要包括子元素的高度以及子元素在豎直方向上的margin等。當子元素測量完畢後，LinearLayout會測量自己的大小，源碼如下所示。
// Add in our padding
mTotalLength += mPaddingTop + mPaddingBottom;
int heightSize = mTotalLength;
// Check against our minimum height
heightSize = Math.max(heightSize, getSuggestedMinimumHeight());
// Reconcile our calculated size with the heightMeasureSpec
int heightSizeAndState = resolveSizeAndState(heightSize, heightMeasureSpec, 0);
heightSize = heightSizeAndState & MEASURED_SIZE_MASK;
...
setMeasuredDimension(resolveSizeAndState(maxWidth, widthMeasureSpec, childState),
heightSizeAndState);這裏對上述代碼進行說明，當子元素測量完畢後，LinearLayout會根據子元素的清空來測量自己的大小。針對，它在水平方向的測量過程遵循View的測量過程，在豎直方向的測量過程則和View有所不同。具體來說是指，如果它的佈局中高度採用的是match_parent或者具體數值，那麼它的測量過程和View一致，即高度爲specSize；如果它的佈局中高度採用的是wrap_content，那麼它的高度是所有子元素所佔用的高度總和，但是仍然不能超過它的父容器的剩餘空間，當然它的最終高度還需要考慮豎直方向的padding，這個過程可以進一步參看如下源碼：
public static int resolveSizeAndState(int size, int measureSpec, int childMeasuredState) {
final int specMode = MeasureSpec.getMode(measureSpec);
final int specSize = MeasureSpec.getSize(measureSpec);
final int result;
switch (specMode) {
case MeasureSpec.AT_MOST:
if (specSize < size) {
result = specSize | MEASURED_STATE_TOO_SMALL;
} else {
result = size;
}
break;
case MeasureSpec.EXACTLY:
result = specSize;
break;
case MeasureSpec.UNSPECIFIED:
default:
result = size;
}
return result | (childMeasuredState & MEASURED_STATE_MASK);
}View的measure過程是三大流程中最複雜的一個，measure完成以後，通過getMeasuredWidth/Height方法就可以正確地獲取到View地測量寬高。需要注意的是，在某些極端情況下，系統可能需要多次measure才能確定最終的測量寬高，在這種情形下，在onMeasure方法中拿到的測量寬高很可能是不準確的。一個比較良好的習慣是在onLayout方法中去獲取View的測量寬高或者最終寬高。
上面以及對View的measure過程進行了詳細的分析，現在考慮一種清空，比如我們想在Activity已經啓動的時候就做一個任務，但是這一任務需要獲取View的寬高。可能有人會說這很簡單啊，在onCreate或者onResume裏去獲取這個View的寬高不久行了？可以自行試一下，實際上在onCreate、onStart、onResume裏面均無法正確得到某個View的寬高信息，這是因爲View的measure過程和Activity的生命週期方法不是同步執行的，因此無法保證Activity執行了onCreate、onStart、onResume時某個View已經測量完畢了，如果View還沒有測量完畢，那麼獲取的寬高就是0.有沒有什麼方法能解決這個問題呢？答案是有的，這裏給出四種方法來解決這個問題：
Activity/View#onWindowFocusChanged
onWindowFocusChanged這個方法的含義是：View已經初始化完畢了，寬高已經準備號了，這個時候去獲取寬高是沒有問題的。需要注意的是，onWindowFocusChanged會被調用多次，當Activity的窗口得到和失去焦點時均會被調用一次。具體來說，當Activity繼續執行和暫停執行時，onWindowFocusChanged均會被調用，如果頻繁地進行onResume和onPause，那麼onWindowFocusChanged也會被頻繁地調用。典型代碼如下：
@Override
public void onWindowFocusChanged(boolean hasWindowFocus) {
super.onWindowFocusChanged(hasWindowFocus);
if(hasFocus) {
int width = view.getMeasuredWidth();
int height = view.getMeasuredHeight();
}
}view.post(runnable)。
通過post可以將一個runnable投遞到消息隊列地尾部，然後等待Lopper調用此runnable的時候，View也已經初始化好了。典型代碼如下：
@Override
protected void onStart() {
super.onStart();
view.post(new Runnable(){
@Override
public void run() {
int width = view.getMeasuredWidth();
int height = view.getMeasuredHeight();
}
});
}ViewTreeObserver。
使用ViewTreeObserver的衆多回調可以完成這個功能，比如使用onGlobalLayoutListener這個接口，當View樹的狀態發送改變或者View樹內部的View的可見性發送改變時，onGlobalLayout方法被回調，因此這時獲取View的寬高一個很好的時機。需要注意的是，伴隨着View樹的狀態改變，onGlobalLayout會被調用多次。典型代碼如下：
@Override
protected void onStart() {
super.onStart();
ViewTreeObserver observer = view.getViewTreeObserver();
observer.addOnGlobalLayoutListener(new ViewTreeObserver.OnGlobalLayoutListener() {
@Override
public void onGlobalLayout() {
view.getViewTreeObserver().removeOnGlobalLayoutListener(this);
int width = view.getMeasuredWidth();
int height = view.getMeasuredHeight();
}
});
}view.measure(int widthMeasureSpec, int heightMeasureSpec).
通過手動對View進行measure來得到View的寬高。這種方法比較複雜，這裏要分情況處理，根據View的LayoutParams來分：
- match_parent
直接放棄，無法measure出具體的寬高。原因很簡單，根據View的measure過程，構造此種MeasureSpec需要知道parentSize，即父容器的剩餘空間，而這個時候我們無法知道parentSize的大小，所以理論上不可能測量出View的大小。
- 具體的數值(dp/px)
比如寬高都是100px，如下measure：
int widthMeasureSpec = View.MeasureSpec.makeMeasureSpec(100, View.MeasureSpec.EXACTLY);
int heightMeasureSpec = View.MeasureSpec.makeMeasureSpec(100, View.MeasureSpec.EXACTLY);
view.measure(widthMeasureSpec,heightMeasureSpec);- wrap_content
如下measure：
int widthMeasureSpec = View.MeasureSpec.makeMeasureSpec((1<<30)-1, View.MeasureSpec.AT_MOST);
int heightMeasureSpec = View.MeasureSpec.makeMeasureSpec((1<<30)-1, View.MeasureSpec.AT_MOST);
view.measure(widthMeasureSpec,heightMeasureSpec);注意到(1<<30)-1，通過分析MeasureSpec的實現可以知道，View的尺寸使用30位二進制表示，也就是說最大是30個1(即 2^30-1)，也就是(1<<30) - 1，在最大模式下，我們用View理論上能支持的最大值去構造MeasureSpec是合理的。
關於View的measure，網絡上有兩個錯誤的用法。爲什麼說是錯誤的，首先其違背了系統內部的實現規範(因爲無法通過錯誤的MeasureSpec去得出合法的SpecMode，從而導致measure過程出錯)，其次不能保證一定能measure出正確的結果。
第一種錯誤用法：
int widthMeasureSpec = View.MeasureSpec.makeMeasureSpec(-1, View.MeasureSpec.UNSPECIFIED);
int heightMeasureSpec = View.MeasureSpec.makeMeasureSpec(-1, View.MeasureSpec.UNSPECIFIED);
view.measure(widthMeasureSpec,heightMeasureSpec);第二種錯誤用法：
view.measure(LayoutParams.WRAP_CONTENT,LayoutParams.WRAP_CONTENT);2.layout過程
Layout的作用是ViewGroup用來確定子元素的位置，當ViewGroup的位置被確定後，它在onLayout中會遍歷所有的子元素並調用其layout，在layout方法中onLayout方法又會被調用。Layout的過程和measure過程相比就簡單多了，layout方法確定View本身的位置，而onLayout方法則確定所有子元素的位置，先看View的layout方法，如下所示。
public void layout(int l, int t, int r, int b) {
if ((mPrivateFlags3 & PFLAG3_MEASURE_NEEDED_BEFORE_LAYOUT) != 0) {
onMeasure(mOldWidthMeasureSpec, mOldHeightMeasureSpec);
mPrivateFlags3 &= ~PFLAG3_MEASURE_NEEDED_BEFORE_LAYOUT;
}
int oldL = mLeft;
int oldT = mTop;
int oldB = mBottom;
int oldR = mRight;
boolean changed = isLayoutModeOptical(mParent) ?
setOpticalFrame(l, t, r, b) : setFrame(l, t, r, b);
if (changed || (mPrivateFlags & PFLAG_LAYOUT_REQUIRED) == PFLAG_LAYOUT_REQUIRED) {
onLayout(changed, l, t, r, b);
if (shouldDrawRoundScrollbar()) {
if(mRoundScrollbarRenderer == null) {
mRoundScrollbarRenderer = new RoundScrollbarRenderer(this);
}
} else {
mRoundScrollbarRenderer = null;
}
mPrivateFlags &= ~PFLAG_LAYOUT_REQUIRED;
ListenerInfo li = mListenerInfo;
if (li != null && li.mOnLayoutChangeListeners != null) {
ArrayList<OnLayoutChangeListener> listenersCopy =
(ArrayList<OnLayoutChangeListener>)li.mOnLayoutChangeListeners.clone();
int numListeners = listenersCopy.size();
for (int i = 0; i < numListeners; ++i) {
listenersCopy.get(i).onLayoutChange(this, l, t, r, b, oldL, oldT, oldR, oldB);
}
}
}
mPrivateFlags &= ~PFLAG_FORCE_LAYOUT;
mPrivateFlags3 |= PFLAG3_IS_LAID_OUT;
if ((mPrivateFlags3 & PFLAG3_NOTIFY_AUTOFILL_ENTER_ON_LAYOUT) != 0) {
mPrivateFlags3 &= ~PFLAG3_NOTIFY_AUTOFILL_ENTER_ON_LAYOUT;
notifyEnterOrExitForAutoFillIfNeeded(true);
}
}layout方法的大致流程如下：首先會通過setFrame方法來設定View的四個頂點的位置，即初始化mLeft、mRight、mTop和mBottom這四個值，View的四個頂點一旦確定，那麼View在父容器中的位置也就確定了；接着會調用onLayout方法，這個方法的用途是父容器確定了子元素的位置，和onMeasure方法類似，onLayout的具體實現同樣和具體的佈局有關，所以View和ViewGroup均沒有正真實現onLayout方法。接下來我們可以看一下LinearLayout的onLayout方法，如下所示：
@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中onLayout的實現邏輯和onMeasure的實現邏輯類似，這裏選擇layoutVertical繼續講解，爲了更好地理解其邏輯，這裏只給出主要的代碼：
void layoutVertical(int left, int top, int right, int bottom) {
...
final int count = getVirtualChildCount();
for (int i = 0; i < count; i++) {
final View child = getVirtualChildAt(i);
if (child == null) {
childTop += measureNullChild(i);
} else if (child.getVisibility() != GONE) {
final int childWidth = child.getMeasuredWidth();
final int childHeight = child.getMeasuredHeight();
final LinearLayout.LayoutParams lp =
(LinearLayout.LayoutParams) child.getLayoutParams();
...
if (hasDividerBeforeChildAt(i)) {
childTop += mDividerHeight;
}
childTop += lp.topMargin;
setChildFrame(child, childLeft, childTop + getLocationOffset(child),
childWidth, childHeight);
childTop += childHeight + lp.bottomMargin + getNextLocationOffset(child);
i += getChildrenSkipCount(child, i);
}
}
}
這裏分析一下layoutVertical的代碼邏輯，可以看到，此方法會遍歷所有子元素並調用setChildFrame方法來位子元素指定對應的位置，其中childTop會逐漸增大，這就意味着後面的子元素會被放置在靠下的位置，這剛好符合豎直方向的LinearLayout的特性。至於setChildFrame，它僅僅是調用子元素的layout方法而已，這樣父元素在layout方法中完成自己的定位以後，就通過onLayout方法去調用子元素的layout方法，子元素又會通過自己的layout來確定自己的位置，這樣一層一層地傳遞下去就完成了這個View樹地layout過程。setChildFrame的實現方法如下所示。
private void setChildFrame(View child, int left, int top, int width, int height) {
child.layout(left, top, left + width, top + height);
}我們注意到，setChildFrame中的width和height實際上就是子元素的測量寬高，從下面的代碼就可以看出這一點：
final int childWidth = child.getMeasuredWidth();
final int childHeight = child.getMeasuredHeight();
setChildFrame(child, childLeft + getLocationOffset(child), childTop,
childWidth, childHeight);而在layout方法中會通過setFrame去設置子元素的四個頂點的位置，在setFrame中有如下幾句賦值語句，這樣一來子元素的位置就確定了；
mLeft = left;
mTop = top;
mRight = right;
mBottom = bottom;下面來回答一個問題：View的測量寬高和最終寬高有什麼區別？這個問題可以具體位View的getMeasuredWidth和getWidth這兩個方法有什麼區別，至於getMeasuredHeight和getHeight的區別和前兩者完全一樣。爲了回答這個問題，首先，我們看一下getWidth和getHeight這兩個方法的具體實現。
/**
* Return the width of the your view.
*
* @return The width of your view, in pixels.
*/
@ViewDebug.ExportedProperty(category = "layout")
public final int getWidth() {
return mRight - mLeft;
}
/**
* Return the height of your view.
*
* @return The height of your view, in pixels.
*/
@ViewDebug.ExportedProperty(category = "layout")
public final int getHeight() {
return mBottom - mTop;
}從getWidth和getHeight的源碼結合mLeft、mRight、mTop和mBottom這個四個變量的賦值過程來看，getWidth方法的返回值剛好就是View的測量寬度，而getHeight方法的返回值也剛好就是View的測量高度。經過上述分析，現在我們就可以回答這個問題了：在View的默認實現中，View的測量寬高和最終寬高是相等的，只不過測量寬高形成於View的measure過程，而最終寬高形成於View的layout過程，即兩者的賦值時機不同，測量寬高的賦值時間稍微早一些。因此在日常開發中，我們可以認爲View的測量寬高就等於最終寬高，但是的確存在某些特殊清空導致兩者不一致，下面距離說明。
如果重寫View的layout方法，代碼如下：
@Override
public void layout(int l, int t, int r, int b) {
super.layout(l, t, r+100, b+100);
}上述代碼會導致在任何情況下View的最終寬高總是比測量寬高大100px，雖然這樣繪製到View顯示不正常並且沒有意義，但這證明了測量寬高的確可以不等於最終寬高。另外一種清空是在某些清空下，View需要多次measure才能確定自己的測量寬高，在前幾次的測量過程中，其得出的測量寬高有可能和最終寬高不一致，但最終來說，測量寬高還是和最終寬高相同。
3.draw過程
Draw就比較簡單了，它的作用是將View繪製到屏幕上面。View的繪製過程遵循如下幾步：
- 繪製背景background.draw(canvas).
- 繪製自己(onDraw)
- 繪製child(dispatchDraw)
- 繪製裝飾(onDrawScrollBars)
這一點通過draw方法的源碼可以明顯看出來，如下所示。
public void draw(Canvas canvas) {
final int privateFlags = mPrivateFlags;
final boolean dirtyOpaque = (privateFlags & PFLAG_DIRTY_MASK) == PFLAG_DIRTY_OPAQUE &&
(mAttachInfo == null || !mAttachInfo.mIgnoreDirtyState);
mPrivateFlags = (privateFlags & ~PFLAG_DIRTY_MASK) | PFLAG_DRAWN;
/*
* 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
int saveCount;
if (!dirtyOpaque) {
drawBackground(canvas);
}
// skip step 2 & 5 if possible (common case)
final int viewFlags = mViewFlags;
boolean horizontalEdges = (viewFlags & FADING_EDGE_HORIZONTAL) != 0;
boolean verticalEdges = (viewFlags & FADING_EDGE_VERTICAL) != 0;
if (!verticalEdges && !horizontalEdges) {
// Step 3, draw the content
if (!dirtyOpaque) onDraw(canvas);
// Step 4, draw the children
dispatchDraw(canvas);
drawAutofilledHighlight(canvas);
// Overlay is part of the content and draws beneath Foreground
if (mOverlay != null && !mOverlay.isEmpty()) {
mOverlay.getOverlayView().dispatchDraw(canvas);
}
// Step 6, draw decorations (foreground, scrollbars)
onDrawForeground(canvas);
// Step 7, draw the default focus highlight
drawDefaultFocusHighlight(canvas);
if (debugDraw()) {
debugDrawFocus(canvas);
}
// we're done...
return;
}
...
}View繪製過程的傳遞時通過dispatchDraw來實現，dispatchDraw會遍歷調用所有子元素的draw方法，如此draw時間就一層層地傳遞了下去。View有一個特殊地方法seyWillNotDraw，先看一下它地源碼，如下所示。
public void setWillNotDraw(boolean willNotDraw) {
setFlags(willNotDraw ? WILL_NOT_DRAW : 0, DRAW_MASK);
}從seyWillNotDraw這個方法的註釋中可以看出，如果一個View不需要繪製任何內容，那麼設置這個標記位爲true以後，系統會進行相應的優化。默認清空下，View沒有啓用這個優化標記位，但是ViewGroup會默認啓用這個優化標記位。這個標記位對時機開發的意義是：當我們的自定義控件繼承與ViewGroup並且不具備繪製功能時，就可以開啓這個標記位從而便於系統進行後續的優化。當然明確知道一個ViewGroup需要通過onDraw來繪製內容時，我們需要顯式地關閉WILL_NOIT_DRAW這個標記位。