一、MeasureSpec 与 LayoutParams：它们到底是什么关系？
说实话，我刚接触 Android 绘制流程那会儿，也被 MeasureSpec 和 LayoutParams 搞晕过。这两个东西名字长得像，作用又纠缠在一起，很容易让人犯迷糊。
但说白了，它们的分工其实很清晰：
- LayoutParams：是子 View 的「愿望清单」。它告诉父容器：「我希望自己有多宽、多高」。比如 match_parent、wrap_content，或者一个具体的 dp 值。
- MeasureSpec：是父容器给子 View 的「最终指令」。它告诉子 View：「你最多能有多大，你该怎么量自己」。它由父容器的 MeasureSpec 和子 View 的 LayoutParams 共同计算得出。
嗯，你可以把 LayoutParams 想象成孩子跟妈妈说「我想吃三碗饭」，而 MeasureSpec 就是妈妈根据家里还剩多少米，最终告诉孩子「你最多吃两碗」。你看，孩子的愿望（LayoutParams）和实际情况（父容器的约束）一结合，就产生了最终的指令（MeasureSpec）。
核心结论：MeasureSpec 的生成公式 = 父容器的 MeasureSpec + 子 View 的 LayoutParams。缺一不可。
二、MeasureSpec 的三种模式：你必须要懂的三个状态
在深入 LayoutParams 如何影响 MeasureSpec 之前，我们先快速回顾一下 MeasureSpec 的三种模式。我习惯把它们记成三个词：
| 模式 | 含义 | 对应 LayoutParams |
|---|---|---|
| EXACTLY | 精确值，子 View 必须按这个大小来 | match_parent 或具体 dp 值 |
| AT_MOST | 最大值，子 View 不能超过这个值 | wrap_content |
| UNSPECIFIED | 无限制，子 View 想多大就多大 | ScrollView、ListView 等可滚动容器 |
这里有个坑，我刚开始做开发时踩过：UNSPECIFIED 模式并不常见，但一旦遇到，往往就是 bug 的来源。比如在 ScrollView 中嵌套 RecyclerView，如果不做处理，RecyclerView 会收到 UNSPECIFIED 的 MeasureSpec，导致它无限高，所有 item 一次性全部加载——性能灾难。
三、LayoutParams 如何影响 MeasureSpec 的生成？
好，现在进入正题。父容器在测量子 View 时，会调用 getChildMeasureSpec() 方法。这个方法的核心逻辑，就是根据父容器的 MeasureSpec 和子 View 的 LayoutParams，计算出子 View 的 MeasureSpec。
我们来看一下这个方法的简化逻辑（源码在 ViewGroup.java 中）：
public static int getChildMeasureSpec(int parentSpec, int padding, int childDimension) {
int parentMode = MeasureSpec.getMode(parentSpec);
int parentSize = MeasureSpec.getSize(parentSpec);
int resultSize;
int resultMode;
switch (parentMode) {
case MeasureSpec.EXACTLY:
if (childDimension >= 0) {
// 子 View 指定了具体 dp 值
resultSize = childDimension;
resultMode = MeasureSpec.EXACTLY;
} else if (childDimension == LayoutParams.MATCH_PARENT) {
// 子 View 想填满父容器
resultSize = parentSize - padding;
resultMode = MeasureSpec.EXACTLY;
} else if (childDimension == LayoutParams.WRAP_CONTENT) {
// 子 View 想包裹内容
resultSize = parentSize - padding;
resultMode = MeasureSpec.AT_MOST;
}
break;
case MeasureSpec.AT_MOST:
// 类似逻辑，但父容器本身也是 AT_MOST
// ...
break;
case MeasureSpec.UNSPECIFIED:
// 父容器无限制，子 View 基本也自由
// ...
break;
}
return MeasureSpec.makeMeasureSpec(resultSize, resultMode);
}你看，逻辑其实不复杂。关键点在于：当子 View 的 LayoutParams 是 wrap_content 时，父容器会把它转成 AT_MOST 模式。这意味着子 View 可以自己决定大小，但不能超过父容器给的上限。
避坑指南：我曾经遇到过一个 case，自定义 View 在 onMeasure 中直接使用了 MeasureSpec.getSize() 作为最终大小，没有判断 mode。结果在 wrap_content 时，View 被撑满了整个父容器，而不是包裹内容。这就是典型的「没有处理 AT_MOST 模式」的 bug。
四、LinearLayout 与 FrameLayout 的 MeasureSpec 计算差异
不同布局容器对 MeasureSpec 的计算方式是不同的。我挑两个最常用的来说：LinearLayout 和 FrameLayout。
4.1 FrameLayout：简单粗暴
FrameLayout 的测量逻辑非常直接。它遍历所有子 View，对每个子 View 调用 getChildMeasureSpec()，传入自己的 MeasureSpec 和子 View 的 LayoutParams。
关键点：FrameLayout 不会修改父容器传下来的 MeasureSpec。它只是简单地把自己的 MeasureSpec 传给子 View，然后让子 View 自己去计算。
举个例子：
// FrameLayout 的 onMeasure 简化逻辑
@Override
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
int count = getChildCount();
for (int i = 0; i < count; i++) {
final View child = getChildAt(i);
if (child.getVisibility() != GONE) {
// 直接使用父容器传下来的 MeasureSpec
measureChildWithMargins(child, widthMeasureSpec, 0, heightMeasureSpec, 0);
}
}
// ... 然后取所有子 View 的最大值作为自己的大小
}所以，在 FrameLayout 中，子 View 的 MeasureSpec 几乎完全由父容器的 MeasureSpec 和子 View 自己的 LayoutParams 决定。FrameLayout 本身不做任何「二次加工」。
4.2 LinearLayout：有「分配」逻辑
LinearLayout 就复杂多了。因为它有 orientation（方向）的概念，而且支持 weight（权重）分配。
LinearLayout 的测量分两步：
- 第一步：先测量所有没有 weight 的子 View。这些子 View 的 MeasureSpec 计算方式和 FrameLayout 类似。
- 第二步：如果有剩余空间，再分配给设置了 weight 的子 View。这些子 View 的 MeasureSpec 会被重新计算，size 变成「剩余空间 × weight 占比」。
这里有个细节：对于设置了 weight 的子 View，LinearLayout 会把它临时当成 wrap_content 来处理。为什么？因为 weight 的最终大小要在分配阶段才能确定，所以先让子 View 按 wrap_content 测量一次，拿到它的「自然大小」，然后再用剩余空间去补足。
关键差异总结：
- FrameLayout：直接传递父容器的 MeasureSpec，不做二次分配。子 View 的 MeasureSpec = f(父容器 MeasureSpec, 子 View LayoutParams)。
- LinearLayout：有 weight 分配逻辑，会重新计算部分子 View 的 MeasureSpec。子 View 的 MeasureSpec = f(父容器 MeasureSpec, 子 View LayoutParams, 其他子 View 的测量结果, 剩余空间)。
五、一张图看懂整个流程
说了这么多，我画了一张图来总结 MeasureSpec 的生成流程。你看完应该就全明白了：
六、实战中的选择建议
说了这么多理论，最后聊点实际的。我在项目中怎么选这两个容器？
- 如果子 View 之间没有依赖关系，用 FrameLayout。它的测量逻辑简单，性能更好。比如一个 Fragment 容器、一个遮罩层。
- 如果需要按比例分配空间，用 LinearLayout + weight。但要注意，weight 的测量会多走一轮，性能略差。如果子 View 数量不多（比如 2-3 个），完全没问题。
- 如果子 View 数量很多（比如 10+），而且需要按比例分配，我建议用 ConstraintLayout。它的测量效率比 LinearLayout 高，而且更灵活。
我曾经踩过的坑：在一个 LinearLayout 中放了 5 个 TextView，每个都设置了 weight 和 wrap_content。结果发现界面卡顿，测量耗时飙升。后来排查发现，LinearLayout 的两次测量 + weight 计算，在嵌套场景下会被放大。最终改用 ConstraintLayout 的 chain 来解决。
好了，这一章的内容就到这里。MeasureSpec 和 LayoutParams 的关系，说白了就是「愿望」和「现实」的博弈。理解了这一点，你再看 View 的测量流程，就会觉得豁然开朗。