Android View 绘制流程 源码解析

标签: Android 源码解析 View


关于View的绘制流程,或者说 View 的工作流程(说绘制流程容易让人误解成 View 的 draw 流程)自己也在网上看过不少好文。但每当被问到具体的问题的时候,总感觉有很多知识还是模棱两可。因此本篇博客主要是用来梳理和总结相关知识。如果你也对View的绘制流程似懂非懂,不妨顺着我的思路看下去,希望你会有所收获。当然,任何不足、不当之处也请告诉我~

1.View 绘制流程的开始

当我们打开一个 Activity,呈现在我们面前的就已经是绘制好了的 View 了。在我们梳理 View 的绘制流程之前,不妨先思考一个问题:View是从什么时候/哪里开始被绘制的?

预备知识:

1.1 关于DecorView

DecorView 继承 FrameLayout,一般情况下包含一个 LinearLayout。而这个 LinearLayout 又包含一个 id 为 android.R.id.content 的 ViewGroup 和 一个titlebar (跟主题相关,也可能没有)。DecorView 也被称作顶级 View,也因此它是最先被绘制的。

1.2 关于ViewRootImpl

*注:这里涉及到的和 Window 及 WindowManager 相关知识不作过多解释。
ViewRootImpl 顾名思义,它是所有 View 的根,即整个 View 树的根节点。同时它也是连接WindowManager 和 DecorView 的纽带。但需要注意的是 ViewRootImpl 本身并不是一个 View 。有了这两点知识,我们可以回答最开始的问题了:View 的绘制流程是从 ViewRootImpl#performTravels 方法开始的。这个方法在 ActivityThread 被执行。performTravels 方法主要包含 measure,layout,draw 这三个过程。一般情况下这里的变量 mView 就是 DecorView。

private void performTraversals() { 
//...... 
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); 
...... 
}

OK,一切的绘制都是从DecorView开始的啊。那么现在要绘制DecorView了,首先被执行的是它的measure方法,即确定DecorView的大小,那么 DecorView 的大小是如何确定的呢?

2.View 的 measure 过程

预备知识

2.1 关于MeasureSpec

MeasureSpec即测量规格,它是一个32位的int值,高2位代表SpecMode,低30位代表SpecSize。并提供了打包和拆包低方法。

测量模式有三种:

UNSPECIFIED
父视图不对子视图有任何约束,它可以达到所期望的任意尺寸。
EXACTLY
父视图为子视图指定一个确切的尺寸,而且无论子视图期望多大,它都必须在该指定大小的边界内,对应的属性为 match_parent 或具体值。
AT_MOST
父视图为子视图指定一个最大尺寸。子视图必须确保它自己所有子视图可以适应在该尺寸范围内,对应的属性为 wrap_content ,这种模式下,父控件无法确定子 View 的尺寸,只能由子控件自己根据需求去计算自己的尺寸。

理解了 MeasureSpec,我们就知道了要确定 DecorView 的大小,最先要做的事情就是要确定 DecorView 的 MeasureSpec。那么 DecorView 的 MeasureSpec 是如何确定的呢?让我们再回到 performTraversals 这个方法,根据源码可以看出,DecorView 的测量时所需要的两个 MeasureSpec 变量是根据 getRootMeasureSpec 方法得到的。同时,我们可以发现:DecorView 的 MeasureSpec 是由 windowSize 和 Window.LayoutParams 共同决定的。 具体规则如下:

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;
        case ViewGroup.LayoutParams.WRAP_CONTENT:
            // Window can resize. Set max size for root view.
            measureSpec = MeasureSpec.makeMeasureSpec(windowSize, MeasureSpec.AT_MOST);
            break;
        default:
            // Window wants to be an exact size. Force root view to be that size.
            measureSpec = MeasureSpec.makeMeasureSpec(rootDimension, MeasureSpec.EXACTLY);
            break;
    }
        return measureSpec;
}

当 window 的 layout_width / layout_height 为 match_parent 时:
DecorView 的 size 即为 windowSize,其 mode 为 EXACTLY。
当 window 的 layout_width / layout_height 为 wrap_parent 时:
DecorView 的 size 是不确定的,但其 size 不能超过 windowSize 的大小,同时其 mode 为 AT_MOST。
当 window 的 layout_width / layout_height 为 default (即确定值)时 :
DecorView 的 size 即为 Window.LayoutParams 中所指定宽高,同时其 mode 为 EXACTLY。
至此,DecorView 的两个 MeasureSpec 都已经拿到,一切都交由 DecorView 的 measure 方法去处理了。DecorView 是一个 FrameLayout,其 measure 方法继承的是 View 的 measure 方法,在 View 的 measure 方法中又会去调用 View 的 onMeasure 方法。而作为一个父 View 其大小在某些情况也与其子 View 有关,对于不同的 ViewGroup 来说,其 onMeasure 方法的实现也不相同。但在 ViewGroup 中提供了一些通用的测量子 View 的方法:measureChild , measureChildren , measureChildWithMargins。我们选取一个典型来看一下 measureChildWithMargins 这个方法:

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

上述方法会对子元素进行 measure,在调用子元素的 measure 方法之前会先通过 getChildMeasureSpec 方法来得到子元素的 MeasureSpec 。根据方法参数来看,很显然,子元素的 MeasureSpec 的创建与父容器的 MeasureSpec 和子元素本身的 LayoutParams 有关,此外与父 View 的 padding 和子 View 的 margin 也有关。具体情况我们可以看一下 ViewGroup 的 getChildMeasureSpec 方法。

public static int getChildMeasureSpec(int spec, int padding, int childDimension) {
        int specMode = MeasureSpec.getMode(spec);
        int specSize = MeasureSpec.getSize(spec);

        int size = Math.max(0, specSize - padding);

        int resultSize = 0;
        int resultMode = 0;

        switch (specMode) {
        // Parent has imposed an exact size on us
        case MeasureSpec.EXACTLY:
            if (childDimension >= 0) {
                resultSize = childDimension;
                resultMode = MeasureSpec.EXACTLY;
            } else if (childDimension == LayoutParams.MATCH_PARENT) {
                // Child wants to be our size. So be it.
                resultSize = size;
                resultMode = MeasureSpec.EXACTLY;
            } else if (childDimension == LayoutParams.WRAP_CONTENT) {
                // Child wants to determine its own size. It can't be
                // bigger than us.
                resultSize = size;
                resultMode = MeasureSpec.AT_MOST;
            }
            break;

        // Parent has imposed a maximum size on us
        case MeasureSpec.AT_MOST:
            if (childDimension >= 0) {
                // Child wants a specific size... so be it
                resultSize = childDimension;
                resultMode = MeasureSpec.EXACTLY;
            } else if (childDimension == LayoutParams.MATCH_PARENT) {
                // Child wants to be our size, but our size is not fixed.
                // Constrain child to not be bigger than us.
                resultSize = size;
                resultMode = MeasureSpec.AT_MOST;
            } else if (childDimension == LayoutParams.WRAP_CONTENT) {
                // Child wants to determine its own size. It can't be
                // bigger than us.
                resultSize = size;
                resultMode = MeasureSpec.AT_MOST;
            }
            break;

        // Parent asked to see how big we want to be
        case MeasureSpec.UNSPECIFIED:
            if (childDimension >= 0) {
                // Child wants a specific size... let him have it
                resultSize = childDimension;
                resultMode = MeasureSpec.EXACTLY;
            } else if (childDimension == LayoutParams.MATCH_PARENT) {
                // Child wants to be our size... find out how big it should
                // be
                resultSize = View.sUseZeroUnspecifiedMeasureSpec ? 0 : size;
                resultMode = MeasureSpec.UNSPECIFIED;
            } else if (childDimension == LayoutParams.WRAP_CONTENT) {
                // Child wants to determine its own size.... find out how
                // big it should be
                resultSize = View.sUseZeroUnspecifiedMeasureSpec ? 0 : size;
                resultMode = MeasureSpec.UNSPECIFIED;
            }
            break;
        }
        return MeasureSpec.makeMeasureSpec(resultSize, resultMode);
    }

上述方法的主要作用是根据父容器的 MeasureSpec 同时结合 View 本身的 LayoutParams 来确定子元素的 MeasureSpec。这里简单的阐述下该方法的逻辑:
当 View 的 layout_width / layout_height 是固定宽高的时候:
不管父容器的 MeasureSpec 是什么,View 的 mode 都是EXACTLY,size 遵循 LayoutParams 中的大小。
当 View 的 layout_width / layout_height 是 match_parent时:
如果父容器的 mode 是 EXACTLY,那么 View 的 mode 为 EXACTLY,size 是父 View 的剩余空间。
如果父容器的 mode 是 AT_MOST,那么 View 的 mode 也为 AT_MOST,size 为父 View 的剩余空间。
当 View 的 layout_width / layout_height 是 wrap_parent时:
无论父容器的 mode 是 EXACTLY 还是 AT_MOST ,View 的 mode 总为 AT_MOST,size 不能超过父 View 的剩余空间。

现在我们终于获得了子 View 的 MeasureSpec,这个时候 View 就需要开始测量自己本身了。

对于不同的 View 来说,一般都会重写 onMeasure 方法以便根据自己本身的内容和 MeasureSpec 来测量自己本身的宽高,最后调用 setMeasuredDimension 方法完成设置。为了简明起见,这里我们不妨看一下 View#onMeasure 方法的默认实现:

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

getDefaultSize 这个方法很好理解,在 AT_MOST 和 EXACTLY 模式下,getDefaultSize 返回的大小就是 measureSpec 中的 specSize。在 UNSPECIFIED 这中情况下,View 的大小为 getSuggestedMinimunWidth/Height的返回指。我们选取 getSuggestedMinimumWidth 看一下它的源码:

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

可见如果设置了 minWidth 属性,则为 mMinWidth。如果没有设置则跟 View 的 background 有关。我们再来看一下 Drawable#getMinimumWidth 方法:

public int getMinimumWidth() {
        final int intrinsicWidth = getIntrinsicWidth();
        return intrinsicWidth > 0 ? intrinsicWidth : 0;
}

可见,getMinimumWidth 返回的就是 Drawable 的原始宽度。当然这是在 Drawable 有原始宽度的情况下,否则就返回0。

小结
现在我们大致明白了整个 View 绘制流程中的 measure 过程。首先顶级 View —— DecorView 会根据 window.size 和 window.layoutParams 来测量自身,同时作为一个父 View 它还会确定子 View 的 measureSpec 参数,并将测量的流程传递给自己的子 View。接着,对于普通的 View 来讲,会根据 onMeasure 方法中具体实现的逻辑,并结合其父 View 提供的 measureSpec 和 自身的 LayoutParams 这两个参数完成自身的测量。最后会调用 setMeasuredDimension 方法来设置自身测量后的宽高。

3.View 的 layout 流程

根据之前的分析可知,View 的 layout 也是从 ViewRootImpl 中的 performTraversals 开始的。最先被调用的依然是 DecorView 的 layout 方法,那么 DecorView 是如何确定自己的位置的?在 ViewRootImpl#performTraversals 方法中,直接调用了 DecorView 的 layout 方法:

mView.layout(0, 0, mView.getMeasuredWidth(), mView.getMeasuredHeight()); 

这个里的 getMeasuredWidth / getMeasuredHeight 获取的正是在 measure 过程中测量后的宽高。我们再来看看 DecorView#layout 方法,由于 DecorView 继承自 ViewGroup ,DecorView#layout 方法也即是 ViewGroup#layout 方法:

    @Override
    public final void layout(int l, int t, int r, int b) {
        if (!mSuppressLayout && (mTransition == null || !mTransition.isChangingLayout())) {
            if (mTransition != null) {
                mTransition.layoutChange(this);
            }
            super.layout(l, t, r, b);
        } else {
            // record the fact that we noop'd it; request layout when transition finishes
            mLayoutCalledWhileSuppressed = true;
        }
    }

可见ViewGroup#layout 方法又调用 View#layout 方法,而 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<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;
    }

整个 layout 方法会通过 setFrame 方法来设定 View 的四个顶点的位置,也即是 View 在父容器中的位置。在这里,对于 DecorView 来讲,其左上角的坐标为(0,0),而其右下角的坐标则有其在 measure 过程中所确定的宽高来决定。

回到 View#setFrame 方法中,有这样几条语句:

    mLeft = left;
    mTop = top;
    mRight = right;
    mBottom = bottom;

上面说到,在 layout 方法中我们确定了 View 的四个定点。根据这四个顶点我们很容易计算出 View 的宽高:

    public final int getWidth() {
        return mRight - mLeft;
    }
    
    public final int getHeight() {
        return mBottom - mTop;
    }

看到这,可能就会有疑问:View 的宽高不是在 measure 过程中就已经确定了的吗?这里获得的宽高又是什么呢?或者说 getWidth / getHeight 和 getMeasuredWidth / getMeasuredHeight 有什么区别?
在一般情况下,View 的实际宽高和测量宽高是相等的,只不过这两者的形成时机不同。View 的测量宽高实在 View 的 measure 过程中确定的,而 View 的实际宽高是在 View 的 layout 过程中确定的。

在确定好自己的位置之后,同时作为一个父 View 的 DecorView 就会调用 onLayout 方法去布置自己的子 View 了。不同的 ViewGroup 其 onLayout 方法的实现也不同。这里我们来看看 DecorView ,即 FrameLayout 的具体实现。在 FrameLayout#onLayout 中,调用了 layoutChildren 方法:

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

再来看看 FrameLayout#layoutChildren 这个方法:

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

这里简单分析下 layoutChildren 的代码逻辑:
首先5~9行确定了父容器的边界,接着遍历所有的子元素,根据子元素的 Gravity 属性的不同来计算子元素左上角的位置即 childLeft 和 childTop 的值。最后,由于在之前的 measure 方法中我们已经确定了子元素的宽高,所以每个子元素所在的矩形区域也就相应的确定了。这里只需要调用子元素的 layout 方法,来确定子元素的位置,并将 layout 流程传递下去即可。

小结
到这里,View 的 layout 过程就完成了。layout 过程的作用是 ViewGroup 用来确定子元素的位置的。整个过程也是从 DecorView 开始的,DecorView 会根据自己在 measure 过程中计算出的 MeasuredWidth 和 MeasuredHeight 来确定自己的位置。同时 DecorView 作为一个 ViewGroup 也会负责去确定自己的子元素的位置,并将 layout 的流程传递下去。

3.View 的 Draw 流程

最后只剩下 View 的绘制过程了,整个过程比较简单。我们依然从 DecorView 开始分析。由于 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 if need
         *      2. If necessary, save the canvas' layers to prepare for fading
         *      3. Draw view's content
         *      4. Draw children (dispatchDraw)
         *      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)
        final int viewFlags = mViewFlags;
        if (!verticalEdges && !horizontalEdges) {
            // Step 3, draw the content
            if (!dirtyOpaque) onDraw(canvas);

            // Step 4, draw the children
            dispatchDraw(canvas);

            // Step 6, draw decorations (scrollbars)
            onDrawScrollBars(canvas);

            if (mOverlay != null && !mOverlay.isEmpty()) {
                mOverlay.getOverlayView().dispatchDraw(canvas);
            }

            // we're done...
            return;
        }

        // Step 2, save the canvas' layers
        ...

        // 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

        // Step 6, draw decorations (scrollbars)
        onDrawScrollBars(canvas);
    }

注释写的如此详细,看来有必要为之配图了:

View draw 流程
View draw 流程

这里我们再来看看 dispatchDraw 这个方法它是如何将 View 的绘制过程传递下去的。显然对于普通的 View 来讲,它只需要绘制好自身就可以了,因此 View#dispatchDraw 方法的实现为空。而作为 ViewGroup 在绘制自身的同时还需要将绘制流程传递给子元素。期中涉及到的相关方法如下:

dispatchDraw(Canvas canvas){

...

 if ((flags & FLAG_RUN_ANIMATION) != 0 && canAnimate()) {
     final boolean buildCache = !isHardwareAccelerated();
            for (int i = 0; i < childrenCount; i++) {
                final View child = children[i];
                if ((child.mViewFlags & VISIBILITY_MASK) == VISIBLE) {
                    final LayoutParams params = child.getLayoutParams();
                    attachLayoutAnimationParameters(child, params, i, childrenCount);
                    bindLayoutAnimation(child);
                    if (cache) {
                        child.setDrawingCacheEnabled(true);
                        if (buildCache) {
                            child.buildDrawingCache(true);
                        }
                    }
                }
            }

     final LayoutAnimationController controller = mLayoutAnimationController;
            if (controller.willOverlap()) {
                mGroupFlags |= FLAG_OPTIMIZE_INVALIDATE;
            }

    controller.start();
}

//draw children
 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);
}

通过上面的源码我们也可以知道,在我们自定义 View 的时候,一般只需要去重写 View#onDraw 方法来绘制 View 的具体内容就可以了。而 View#draw 这个方法还帮我们做了很多其它的事情。

4.总结

Measure 过程
自上而下遍历,DecorView 根据 window.size 和 window.LayoutParams 这两个参数先确定自身的 MeasureSpec。同时作一个父 View 它会根据自身的 MeasureSpec 和子 View 的 LayoutParams 获取 ChildView 的 MeasureSpec,回调 ChildView.measure 方法,最终调用 setMeasuredDimension 得到 ChildView 的尺寸:mMeasuredWidth 和 mMeasuredHeight

Layout 过程
自上而下遍历,根据 Measure 过程中得到的每个 View 的 mMeasuredWidth 和 mMeasuredHeight 与计算得到的每个 ChildView 的 ChildLeft,ChildTop 进行布局:child.layout(left,top,left + width,top + height);

Draw 过程
自上而下遍历,父 View 除了绘制自身外,还需要将整个绘制过程传递给自己的子元素。

最后,整个 View 的绘制流程我们总结为如下一张流程图,需要说明的是,用户主动调用 request,只会出发 measure 和 layout 过程,而不会执行 draw 过程。

View 绘制流程
View 绘制流程
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 151,511评论 1 330
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 64,495评论 1 273
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 101,595评论 0 225
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 42,558评论 0 190
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 50,715评论 3 270
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 39,672评论 1 192
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,112评论 2 291
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,837评论 0 181
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,417评论 0 228
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,928评论 2 232
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,316评论 1 242
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,773评论 2 234
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,253评论 3 220
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,827评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,440评论 0 180
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 34,523评论 2 249
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 34,583评论 2 249

推荐阅读更多精彩内容