每日一问 | 自定义控件测量模式真的和 match_parent，wrap_content 一一对应吗？

准备发的时候发现 @sukai丶同学跟我的回答差不多。。。本来想不发了，想了想，还是发吧。。。(主要是想给大家安利粤剧)

match_parent和wrap_content就一定对应MeasureSpec.EXACTLY和MeasureSpec.AT_MOST吗？

肯定不是。为什么呢？

因为View在measure时，它的宽高MeasureSpec完全是取决于父容器，父容器传的是什么它收到的就是什么。

如果这个父容器的onMeasure方法里面写死了每个子View的MeasureSpec的Mode为UNSPECIFIED的话，那么无论你在xml布局或者LayoutParams中怎么设置宽高都好，最终子View的onMeasure收到的也是UNSPECIFIED。

好吧，故意手动指定的不算，就以正常的角度来看：

我们都知道，自定义ViewGroup过程中，需要在onMeasure里面对子View进行测量。

在测量子View时，往往会通过measureChild、measureChildWithMargins方法来完成（比如FrameLayout、LinearLayout、CoordinatorLayout、ViewPager2）。

或者调用ViewGroup的静态方法getChildMeasureSpec来直接获取目标子View的MeasureSpec，然后手动measure（比如ScrollView、NestedScrollView、DrawerLayout、TabLayout、ConstraintLayout）。

其实，measureChild和measureChildWithMargins里面也是会通过getChildMeasureSpec方法来获取MeasureSpec的，也就是说，上面提到的这些容器，在测量它们的子View之前，都是先通过getChildMeasureSpec方法来获取子View的宽高MeasureSpec，然后传给子View的measure方法的。

好，那我们现在来看看getChildMeasureSpec方法里面做了什么：

public static int getChildMeasureSpec(int spec, int padding, int childDimension) {
    int specMode = MeasureSpec.getMode(spec);
    ......
    switch (specMode) {
        case MeasureSpec.EXACTLY:
            if (childDimension >= 0) {
                ......
                resultMode = MeasureSpec.EXACTLY;
            } else if (childDimension == ViewGroup.LayoutParams.MATCH_PARENT) {
                ......
                resultMode = MeasureSpec.EXACTLY;
            } else if (childDimension == ViewGroup.LayoutParams.WRAP_CONTENT) {
                ......
                resultMode = MeasureSpec.AT_MOST;
            }
            break;

        case MeasureSpec.AT_MOST:
            if (childDimension >= 0) {
                ......
                resultMode = MeasureSpec.EXACTLY;
            } else if (childDimension == ViewGroup.LayoutParams.MATCH_PARENT) {
                ......
                resultMode = MeasureSpec.AT_MOST;
            } else if (childDimension == ViewGroup.LayoutParams.WRAP_CONTENT) {
                ......
                resultMode = MeasureSpec.AT_MOST;
            }
            break;

        case MeasureSpec.UNSPECIFIED:
            if (childDimension >= 0) {
                ......
                resultMode = MeasureSpec.EXACTLY;
            } else if (childDimension == ViewGroup.LayoutParams.MATCH_PARENT) {
                ......
                resultMode = MeasureSpec.UNSPECIFIED;
            } else if (childDimension == ViewGroup.LayoutParams.WRAP_CONTENT) {
                ......
                resultMode = MeasureSpec.UNSPECIFIED;
            }
            break;
    }
    return MeasureSpec.makeMeasureSpec(resultSize, resultMode);
}

可以看到：

• 在父容器的specMode为EXACTLY时，一切正常（子View尺寸指定为match_parent或精确的dimen值时，Mode = EXACTLY，尺寸指定为wrap_content则Mode = AT_MOST）；

• 当父容器specMode为AT_MOST的时候，呵呵，可以看到，除了指定了dimen值之外，无论设置为match_parent或wrap_content，Mode最终都是会变成AT_MOST；

• 如果父容器specMode是UNSPECIFIED的话，跟上面的逻辑差不多，都是会变成UNSPECIFIED的，除非指定了精确的dimen值；

所以，View的onMeasure方法中收到的宽高MeasureSpec，不完全是由xml布局中设置的宽高或LayoutParams的宽高值决定的。

有那些因素影响着MeasureSpec的mode？

从刚刚的getChildMeasureSpec方法中可以看出，影响着View测量模式的因素主要是该View所属容器的测量模式。

也就是说，正常情况下（不是故意乱设置），View的测量模式是由它自身的尺寸 + 父容器的测量模式来决定的。

为什么大家都说MeasureSpec.UNSPECIFIED不常见呢？

MeasureSpec.UNSPECIFIED的相关知识：https://www.wanandroid.com/wenda/show/8613

大家都觉得这个模式不常见，很可能就是因为在编写布局时，View的宽高只能选择match_parent、wrap_content或者直接指定一个精确的尺寸，相对来说，MeasureSpec.UNSPECIFIED就显得不太透明了，因为在日常开发中，如不需定制View的话，基本上不会直接接触到。

MeasureSpec.UNSPECIFIED是不是真的不常见？

在日常定制View时，确实很少会专门针对这个模式去做特殊处理，大多数情况下，都会把它当成MeasureSpec.AT_MOST一样看待，就比如最最常用的TextView，它在测量时也是不会区分UNSPECIFIED和AT_MOST的。

不过，虽说这个模式比较少直接接触到，但很多场景下，我们已经在不知不觉中用上了，比如RecyclerView的Item，如果Item的宽/高是wrap_content且列表可滚动的话，那么Item的宽/高的测量模式就会是UNSPECIFIED。还有就是NestedScrollView和ScrollView，因为它们都是扩展自FrameLayout，所以它们的子View会测量两次，第一次测量时，子View的heightMeasureSpec的模式是写死为UNSPECIFIED的。

我们在自定义ViewGroup过程中，如果允许子View的尺寸比ViewGroup大的话，在测量子View时就可以把Mode指定为UNSPECIFIED。

最近读完了蒋防的《霍小玉传》，临川四梦之一《紫钗记》就是取材自这部小说的。不过，相比于《紫钗记》的圆满结局（“剑合钗圆”），蒋防笔下的霍小玉就没这么幸运了，她毁家为情，遇人不淑，最后含恨而终，为爱而死。正是“风流之士，共感玉之多情；豪侠之伦，皆怒生之薄行”。感兴趣的同学可以去看一下。最后推荐大家听一听粤剧《紫钗记·剑合钗圆》（寄调古曲《春江花月夜》)

贴一下霍小玉临终前痛斥负心汉李益的一段话："我为女子，薄命如斯。君是丈夫，负心若此！韶颜稚齿，饮恨而终。慈母在堂，不能供养。绮罗弦管，从此永休。徵痛黄泉，皆君所致！李君李君，今当永诀！我死之后，必为厉鬼，使君妻妾，终日不安！"

先说前两题，View的测量模式以及其尺寸，也就是View的MeasureSpec，其实是由View父容器MeasureSpec和View自身的LayoutParams决定。

相信大家都或多或少看过任主席的《开发艺术探索》，其中有一张著名的图至今被广大Blogger所借(C)用(V)：

这张图清晰的指出了父View的SpecMode和View的LayoutParams是如何决定View的SpecMode和SpecSize的。

经常写自定义ViewGroup的同学会发现，我们通常使用getChildMeasureSpec(int spec, int padding, int childDimension)方法来创建子View的MeasureSpec。这个方法就是进行了上图的流程，根据父View的SpecMode和子View的LayoutParams来得到一个size和一个mode。实际上真正生成子View测量规格的是MeasureSpec.makeMeasureSpec(int size，int mode)方法，该方法用public static修饰，也就是说父View完全可以绕过上图的流程，手动调用MeasureSpec.makeMeasureSpec()来自定义子View的MeasureSpec。

UNSPECIFIED 真的不常见吗？

常见又不常见。

不常见是因为根据上图，除非父View是MesureSpec.UNSPECIFIED，我们的View才可能是UNSPECIFIED，然而除了DecorView，我们说的父View大部分都是我们自己指定的宽高，xml中从来都不能选择UNSPECIFIED。DecorView不可能指定子View为UNSPECIFIED，因此我们接触到UNSPECIFIED的情况少之又少。

那为什么说常见呢？

实际上在我们平常使用的RecyclerView中，在item进行measure时，如果列表可滚动，并且item的宽或高设置了WRAP_CONTENT的话，那么接下来，itemView的onMeasure方法就会收到MesureSpec.UNSPECIFIED。

还有就是 @九天zone同学 发的链接里的NestedScrollView嵌套RecyclerView的场景，可以看到在NestedScrollView的measureChild方法里：

    protected void measureChild(View child, int parentWidthMeasureSpec,
            int parentHeightMeasureSpec) {
        ViewGroup.LayoutParams lp = child.getLayoutParams();

        int childWidthMeasureSpec;
        int childHeightMeasureSpec;

        // 
        childWidthMeasureSpec = getChildMeasureSpec(parentWidthMeasureSpec, getPaddingLeft()
                + getPaddingRight(), lp.width);

        //
        childHeightMeasureSpec = MeasureSpec.makeMeasureSpec(0, MeasureSpec.UNSPECIFIED);

        child.measure(childWidthMeasureSpec, childHeightMeasureSpec);
    }

可以看到这里宽高的MeasureSpec使用的方法是不一样的，最终的测量模式及尺寸也就不一样，这就是上文说的手动调用MeasureSpec.makeMeasureSpec()来干扰子View的MeasureSpec创建。

有同学可能会问：那么为什么要让子View UNSPECIFIED呢？

View设置了wrap_content，按理来说其specMode应该是AT_MOST，也就是说其尺寸不应该超过父View。但对于一个可滚动ViewGroup来说，子View的宽高是可以超出父View的。

举个栗子，对于一个水平滚动的RecyclerView来说，它自身的宽度一般是match_parent，也就是确定值，但是对于其item来说，宽度是可以无限大的。因为即使item的宽度超出了屏幕，RecyclerView只需要滚动就能将item完全显示出来，这种情况下，item想多宽就能有多宽，因此UNSPECIFIED显然比AT_MOST要更合适。

对于顶级 View 来说，测量模式和 match_parent，wrap_content 是一一对应的，查看这个方法：

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

对于普通 View 来说，测量模式和 match_parent，wrap_content 不是一一对应的，查看 getChildMeasureSpec 方法。

通常在一般单个控件的情况下，这两者是相对应的，但是如果对于ViewGroup组件而言就不一定了，以线性（垂直）布局为例，先measure子控件的大小，然后还需要计算是否有padding，那么它的实际大小就并不是view的大小，而且此时在onMearsure方法中获取获取到的数据就不一定准确了，它会优先MearsureChild子控件，然后再计算自身的线性布局控件大小，因此如果要想获取到准确的大小，那么就需要在onLayout中获取，此时的数据就是正确的

测量模式是和view自身空间以及父容器空间大小共同决定的

UNSPECIFIED是很常见的，比如match_parent,wrap_content

具体分析详见：<Android开发艺术探索>--View的工作原理

111

有没有大佬具体解答 View.measure(View.MeasureSpec.UNSPECIFIED, View.MeasureSpec.UNSPECIFIED)

获取宽高的具体问题出在哪里

实际上是由本身的模式和父类的模式共同得出的

EXACTLY/ AT_MOST/UNSPECIFIED都是属于SpecMode的。

EXACTLY：表示的模式是父容器已经测量出了View需要的精确大小（你已经看中了一个房子，他的大小已经确定了），它对应的是特定的数值与LayoutParams中的match_parent。（称为精确模式）

AT_MOST：表示的模式是父容器已经指定了一个SpecSize，View的大小不能超过这个值（你还没出去看房子，根据你的预算，你确定了可以买多少平米内的房子）。它对应的是LayoutParams中的wrap_conent。（称为最大模式）

1. 虽然上面说了，但不一定，因为对于一般的View来说，它的MeasureSpec是由父容器的MeasureSpec和自己的LayoutParams共同决定的。（🌰：当View的宽高为match_parent时，如果父容器为最大模式，该View的模式也是最大模式，而且不会超过父容器剩下的空间），就像合租一样，房子固定了，就算你确定了一套房，你租到的房间也不会超过它剩下的房间数。
2. 测量模式是由parentSpeceMode与childLayoutParams共同决定的。
3. 还剩下一个 UNSPECIFIED大家不用管，不常用？UNSPECIFIED：该模式表示父容器不对View的大小限制。一般用在系统内部多次Measure的情况下。

前段时间的blog正好从一个现象着重讲了UNSPECIFIED，再推一遍～

https://juejin.im/post/5d75e8cd6fb9a06afd662bf3