Android View的工作流程-一一网

View的工作流程

开始自定义之前，必须先了解以下View的工作流程，也就是measure、layout、draw这三大流程。

measure

Android的视图树中，根View肯定是一个ViewGroup（DecorView就是根View，实际上是一个FrameLayout），所以了解测量过程，应该从ViewGroup开始，沿着视图树去看，这样更容易理解。ViewGroup继承自View，View的的measure方法中会调用onMeasure，由于ViewGroup无法统一出一个通用的测量规则（例如LinearLayout和RelativeLayout的测量规则差别很大），所以并没有实现onMeasure，而是交由子类去实现，所以我们来看看他的子类LinearLayout的onMeasure的实现。

@Override
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
    if (mOrientation == VERTICAL) {
        measureVertical(widthMeasureSpec, heightMeasureSpec);
    } else {
        measureHorizontal(widthMeasureSpec, heightMeasureSpec);
    }
}
复制代码

measureVertical和measureHorizontal类似，只看一个就够了，measureVertical代码很长，但是里边有这么关键的一句

measureChildBeforeLayout(child, i, widthMeasureSpec, 0,heightMeasureSpec, usedHeight);

void measureChildBeforeLayout(View child, int childIndex, int widthMeasureSpec, int totalWidth, int heightMeasureSpec, int totalHeight) {
    measureChildWithMargins(child, widthMeasureSpec, totalWidth,heightMeasureSpec, totalHeight);
}
复制代码

measureChildBeforeLayout是在循环中被调用的，循环次数就是ViewGroup中的子视图的数量。measureChildBeforeLayout中又调用了measureChildWithMargins，measureChildWithMargins是父类ViewGroup提供的一个方法。

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中，先是调用了getChildMeasureSpec获取到了子视图宽和高的MeasureSpec，然后再调用子视图的measure，并将宽和高的MeasureSpec传进去，子视图measure方法中又会调用子视图的onMeasure，如此递归直到视图树中的叶子节点。现在需要先了解MeasureSpec以及getChildMeasureSpec这个方法。

MeasureSpec

MeasureSpec 封装了从父级传递到子视图的布局要求，为什么父级要对自己做出要求呢？因为屏幕空间有限，比如父级分配到的宽度500像素，就会将这个宽度告诉子视图，子视图最好不要超出这个宽度，如果非要超出这个宽度，最终效果可能就无法达到预期。MeasureSpec 由大小和模式组成，大小就是像素值，模式有3种

EXACTLY 父级已经确定了子View的确切尺寸，这种情况对应的是子View的LayoutParams中指定了具体的尺寸。LayoutParams中指定的尺寸代表了开发者的意愿，开发者的意愿优先级是最高的。即使开发者指定的值不合理，最终可能会导致异常情况，但是系统依然会按照开发者要求将View的尺寸设置为指定的值，毕竟这是开发者的bug，不是系统的bug。
AT_MOST 父级规定一个上限，具体大小由子视图自行决定，只要不超过上限。
UNSPECIFIED 父级未对子视图施加任何约束。它可以是它想要的任何尺寸，这种情况一般用于重复测量时。

可以使用makeMeasureSpec将模式和尺寸压缩为一个MeasureSpec，使用getMode和getSize可以从MeasureSpec中解压出模式和尺寸。

getChildMeasureSpec

getChildMeasureSpec方法传入父级的MeasureSpec、父级的padding、子视图在LayoutParams中指定的尺寸，返回子视图的MeasureSpec。方法可以概括成如下一张图：

其中灰色部分就是子视图的MeasureSpec。按行说明一下。灰色部分第1行，也就是子视图指定了具体值，由于开发者设定的值优先级最高，所以不考虑父级的限制，直接就是EXACTLY和子视图自己的尺寸。第2行，当子视图指定了match_parent时，分3种情况：父级尺寸确定，那子视图尺寸也确定，也就是EXACTLY和父级size-父级padding；父级尺寸不定，但是父级有上限，此时子视图又要占满父级的可用空间，那就只能给子视图一个上限（AT_MOST），上限就是父级size-父级padding；父级不受限制，子视图又想占满父级的空间，此时父级自己也不知道自己多大，所以只能将自己的可用尺寸（父级size-父级padding）给子视图，同时让子视图也是UNSPECIFIED，这种情况一般需要多次测量，最终确定尺寸。第3行，子视图为wrap_content时，前两种情况很像，父级尺寸确定和父级尺寸有上限，但是此时子视图尺寸需要根据自己的内容来确定，并没有具体值，所以就只能限制子视图不超过自己的上限值，也就是AT_MOST 和父级size-父级padding，这两种情况子视图会在自己的onMeasure中进一步测量自己的尺寸；最后一种情况就是父级不限制，自己的尺寸需要自己测量才能知道，并且没有上限，所以就把父级size-父级padding给子视图，同时也不限制子视图的尺寸，这种情况同样需要子视图在onMeasure中进一步测量自己的尺寸。

需要说明的是父级UNSPECIFIED，有两种情况子视图会是0或者父级size-父级padding，Android6.0以前是0，6.0以后就是父级size-父级padding，这两种情况一种是需要多次测量，一种是需要子视图在onMeasure中进一步测量，所以不管是0还是父级size-父级padding，其实并不需要太多关注。getChildMeasureSpec中的父级padding，其实是把父级的padding和子视图的margin加在了一起，作为最终的父级的padding，这一点在measureChildWithMargins中可以看到。所以我们自己继承View实现自定义View时，不需要自己处理margin，因为他的父级（比如LinearLayout）已经处理了margin，但是父级并没有处理子视图的padding，所以需要我们自己去处理padding。

measureChildWithMargins的最后一行就是调用子视图的measure方法，子视图如果是ViewGroup，就会继续重复上述过程，如果是View，就进入了View的测量过程，View的测量比较简单，毕竟只需要测量自己，不需要测量子View。

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

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

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

从里往外看，getSuggestedMinimumWidth返回了View的建议宽度，如果View没有背景，建议宽度就是0，如果有背景，建议宽度就是背景的宽度。getDefaultSize中，根据MeasureSpec（这个MeasureSpec就是从父级ViewGroup传过来的，代表的是父级对子视图的限制），如果EXACTLY和AT_MOST，就返回MeasureSpec中的尺寸，如果是UNSPECIFIED就返回建议尺寸。这里需要注意的是，AT_MOST模式下，返回的是MeasureSpec中的尺寸。由上边表格可以知道，子View是AT_MOST模式有3种情况：父级AT_MOST，子视图match_parent，此时getDefaultSize返回MeasureSpec中的尺寸（也就是父级的可用尺寸），这种情况是符合预期的；而其他两种情况，子视图wrap_content同时父级分别是EXACTLY和AT_MOST，此时getDefaultSize返回MeasureSpec中的尺寸（也就是父级的可用尺寸），也就是说设置的是wrap_content，然而实际效果却是match_parent，这是不符合预期的。所以，在我们继承View实现自定义View时需要自己处理wrap_content的情况。onMeasure中最后通过setMeasuredDimension将测量的结果保存起来，测量过程也就结束了。

layout

layout的过程就是确定自己以及子视图位置的过程。layout方法中，会接收4个参数，4个参数就是View相对于父容器的位置，并调用setFrame，将父容器给的4个顶点指定为View的位置，这样View的位置就确定了，layout方法中会继续调用onLayout方法，onLayout的用途是父容器确定子视图的位置，确定后会调用子视图的layout方法，子视图再setFrame指定位置，直到视图树的叶子节点，叶子节点肯定是一个View（或者一个空ViewGroup），此时VIew完成了layout，确定了自己的位置后，layout流程就结束了。从根视图开始看布局流程就是，根视图先在layout中指定自己的位置（占满屏幕就行了），然后在onLayout按照规则确定子View的位置，并调用子View的layout，子View在layout方法中调用setFrame将父级确定的位置设定下来，然后子View再调用onLayout，按照自己的规则确定孙子View的位置，如此重复，直到View树的最后一层，最后一层没有子View，布局过程就结束了。这里反复提到onLayout中按照自己的规则确定子View的位置，什么是自己的规则呢，其实就是开发者定义ViewGroup时指定的规则，例如：FrameLayout的布局规则是层层叠加，子View的先后顺序不会影响4个顶点的位置，而LinearLayout的规则是视图的先后顺序会影响到4个顶点的位置，布局时需要将某个子View在上一个兄弟View的基础上加上自己的测量结果去计算得到4个顶点的位置。这就是不同的Layout，各自有自己的布局规则，所以ViewGroup并没有实现一个通用的onLayout方法。ViewGroup类中layout方法为final，这是因为ViewGroup的父类View中layout已经有了默认实现，因此所有的ViewGroup都只需要实现onLayout方法确定子视图的位置即可，不需要考虑确定自己的位置。下边来看看FrameLayout的布局过程，也就是看看它的onLayout方法。

@Override
protected void onLayout(boolean changed, int left, int top, int right, int bottom) {
    layoutChildren(left, top, right, bottom, false /* no force left gravity */);
}

void layoutChildren(int left, int top, int right, int bottom, boolean forceLeftGravity) {
    final int count = getChildCount();

    final int parentLeft = getPaddingLeftWithForeground();
    final int parentRight = right - left - getPaddingRightWithForeground();

    final int parentTop = getPaddingTopWithForeground();
    final int parentBottom = bottom - top - getPaddingBottomWithForeground();

    for (int i = 0; i < count; i++) {
        final View child = getChildAt(i);
        if (child.getVisibility() != GONE) {
            final LayoutParams lp = (LayoutParams) child.getLayoutParams();

            final int width = child.getMeasuredWidth();
            final int height = child.getMeasuredHeight();

            int childLeft;
            int childTop;

            int gravity = lp.gravity;
            if (gravity == -1) {
                gravity = DEFAULT_CHILD_GRAVITY;
            }

            final int layoutDirection = getLayoutDirection();
            final int absoluteGravity = Gravity.getAbsoluteGravity(gravity, layoutDirection);
            final int verticalGravity = gravity & Gravity.VERTICAL_GRAVITY_MASK;

            switch (absoluteGravity & Gravity.HORIZONTAL_GRAVITY_MASK) {
                case Gravity.CENTER_HORIZONTAL:
                    childLeft = parentLeft + (parentRight - parentLeft - width) / 2 +
                    lp.leftMargin - lp.rightMargin;
                    break;
                case Gravity.RIGHT:
                    if (!forceLeftGravity) {
                        childLeft = parentRight - width - lp.rightMargin;
                        break;
                    }
                case Gravity.LEFT:
                default:
                    childLeft = parentLeft + lp.leftMargin;
            }

            switch (verticalGravity) {
                case Gravity.TOP:
                    childTop = parentTop + lp.topMargin;
                    break;
                case Gravity.CENTER_VERTICAL:
                    childTop = parentTop + (parentBottom - parentTop - height) / 2 +
                    lp.topMargin - lp.bottomMargin;
                    break;
                case Gravity.BOTTOM:
                    childTop = parentBottom - height - lp.bottomMargin;
                    break;
                default:
                    childTop = parentTop + lp.topMargin;
            }

            child.layout(childLeft, childTop, childLeft + width, childTop + height);
        }
    }
}
复制代码

代码很长，其实很简单，就是循环计算每个子View的顶点位置，计算规则就是根据FrameLayout的padding，以及子View的gravity和margin来计算4个顶点的位置，这个计算规则也就是FrameLayout的布局规则。计算完成之后，调用子View的layout，并传入计算的顶点，从而将布局过程一级一级传下去。

draw

绘制的过程比较简单，draw方法的源码中清晰的描述了绘制过程

// Step 1, draw the background, if needed
int saveCount;

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
    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 (isShowingLayoutBounds()) {
        debugDrawFocus(canvas);
    }

    // we're done...
    return;
}
复制代码

绘制顺序依次是：

绘制背景。无法被重写。
onDraw中绘制自己。
dispatchDraw中调度子View绘制，也就是绘制子View。
onDrawForeground中绘制前景，包括绘制滚动条和绘制前景。
绘制获得焦点是的高亮状态。无法被重写。

绘制顺序中后绘制的总是会挡住先绘制的内容，这一点尤其重要，可以帮我们实现各种叠加的效果，这里盗一张图，总结绘制位置对结果的影响。

绘制顺序.jpg

更多绘制顺序的内容可以参考rengwuxian.com/ui-1-5/

虽说绘制的流程很简单，但其实绘制并不简单，绘制的复杂在于Canvas的一堆API以及Paint的各种设置，甚至包括各种数学计算和物理计算，比如：绘制一根线模拟时钟的秒针旋转，需要用到数学的三角函数去计算；绘制一个自由落体的小球，需要用物理公式去计算速度和位置；绘制一些曲线是需要用到正弦曲线、余弦曲线、贝塞尔曲线等并根据参数不断调整以达到预期的效果。这些才是绘制最复杂的内容，但是没法总结，只能遇到需求后再去思考实现。至于canvas的API，我认为需要知道能做什么，但不一定需要记住，具体用的时候再去查文档就行了，毕竟这些死记硬背的知识也没啥好记的。

文章版权归作者所有，未经允许请勿转载。

THE END

Android