自定義控件知識儲備-View的繪制流程

protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
        setMeasuredDimension(getDefaultSize(getSuggestedMinimumWidth(), widthMeasureSpec),
                getDefaultSize(getSuggestedMinimumHeight(), heightMeasureSpec));
    }

這方法一層嵌一層的，還是從裡往外接著看吧，對於getSuggestedMinimumWidth和getSuggestedMinimumHeight方法，顧名思義，就是得到建議的最小的寬/高。什麼意思呢？以getSuggestedMinimumWidth為例：

 protected int getSuggestedMinimumWidth() {
        return (mBackground == null) ? mMinWidth : max(mMinWidth, mBackground.getMinimumWidth());
    }

mMinWidth屬性對應的就是xml布局裡的android:minWidth屬性，設置最小寬度。mBackground.getMinimumWidth()方法返回的就是View背景Drawable的原始寬度，這個寬度跟背景的類型有關。比如我們給View的背景設置一張圖片，那這個方法返回的寬度就是圖片的寬度，而如果我們給View背景設置的是顏色，那麼這個方法返回的寬度則是0。具體的大家可以自行查閱Drawable尺寸的相關資料。所以，這個方法的返回的寬度是：如果View沒有設置背景，那就返回xml布局裡的android:minWidth屬性定義的值，默認為0；如果View設置了背景，就返回背景的寬度和mMinWidth中的最大值。

再來看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;//這裡的size就是上面getSuggestedMinimumWidth/height的返回值
            break;
        case MeasureSpec.AT_MOST:
        case MeasureSpec.EXACTLY:
            result = specSize;//測量規格裡的尺寸
            break;
        }
        return result;
    }

可以看出，View在當測量模式為UNSPECIFIED時，返回的就是上面getSuggestedMinimumWidth/Height()方法裡的大小。其實這對我們自定義控件並沒有什麼影響，因為上文有提到過，UNSPECIFIED一般用於系統內部的測量過程，對我們正常邏輯沒什麼影響。我們的重點還是應該放在AT_MOST和EXACTLY兩種情況下。對於這兩種情況，getDefaultSize十分簡單粗暴，直接返回了specSize，也就是View的測量規格裡的測量尺寸。

，不知道大家在看完上面的代碼以後，有沒有發現一個“碧油雞”，在AT_MOST和EXACTLY兩種情況下返回的尺寸竟然都是specSize，這意味著什麼呢？

自定義View控件時，我們需要重寫onMeasure方法並設置wrap_content時自身的大小。否則在xml布局中使用wrap_content時與match_parent的效果一樣。

為什麼呢？如果View在xml布局中使用wrap_content，根據上面提到的規則表格，它的測量模式是AT_MOST模式，測量尺寸specSize是parentSize，而getDefaultSize方法在AT_MOST裡直接返回specSize，也就是等於父容器的剩余空間大小，這和match_parent是一樣的。所以我們需要自己來處理AT_MOST模式下的寬高。

一個重寫onMeasure方法來支持wrap_content屬性的模版如下：

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);

        int wrapWidth,wrapHeight;//根據View的邏輯得到，比如TextView根據設置的文字計算wrap_content時的大小

        if(widthSpecMode == MeasureSpec.AT_MOST && heightSpecMode == MeasureSpec.AT_MOST){
            setMeasuredDimension(wrapWidth, wrapHeight);
        }else if(widthSpecMode == MeasureSpec.AT_MOST){
            setMeasuredDimension(wrapWidth, heightSpecSize);
        }else if(heightSpecMode == MeasureSpec.AT_MOST){
            setMeasuredDimension(widthSpecSize, wrapHeight);
        }
}

以上代碼可以直接應用到我們的自定義控件裡去，當然最重要的還是大家得對AT_MOST模式留點心，記得對它特別對待就行。

好的，我們再看最外層的方法setMeasuredDimension：

protected final void setMeasuredDimension(int measuredWidth, int measuredHeight) {
        boolean optical = isLayoutModeOptical(this);
        if (optical != isLayoutModeOptical(mParent)) {
            Insets insets = getOpticalInsets();
            int opticalWidth  = insets.left + insets.right;
            int opticalHeight = insets.top  + insets.bottom;

            measuredWidth  += optical ? opticalWidth  : -opticalWidth;
            measuredHeight += optical ? opticalHeight : -opticalHeight;
        }
        setMeasuredDimensionRaw(measuredWidth, measuredHeight);
    }

 private void setMeasuredDimensionRaw(int measuredWidth, int measuredHeight) {
        mMeasuredWidth = measuredWidth;
        mMeasuredHeight = measuredHeight;

        mPrivateFlags |= PFLAG_MEASURED_DIMENSION_SET;
    }    

setMeasuredDimension方法裡調用了setMeasuredDimensionRaw方法，在這個方法裡面，終於看到了我們熟悉的mMeasuredWidth和measuredHeight的賦值語句。從此以後，我們就可以安心的調用View的getMeasureWidth()和getMeasureHeight()方法了！(≧?≦)?

2.2 ViewGroup的measure過程

ViewGroup並沒有重寫View的onMeasure方法，這需要它的子類去根據相應的邏輯去實現，比如LinearLayout與RelativeLayout對child view的測量邏輯顯然是不同的。不過，ViewGroup倒是提供了一個measureChildren的方法，貌似可以用來測量child的樣子，看看源碼：

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);
            }
        }
    }

上面的代碼邏輯很清晰，就是遍歷每個孩子，調用measureChild方法對其進行測量，接著來看看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方法裡，會取出child的LayoutParams，再結合父控件的測量規格和已被占用的空間Padding，作為參數傳遞給getChildMeasureSpec方法，在getChildMeasureSpec裡會組合生成child控件的測量規格。getChildMeasureSpec方法的邏輯在上面的MeasureSpec部分有詳細說明。最後，當然還是得調用child的measure方法啦，讓孩子根據父母的指引去測量自己。

在我看來，我們在自己自定義控件時，上面的這兩個方法幾乎不會用到。因為measureChildren太過簡單粗暴，我們一般都會考慮孩子們之間的邏輯關系(順序、間隔等)，再計算他們的測量規格。不過這個方法也給我們一點啟示，就是：

測量子元素時，對可見性為GONE的View要做特殊處理，一般來說就是跳過對它們的測量，來優化布局。

而measureChild方法只考慮了父控件的padding，但是沒考慮到child view的margin，這就會導致child view在使用match_parent屬性的時候，margin屬性會有問題。（什麼？你說你自定義的ViewGroup對孩子不支持margin屬性不就不會有問題了麼…是是是，那當我沒說….）當然，ViewGroup裡為此也提供了另一個測量child的方法：

protected void measureChildWithMargins(View child,
            int parentWidthMeasureSpec, int widthUsed,
            int parentHeightMeasureSpec, int heightUsed) {
        final MarginLayoutParams lp = (MarginLayoutParams) child.getLayoutParams();

        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);

        child.measure(childWidthMeasureSpec, childHeightMeasureSpec);
    }

measureChildWithMargins方法，顧名思義，比measureChild方法多考慮了個margin。看源碼也看得出來，的確是這樣。所以一般情況下，這個方法使用的更多一些。

3.布局流程-layout

布局的流程就沒有測量流程那麼“蜿蜒曲折”了。對於單身View來說，調用layout方法確定好自己的位置，設置好位置屬性的值（mLeft/mRgiht,mTop/mBottom）就行。而對於父母ViewGroup來說，還得通過調用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);
            mPrivateFlags &= ~PFLAG_LAYOUT_REQUIRED;

            ListenerInfo li = mListenerInfo;
            if (li != null && li.mOnLayoutChangeListeners != null) {
                ArrayList listenersCopy =
                        (ArrayList)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;
    }

 protected boolean setFrame(int left, int top, int right, int bottom) {
        boolean changed = false;

        if (mLeft != left || mRight != right || mTop != top || mBottom != bottom) {
            changed = true;

            ...

            // Invalidate our old position
            invalidate(sizeChanged);

            mLeft = left;
            mTop = top;
            mRight = right;
            mBottom = bottom;
            mRenderNode.setLeftTopRightBottom(mLeft, mTop, mRight, mBottom);

            ...
        }
        return changed;
    }

從上面的代碼，能看到layout方法首先會調用setFrame方法來給View的四個頂點屬性賦值，即mLeft，mRight，mTop，mBottom四個值，此時這個View的位置就確定了。同時我們也就能通過調用getWidth()和getHeight()方法來獲取View的實際寬高了。

接下來，onLayout方法才會被調用，這也意味著我們在自定義ViewGroup時，想要重寫onLayout方法給我們的子元素定位，是可以直接調用getWidth()和getHeight()方法來獲取ViewGroup的真實寬高的。在View類裡的onLayout方法是個空方法，而在ViewGroup方法裡聲明成了抽象方法，所以繼承ViewGroup的類都得自己去實現自己定位子元素的邏輯。

最後，在layout方法的最後我們能看到一個OnLayoutChangeListener的集合，看名字我們也猜得出，這是View位置發生改變時的回調接口。所以我們可以通過addOnLayoutChangeListener方法可以監聽一個View的位置變化，並做出想要的響應。（看源碼的時候才發現這個回調接口的，以前都不知道。新技能get！︿(￣︶￣)︿）

4.繪制流程-draw

繪制的流程也就是通過調用View的draw方法實現的。draw方法裡的邏輯看起來更清晰，我就不貼源碼了。一般是遵循下面幾個步驟：

由於不同的控件都有自己不同的繪制實現，所以View的onDraw方法肯定是空方法。而ViewGroup由於需要照顧孩子們的繪制，所以肯定在dispatchDraw方法裡遍歷調用了child的draw方法。不信？不信咱來看看ViewGroup裡重寫的dispatchDraw方法：

 protected void dispatchDraw(Canvas canvas) {

        ...

        for (int i = 0; i < childrenCount; i++) {
            int childIndex = customOrder ? getChildDrawingOrder(childrenCount, i) : i;
            final View child = (preorderedList == null)
                    ? children[childIndex] : preorderedList.get(childIndex);
            if ((child.mViewFlags & VISIBILITY_MASK) == VISIBLE || child.getAnimation() != null) {
                more |= drawChild(canvas, child, drawingTime);
            }
        }

        ...
    }    

protected boolean drawChild(Canvas canvas, View child, long drawingTime) {
        return child.draw(canvas, this, drawingTime);
    }

ViewGroup裡的dispatchDraw方法遍歷調用drawChild方法，drawChild方法又調用了child的draw(canvas, this, drawingTime)方法，最後還是調用到了child的draw(canvas)方法。如此這般，繪制流程也就一層一層的傳遞下去了。

好的，說完了…(*???)…………………………………..

5.總結

我已經無力總結了，沒想到一篇總結的文章寫了我兩天半…。不過，自己在總結的過程中確實也學到了蠻多，加深了對View的繪制流程的理解，也弄清楚了一些模糊的知識點。當然了，也希望我的文章能對正在學Android開發的小伙伴們有所幫助。

當然了，這些都屬於自定義控件的基本功，還需要在實踐中多積累一些相關的經驗，並逐漸做到融會貫通，這樣才能提高自己的水平。keep going!