ViewRoot，DecorView，MeasureSpec和View的工作原理——Android开发艺术探索笔记

原文链接 http://sparkyuan.me/ 转载请注明出处

View的绘制流程是从ViewRoot的performTraversals方法開始的。它经过measure、layout和draw三个过程才干终于将一个View绘制出来，当中measure用来測量View的宽和高，layout用来确定View在父容器中的放置位置，而draw则负责将View绘制在屏幕上。

ViewRoot和DecorView

ViewRoot

• ViewRoot相应ViewRootImpl类，它是连接WindowManager和DecorView的纽带，View的三大流程均通过ViewRoot来完毕。
• ActivityThread中。Activity创建完毕后，会将DecorView加入到Window中，同一时候创建ViewRootImpl对象，并建立两者的关联。

DecorView

• DecorView作为顶级View，普通情况下它内部包括一个竖直方向的LinearLayout，在这个LinearLayout里面有上下两个部分（详细情况和Android版本号及主体有关），上面的是标题栏，以下的是内容栏。在Activity中通过setContentView所设置的布局文件事实上就是被加到内容栏之中的，而内容栏的id是content，在代码中能够通过ViewGroup content = （ViewGroup)findViewById(R.android.id.content)来得到content相应的layout。
• DecorView事实上是一个FrameLayout，View层的事件都先经过DecorView。然后才传递给我们的View。

MeasureSpec

在測量过程中，系统会将View的LayoutParams依据父容器所施加的规则转换成相应的MeasureSpec。然后再依据这个MeasureSpec来測量出View的宽和高。測量出来的宽和高不一定等于View终于的宽和高。

MeasureSpec将SpecMode和SpecSize打包成一个int值来避免过多的对象内存分配。高2位代表SpecMode，低30位代表SpecSize，SpecMode是指測量模式。而SpecSize是指在某种測量模式下的规格大小。

SpecMode有三类：

• UNSPECIFIED：父容器不正确View有不论什么限制，要多大给多大。这样的情况一般用于系统内部。表示一种測量状态
• EXACTLY：父容器已经检測出View所须要的精确大小，这个时候View的终于大小就是SpecSize所指定的值。它相应于LayoutParams中的match_parent和详细的数值这两种模式
• AT_MOST：父容器指定了一个可用大小即SpecSize，View的大小不能大于这个值，详细是什么值要看不同View的详细实现。它相应于LayoutParams中的wrap_content。

普通MeasureSpec的创建规则

对于普通View。其MeasureSpec由父容器的MeasureSpec和自身的LayoutParams来共同决定。

• 子View为精确宽高，不管父容器的MeasureSpec，子View的MeasureSpec都为精确值且遵循LayoutParams中的值。
• 子View为match_parent时，假设父容器是精确模式，则子View也为精确模式且为父容器的剩余空间大小；假设父容器是最大模式。则子View也是最大模式且不会超过父容器的剩余空间。
• 子View为wrap_content时。不管父View是精确还是最大模式，子View的模式总是最大模式。且不会超过父容器的剩余空间。

View的工作流程

measure

ViewGroup的measure方法会遍历每一个子元素，并调用子元素内部的measure方法，measure源代码例如以下：

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

注：

• getDefaultSize()返回MeasureSpec中的specSize，也就是View測量后的大小。
• getSuggestedMinimumWidth()，View假设没有背景，那么返回android:minWidth这个属性指定的值，这个值能够为0；假设设置了背景，则返回背景的最小宽度和minWidth中的最大值。
• getSuggestedMinimumHeight()，与getSuggestedMinimumWidth()相似。
• 直接继承View的自己定义控件须要重写onMeasure方法并设置wrap_content时的自身大小，否则在布局中使用wrap_content时就相当于使用match_parent。

  由于LayoutParams=wrap_content的情况下，MeasureSpec为AT_MOST。所以View的宽和高为父容器当前剩余的空间，这样的效果与match_parent一致。详细处理方法要依据需求灵活决定。

怎样得到View的宽和高

在Activity的onCreate、onStart、onResume方法中均无法正确得到某个View的宽/高信息。这是由于View的measure过程和Activity的生命周期方法不是同步运行的，因此无法保证Activity运行了onCreate、onStart、onResume时某个View就已经測量完毕了，假设View还没有測量完毕，那么获得的宽/高就是0。

能够通过例如以下四个方法来解决问题：

• Activity或者View的onWindowFocusChanged方法（注意该方法会在Activity Pause和resume时被多次调用）
• view.post(new Runnable( {@Overidde public void run(){})})，在run方法中获取。
• ViewTreeObserver中的onGlobalLayoutListener中。
• 手动调用View的measure方法。

演示样例代码请參考原书P190页

layout

layout的作用是用来确定子视图在父视图中的位置。源代码例如以下：

public void layout(int l, int t, int r, int b) {
    int oldL = mLeft;
    int oldT = mTop;
    int oldB = mBottom;
    int oldR = mRight;
    boolean changed = setFrame(l, t, r, b);
    if (changed || (mPrivateFlags & LAYOUT_REQUIRED) == LAYOUT_REQUIRED) {
        if (ViewDebug.TRACE_HIERARCHY) {
            ViewDebug.trace(this, ViewDebug.HierarchyTraceType.ON_LAYOUT);
        }
        onLayout(changed, l, t, r, b);
        mPrivateFlags &= ~LAYOUT_REQUIRED;
        if (mOnLayoutChangeListeners != null) {
            ArrayList<OnLayoutChangeListener> listenersCopy =
                    (ArrayList<OnLayoutChangeListener>) 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 &= ~FORCE_LAYOUT;
}  

通过setFrame()确定四个顶点的位置，进而确定View在父容器中的位置。

在View的默认实现中，View的測量宽/高和终于宽/高是相等的，仅仅只是測量宽/高形成于View的measure过程，而终于宽/高形成于View的layout过程。即两者的赋值时机不同，測量宽/高的赋值时机略微早一些。多数情况下能够觉得View的測量宽/高就等于终于的宽/高，但对于在View的layout中改变了View的left、top、right、bottom四个属性时，得出的測量宽/高有可能和终于的宽/高不一致。

draw

draw的过程非常easy主要有以下几步：

• 绘制背景(background.draw)
• 绘制自己(onDraw)
• 绘制children(dispatchDraw)
• 绘制装饰(onDrawScrollBars)。

源代码例如以下

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有一个特殊的方法setWillNotDraw。假设一个View不须要绘制不论什么内容，设置这个标记位true后，系统会进行优化。默认情况下，View没有启用这个优化标记位，可是ViewGroup会默认启用这个优化标记位。

• 这个标记位对实际开发的意义是：假设自己定义控件继承于ViewGroup而且本身不具备绘制功能时，就能够开启这个标记位从而便于系统进行兴许的优化。当明白知道一个ViewGroup须要通过onDraw来绘制内容时，须要显示地关闭WILL_NOT_DRAW这个标记位。

欢迎转载。转载请注明本文链接http://blog.csdn.net/l664675249/article/details/50774617