修改含wrap_content ConstraintLayout子项的FrameLayout高度适配异常问题

该异常的核心原因是ConstraintLayout 2.x版本引入的跨测量流程缓存优化逻辑，和FrameLayout这类普通ViewGroup的实现存在本质差异，和布局代码本身的配置无关。

两类布局的测量逻辑差异 #

• 普通FrameLayout无持久化测量缓存：每次收到父布局传递的新测量请求时，都会基于最新的可用尺寸约束，完整执行子View测量流程，计算wrap_content模式下的真实高度，因此不存在尺寸不更新的问题。
• ConstraintLayout为了降低复杂布局的重复测量开销，会将上一次测量时的计算结果（包括子View尺寸、约束匹配结果、wrap模式下的自身高度计算值）存入本地缓存，后续测量时会通过key比对判断是否需要重新计算。

当前场景下的异常触发流程 #

1. 初始布局阶段，外层FrameLayout高度为50dp，向内层ConstraintLayout传递AT_MOST 50dp的高度测量Spec。此时ConstraintLayout测量到内部TextView的真实内容高度大于50dp，受Spec限制最终自身高度被截断为50dp，同时将本次测量结果写入本地缓存。
2. 运行时将外层FrameLayout高度修改为100dp后，外层触发重新测量，向内层ConstraintLayout传递新的AT_MOST 100dp高度Spec。但ConstraintLayout做缓存命中判断时，仅校验了宽度方向的Spec值、子View测量状态、约束关系这几个维度的key，未将父布局传入的最大可用高度值纳入缓存比对范围。
3. 因判定缓存key和上一次测量完全匹配，ConstraintLayout直接复用上一次被50dp高度截断的测量结果，不会重新触发内部子View的测量流程，也就不会根据新的可用高度重新计算自身wrap_content的适配尺寸。

测试现象的逻辑匹配 #

你观察到的两个正常场景，完全符合上述原因推导：

• 将内层替换为普通FrameLayout时，由于不存在这类跨流程测量缓存，每次都会基于最新的父布局尺寸重新计算，因此高度可以正常适配内容。
• 直接对内层ConstraintLayout调用requestLayout()时，该方法会强制将ConstraintLayout的本地测量缓存标记为无效，触发完整的重新测量流程。拿到新的100dp高度约束后，ConstraintLayout会正确计算出适配内容的真实高度，布局表现符合预期。

内容的提问来源于stack exchange，提问作者Mikhail