Android O: View的绘制流程(二)：测量

在前一篇博客Android O: View的绘制流程(一): 创建和加载中，
我们分析了系统创建和加载View的过程，这部分内容完成了View绘制的前置工作。

本文开始分析View的测量的流程。

---

一、绘制流程的起点
在分析View的测量的流程前，我们先来寻找一下界面绘制流程的起点。
当Activity启动时，会调用ActivityThread的handleLaunchActivity方法：

private void handleLaunchActivity(ActivityClientRecord r, Intent customIntent, String reason) {
    ............
    //这部分代码，会调用Activity的onCreate， 进而调用setContentView
    //完成上一篇博客描述的前置工作
    Activity a = performLaunchActivity(r, customIntent);

    if (a != null) {
        .............
        //重点关注该函数
        handleResumeActivity(r.token, false, r.isForward,
                !r.activity.mFinished && !r.startsNotResumed, r.lastProcessedSeq, reason);
        .............
    } else {
        .............
    }
}

我们跟进一下handleResumeActivity函数：

final void handleResumeActivity(IBinder token,
            boolean clearHide, boolean isForward, boolean reallyResume, int seq, String reason) {
    ..........
    // 会回调Activity的onResume接口
    r = performResumeActivity(token, clearHide, reason);

    if (r != null) {
        final Activity a = r.activity;
        .........
        if (r.window == null && !a.mFinished && willBeVisible) {
            //之前已经创建出Activity对应的PhoneWindow和DecorView
            //将这些对象记录到ActivityRecord中
            r.window = r.activity.getWindow();
            View decor = r.window.getDecorView();
            decor.setVisibility(View.INVISIBLE);

            //得到WindowManagerImpl
            ViewManager wm = a.getWindowManager();
            WindowManager.LayoutParams l = r.window.getAttributes();
            a.mDecor = decor;
            ..........
            //如果Activity可见
            if (a.mVisibleFromClient) {
                if (!a.mWindowAdded) {
                    a.mWindowAdded = true;
                    //Activity的DecorView递交给WindowManager
                    wm.addView(decor, l);
                } else {
                    ...........
                }
            }
        } else if (...) {
            .......
        }
        .......
    } else {
        .........
    }
}

从上述代码可以看出，解析完XML对应的View后，
最终将DecorView递交给WindowManager。

我们跟进一下WindowManagerImpl中的addView函数：

    public void addView(@NonNull View view, @NonNull ViewGroup.LayoutParams params) {
        applyDefaultToken(params);
        //实际上定义于WindowManagerGlobal中
        mGlobal.addView(view, params, mContext.getDisplay(), mParentWindow);
    }

继续跟进WindowManagerGlobal中的代码：

public void addView(View view, ViewGroup.LayoutParams params,
        Display display, Window parentWindow) {
    ............
    final WindowManager.LayoutParams wparams = (WindowManager.LayoutParams) params;
    //进一步调整wparams
    .............
    ViewRootImpl root;
    View panelParentView = null;

    synchronized (mLock) {
        ..........
        //创建出View对应的ViewRoot
        root = new ViewRootImpl(view.getContext(), display);
        view.setLayoutParams(wparams);

        mViews.add(view);
        mRoots.add(root);
        mParams.add(wparams);

        try {
            //关联View和ViewRootImpl
            root.setView(view, wparams, panelParentView);
        } catch (RuntimeException e) {
            ...........
        }
    }
}

至此我们知道了，WindowManager将DecorView和对应的ViewRootImpl关联起来了。
现在来一起看看ViewRootImpl的setView函数：

public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {
    synchronized (this) {
        if (mView == null) {
            mView = view;
            ...........
            //初次布局开始
            requestLayout();
            ...........
        }
    }
}

容易看出ViewRootImpl与View关联后，会调用requestLayout函数，
该函数将开启整个绘制流程。

眼见为实，我们来看看这个requestLayout函数：

    public void requestLayout() {
        if (!mHandlingLayoutInLayoutRequest) {
            checkThread();
            mLayoutRequested = true;
            //继续跟进
            scheduleTraversals();
        }
    }

    void scheduleTraversals() {
        //mTraversalScheduled用于限制绘制的次数
        if (!mTraversalScheduled) {
            mTraversalScheduled = true;
            ...........
            //将mTraversalRunnable加入执行队列
            mChoreographer.postCallback(
                    Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
            ...........
        }
    }

最后，我们来看看TraversalRunnable的实现：

    final class TraversalRunnable implements Runnable {
        @Override
        public void run() {
            doTraversal();
        }
    }

TraversalRunnable在执行时，会调用doTraversal函数，对应代码如下：

void doTraversal() {
    if (mTraversalScheduled) {
        mTraversalScheduled = false;
        ..........
        //开始绘制了
        performTraversals();
        ..........
    }
}

绘制的主要逻辑定义于ViewRootImpl的performTraversals中，
该函数会遍历整个视图书，逐一绘制每个View。

performTraversals函数接近1000行左右且涉及较多琐碎的细节，
个人感觉没有逐行解析的必要，因此我们主仅关注主要的逻辑。

实际上performTraversals的代码流程可以大致分为三个阶段，如下所示：

private void performTraversals() {
    .............
    // 测量阶段
    int childWidthMeasureSpec = getRootMeasureSpec(mWidth, lp.width);
    int childHeightMeasureSpec = getRootMeasureSpec(mHeight, lp.height);
    ............
    performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);
    ............
    // 布局阶段
    performLayout(lp, mWidth, mHeight);
    ............
    // 绘制阶段
    performDraw();
}

总结一下上述整个代码的调用流程，大致如下所示：

二、Measure阶段
将performTraversals划分为三个阶段后，整体的逻辑就可以简化为下图:

现在我们来看看其中Measure阶段的代码。

2.1 MeasureSpec
在分析测量的代码前，我们先要了解一下MeasureSpec的概念。
MeasureSpec是定义于View.java中的内部类，表示一个32位的整形值。
它的高2位表示测量模式SpecMode，低30位表示在相应模式下的测量尺寸SpecSize。

目前SpecMode的取值可以为以下三种：

/**
 * Measure specification mode: The parent has not imposed any constraint
 * on the child. It can be whatever size it wants.
 */
 public static final int UNSPECIFIED = 0 << MODE_SHIFT;

/**
 * Measure specification mode: The parent has determined an exact size
 * for the child. The child is going to be given those bounds regardless
 * of how big it wants to be.
 */
 public static final int EXACTLY     = 1 << MODE_SHIFT;

/**
 * Measure specification mode: The child can be as large as it wants up
 * to the specified size.
 */
 public static final int AT_MOST     = 2 << MODE_SHIFT;

如注释所述：
UNSPECIFIED 表示不指定测量模式，对应的场景是：
父视图没有限制子试图大小，子试图可以是想要的任何尺寸。
这种模式基本用不到。

EXACTLY 表示精确测量模式，对应的场景是：
父视图已经指定了子试图的精确大小，此时测量值就是SpecSize的值。
当视图的layout_width或者layout_height指定为具体的数值，
或指定为match_parent时，该模式生效。

AT_MOST 表示最大值模式，对应的场景是：
当视图的layout_width或layout_height指定为wrap_content时，
子视图的尺寸可以是不超过父视图允许最大值的任何尺寸。

我们来看看前文代码中的getRootMeasureSpec函数：

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

从代码来看，根据LayoutParams的参数，getRootMeasureSpec会得到对应模式的MeasureSpec。
其中主要用到的还是EXACTLY和AT_MOST模式。

对于DecorView而言，它的MeasureSpec由窗口尺寸和其自身的LayoutParams共同决定；
对于普通的View，它的MeasureSpec由父视图的MeasureSpec和自身的LayoutParams共同决定。

2.2 measure
了解完MeasureSpec后，我们来看看performMeasure函数：

private void performMeasure(int childWidthMeasureSpec, int childHeightMeasureSpec) {
    ........
    //实际上调用的还是View的measure接口
    mView.measure(childWidthMeasureSpec, childHeightMeasureSpec);
    ........
}

我们跟进View的measure函数：

//参数为父ViewGroup对当前View的约束信息
public final void measure(int widthMeasureSpec, int heightMeasureSpec) {
    //当前View为ViewGroup且设置为视觉边界布局模式时，才返回true
    boolean optical = isLayoutModeOptical(this);
    //当前View与父容器的模式不同时，需要调整MeasureSpec
    if (optical != isLayoutModeOptical(mParent)) {
        ............
        widthMeasureSpec  = MeasureSpec.adjust(widthMeasureSpec,  optical ? -oWidth  : oWidth);
        heightMeasureSpec = MeasureSpec.adjust(heightMeasureSpec, optical ? -oHeight : oHeight);
    }

    // Suppress sign extension for the low bytes
    // 计算key值, 用于判断是否有缓存及作为存储键值
    long key = (long) widthMeasureSpec << 32 | (long) heightMeasureSpec & 0xffffffffL;
    if (mMeasureCache == null) mMeasureCache = new LongSparseLongArray(2);

    //判断是否需要强制重新布局
    //例如View调用requestLayout时，会在mPrivateFlags添加该标记
    final boolean forceLayout = (mPrivateFlags & PFLAG_FORCE_LAYOUT) == PFLAG_FORCE_LAYOUT;

    // 以下其实就是判断是否需要重新布局
    // Optimize layout by avoiding an extra EXACTLY pass when the view is
    // already measured as the correct size. In API 23 and below, this
    // extra pass is required to make LinearLayout re-distribute weight.
    final boolean specChanged = widthMeasureSpec != mOldWidthMeasureSpec
            || heightMeasureSpec != mOldHeightMeasureSpec;
    final boolean isSpecExactly = MeasureSpec.getMode(widthMeasureSpec) == MeasureSpec.EXACTLY
            && MeasureSpec.getMode(heightMeasureSpec) == MeasureSpec.EXACTLY;
    final boolean matchesSpecSize = getMeasuredWidth() == MeasureSpec.getSize(widthMeasureSpec)
            && getMeasuredHeight() == MeasureSpec.getSize(heightMeasureSpec);
    final boolean needsLayout = specChanged
            && (sAlwaysRemeasureExactly || !isSpecExactly || !matchesSpecSize);

    //强制重新布局或需要重新布局
    if (forceLayout || needsLayout) {
        // first clears the measured dimension flag
        mPrivateFlags &= ~PFLAG_MEASURED_DIMENSION_SET;

        //尝试解析RTL相关的属性
        resolveRtlPropertiesIfNeeded();

        //没有forceLayout时，尝试从缓存获取
        int cacheIndex = forceLayout ? -1 : mMeasureCache.indexOfKey(key);

        //获取缓存失败，或忽略缓存时，才开始测量
        if (cacheIndex < 0 || sIgnoreMeasureCache) {
            // measure ourselves, this should set the measured dimension flag back
            onMeasure(widthMeasureSpec, heightMeasureSpec);
            mPrivateFlags3 &= ~PFLAG3_MEASURE_NEEDED_BEFORE_LAYOUT;
        } else {
            //命中缓存，直接从缓存取结果
            long value = mMeasureCache.valueAt(cacheIndex);
            // Casting a long to int drops the high 32 bits, no mask needed
            setMeasuredDimensionRaw((int) (value >> 32), (int) value);
            mPrivateFlags3 |= PFLAG3_MEASURE_NEEDED_BEFORE_LAYOUT;
        }
        ...........
    }

    mOldWidthMeasureSpec = widthMeasureSpec;
    mOldHeightMeasureSpec = heightMeasureSpec;

    //存入缓存
    mMeasureCache.put(key, ((long) mMeasuredWidth) << 32 |
            (long) mMeasuredHeight & 0xffffffffL); // suppress sign extension
}

从上面的代码来看，当需要(包括强制)重新布局且不使用(包括无缓存)缓存数据时，
才会调用onMeasure进行View的测量工作。

上述代码的整体流程，大致如下图所示：

2.3 ViewGroup的onMeasure
onMeasure函数一般会被View的子类覆盖，因此对于DecorView而言，
实际调用的应该是FrameLayout的onMeasure方法。

我们来跟进一下FrameLayout的onMeasure方法：

protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
    //FrameLayout是ViewGroup的子类， 此处获取子View的数量
    int count = getChildCount();

    //长或宽的SpecMode不为EXACTLY时， measureMatchParentChildren置为true
    //意味着ViewGroup的长或宽为wrap_content
    final boolean measureMatchParentChildren =
            MeasureSpec.getMode(widthMeasureSpec) != MeasureSpec.EXACTLY ||
            MeasureSpec.getMode(heightMeasureSpec) != MeasureSpec.EXACTLY;
    mMatchParentChildren.clear();

    int maxHeight = 0;
    int maxWidth = 0;
    int childState = 0;

    //依次measure子View
    for (int i = 0; i < count; i++) {
        final View child = getChildAt(i);

        //判断能否measure该子View
        if (mMeasureAllChildren || child.getVisibility() != GONE) {
            //具体的测量函数
            measureChildWithMargins(child, widthMeasureSpec, 0, heightMeasureSpec, 0);

            //不断迭代出子View需要的最大宽度和最大高度
            final LayoutParams lp = (LayoutParams) child.getLayoutParams();
            maxWidth = Math.max(maxWidth,
                    child.getMeasuredWidth() + lp.leftMargin + lp.rightMargin);
            maxHeight = Math.max(maxHeight,
                    child.getMeasuredHeight() + lp.topMargin + lp.bottomMargin);

            //迭代childState
            childState = combineMeasuredStates(childState, child.getMeasuredState());
            if (measureMatchParentChildren) {
                if (lp.width == LayoutParams.MATCH_PARENT ||
                        lp.height == LayoutParams.MATCH_PARENT) {
                    //统计matchParentChildren
                    mMatchParentChildren.add(child);
                }
            }
        }
    }

    // Account for padding too
    // 最大宽度和高度需要叠加padding
    maxWidth += getPaddingLeftWithForeground() + getPaddingRightWithForeground();
    maxHeight += getPaddingTopWithForeground() + getPaddingBottomWithForeground();

    // Check against our minimum height and width
    // 需要判断是否满足设置的最小宽高的要求
    maxHeight = Math.max(maxHeight, getSuggestedMinimumHeight());
    maxWidth = Math.max(maxWidth, getSuggestedMinimumWidth());

    // Check against our foreground's minimum height and width
    // 还需要满足前景图像的要求
    final Drawable drawable = getForeground();
    if (drawable != null) {
        maxHeight = Math.max(maxHeight, drawable.getMinimumHeight());
        maxWidth = Math.max(maxWidth, drawable.getMinimumWidth());
    }

    //经过了以上一系列步骤后，我们就得到了ViewGroup的maxHeight和maxWidth的最终值
    //表示当前容器用这个尺寸就能够正常显示其所有子View

    //此处resolveSizeAndState根据数值、MeasureSpec和childState计算出最终的数值
    //然后用setMeasuredDimension保存到mMeasuredWidth与mMeasuredHeight成员变量 (定义于View.java)
    setMeasuredDimension(resolveSizeAndState(maxWidth, widthMeasureSpec, childState),
            resolveSizeAndState(maxHeight, heightMeasureSpec,
                    childState << MEASURED_HEIGHT_STATE_SHIFT));

    //部分子View需要做最后的测量
    //当ViewGroup存在wrap_content的size（初始时，未明确定义大小）
    //且child View存在match_parent的size时（需要依赖父容器）
    //那么父容器计算完毕后，这类child view需要重新测量
    count = mMatchParentChildren.size();
    if (count > 1) {
        for (int i = 0; i < count; i++) {
            //根据父容器的参数生成新的约束条件
            ............
            //重新测量
            child.measure(childWidthMeasureSpec, childHeightMeasureSpec);
        }
    }
}

从以上代码的执行流程，我们可以看到，作为容器的ViewGroup，
将通过measureChildWithMargins方法，对所有子View进行测量，
然后才会计算自身的测量结果。

FrameLayout的onMeasure函数整体流程可以概括为下图：

2.4 measureChildWithMargins
接下来，我们来看下ViewGroup的measureChildWithMargins方法：

protected void measureChildWithMargins(View child,
        int parentWidthMeasureSpec, int widthUsed,
        int parentHeightMeasureSpec, int heightUsed) {
    //获取子View的LayoutParams
    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);

    //调用子View的measure
    child.measure(childWidthMeasureSpec, childHeightMeasureSpec);
}

从上述代码可以看出，ViewGroup会利用getChildMeasureSpec函数计算出子View的约束条件，
然后再调用子View的measure函数。

我们看看getChildMeasureSpec函数：

// 从measureChildWithMargins函数，可以看出:
// spec为父View的MeasureSpec
// padding为父View在相应方向的已用尺寸, 加上父View的padding和子View的margin
// childDimension为子View的LayoutParams相应方向的值
public static int getChildMeasureSpec(int spec, int padding, int childDimension) {
    int specMode = MeasureSpec.getMode(spec);
    int specSize = MeasureSpec.getSize(spec);

    //得到父View在相应方向上的可用大小
    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:
            // 表示子View的LayoutParams指定了具体大小值（xx dp）
            if (childDimension >= 0) {
                resultSize = childDimension;
                resultMode = MeasureSpec.EXACTLY;
            } else if (childDimension == LayoutParams.MATCH_PARENT) {
                // Child wants to be our size. So be it.
                // 子View为match_parent
                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.
                // 子View为wrap_content
                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;
        case MeasureSpec.UNSPECIFIED:
            //不关注
            ................
    }

    //noinspection ResourceType
    return MeasureSpec.makeMeasureSpec(resultSize, resultMode);
}

上面的方法展现了根据父View的MeasureSpec和子View的LayoutParams生成子View的MeasureSpec的过程，
从代码可以看出：
当子View指定了具体的大小时，resultSize就是指定的size，resultMode为EXACTLY，
父View对其没有影响；
当子View指定为MATCH_PARENT时，resultSize为父View可用的size，
resultMode与父View一致；
当子View指定为WRAP_CONTENT时，resultSize为父View可用的size，
resultMode为AT_MOST。

从前文我们知道，获取完子View的MeasureSpec后，
measureChildWithMargins就会调用子View的measure方法。
对于ViewGroup及其子类而言，将重新递归调用ViewGroup的onMeasure方法；
对于View及其子类而言，将调用View的onMeasure方法。

由于measureChildWithMargins会递归调用ViewGroup的onMeasure方法，
可以看出整个View的测量顺序是先序遍历的，但最终计算结果时是后序遍历的，
即子View测量完毕后，才能得到父View的size。

2.5 View的onMeasure
现在我们跟进一下View的onMeasure方法：

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

从代码可以看出，普通View只需要完成自身的测量工作即可。
View以getDefaultSize方法的返回值来作为测量结果，通过setMeasuredDimension方法进行设置。

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;
            break;
        // AT_MOST和EXACTLY这两种情况都返回了SpecSize作为result
        // 自定义View直接继承View类时，需要自己实现
        // 否则wrap_content就和match_parent效果一样
        case MeasureSpec.AT_MOST:
        case MeasureSpec.EXACTLY:
            result = specSize;
            break;
        }
        return result;
    }

三、总结
至此，我们大致了解了View的测量流程。
个人觉得重点在于了解MeasureSpec对测量过程的影响，
同时知道测量的顺序是先序遍历，计算最终结果是后序遍历即可。

此外，当父容器的宽或高为wrap_content，其子View的宽或高为match_parent时，
父容器得到最终的宽、高后，需要重新测量这部分子View。

下一篇博客，我们将继续关注View绘制的布局流程。