Android View的工作流程

331 阅读9分钟

View的工作流程

本文主要介绍View的工作流程,也就是measure、layout、draw这三大流程,以及MeasureSpec,掌握这些知识就可以轻松的自定义View以及自定义ViewGroup。

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。方法可以概括成如下一张图: getChildMeasureSpec.jpg

其中灰色部分就是子视图的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;
}

绘制顺序依次是:

  1. 绘制背景。无法被重写。

  2. onDraw中绘制自己。

  3. dispatchDraw中调度子View绘制,也就是绘制子View。

  4. onDrawForeground中绘制前景,包括绘制滚动条和绘制前景。

  5. 绘制获得焦点是的高亮状态。无法被重写。

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

绘制顺序.jpg

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

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