在传统的 Android View 体系中，“嵌套层级过深导致卡顿” 几乎是每个开发者都踩过的坑。当屏幕刷新率迈向 120Hz 甚至更高时，留给每一帧的渲染时间只有极度苛刻的 8.3 毫秒。
Jetpack Compose 敢于彻底抛弃 XML，并喊出 “拒绝性能劣化” 的口号，其核心底气就来自于它的扁平化渲染架构与单次测量铁律 (Single Pass Measurement) 。
本文将为你深度拆解 Compose 是如何在底层打破传统嵌套魔咒，稳稳控住120FPS的。
1、传统View 体系的 “ 痛 ” vs Compose 的 “ 飒 ”
要理解 Compose 的扁平化，先要看看传统 View 为什么会慢。
1.1 传统 View 的性能陷阱： 的多重测量
在传统 View 中，像 RelativeLayout 或设置了 weight 的 LinearLayout，为了确定子 View 的最终大小，往往需要对子 View 进行 两次或多次测量。
如果这种布局发生了嵌套，测量次数就会呈指数级增长 () 。在 120Hz 的高刷屏幕下，这种指数级的耗时扩散是致命的。
1.2 Compose 的解法： LayoutNode 树与单次测量
Compose 在底层摒弃了笨重的 android.view.View 对象，整个 Compose 视图树在底层最终会映射为极其轻量化的LayoutNode树。
更重要的是Compose树在标准布局流程中，严格遵守“单次测量铁律”：任何一个父节点，对每一个子节点的 measure方法只能调用一次。这直接将布局的时间复杂度从指数级降到了线性级 。
2、 扁平化渲染的三大核心底层机制
Compose 实现 120 FPS 的扁平化渲染，主要依赖以下三个底层杀手锏：
Mechanism 1: 节点级扁平化 —— Modifier 的 “ 折叠 ” 艺术
在传统布局中，如果你想给一个 TextView 加个背景、加个边距，你可能需要在外层套一个 FrameLayout。但在 Compose 中，你只需要写一串 Modifier：
Text(
text = "Hello",
modifier = Modifier.padding(16.dp).background(Color.Red)
)
底层原理：
这些 Modifier 并不会在 LayoutNode 树中创建新的“层级节点”。Compose 在编译与运行时，会把这一串 Modifier 折叠（ Fold ） 到同一个 LayoutNode 内部。对于布局引擎来说，它仍然只有一个节点，这就从结构上实现了彻底的扁平化。
Mechanism 2: 运行时核心 —— 三阶段流水线分离****
Compose 把一帧的渲染划分为了三个完全解耦的阶段：
- Composition （重组） ：确定“要显示什么”，构建或更新 LayoutNode 树。
- Layout （布局） ：确定“放在哪里”及“多大”。包含 Measure （测量） 和 Place （放置） 。
- Draw （绘制） ：将内容绘制到屏幕上。
120 FPS 的关键点在于：状态读取的隔离。
Compose 采用了高度智能的“快照系统（Snapshot）”。如果一个频繁改变的状态（比如倒计时、动画进度）只在 Draw 阶段 被读取，那么 Compose 会直接跳过重组和布局阶段，仅仅触发目标节点的局部重绘。这免去了整棵树的重新遍历，保障了极致的流畅度。
Mechanism 3: 规避死局的固有特性测量 (Intrinsic Measurements)
“只能测量一次”听起来很美，但如果父布局确实需要知道子布局“最大能长多大”才能决定自己的大小怎么办？传统 View 靠多次测量，Compose 则靠固有特性测量 (Intrinsic Measurements) 。
在正式测量之前，父布局可以向子布局查询一个预测值（如：最小/最大宽度）。这个查询是推导式的，不会触发真正的 Layout 流程。通过这种方式，Compose 在保持单次测量的铁律下，依然拥有强大的自适应布局能力。
3、代码实战：自定义Layout 见证单次测量铁律
光说不练假把式。我们通过一个自定义的瀑布流/简易列布局（CustomColumn），来看看 Compose 底层是如何在代码层面强制执行“单次测量”并进行扁平化绘制的。
示例代码*
import androidx.compose.runtime.Composable
import androidx.compose.ui.Modifier
import androidx.compose.ui.layout.Layout
import androidx.compose.ui.layout.Placeable
import androidx.compose.ui.unit.Constraints
@Composable
fun CustomFlatColumn(
modifier = Modifier,
content: @Composable () -> Unit
) {
// Layout 是 Compose 实现扁平化布局的核心元操作符
Layout(
content = content,
modifier = modifier
) { measurables, constraints ->
// 【1. 严格的单次测量阶段】
// measurables 是子节点的测量句柄。注意：这里的 child.measure 针对每个子项只能调用一次！
// 如果你尝试调用两次，Compose 底层会直接抛出 IllegalStateException
val placeables = measurables.map { measurable ->
// 每个子项根据父布局的约束(constraints)进行自我测量
measurable.measure(constraints)
}
// 计算父布局自身应该有多大
var layoutWidth = 0
var layoutHeight = 0
placeables.forEach { placeable ->
layoutWidth = maxOf(layoutWidth, placeable.width)
layoutHeight += placeable.height
}
// 【2. 放置阶段】
// 告诉布局系统父布局的宽高，并在这个作用域内安排子项的位置
layout(layoutWidth, layoutHeight) {
var yPosition = 0
placeables.forEach { placeable ->
// 将子项放置在指定的坐标上
placeable.placeRelative(x = 0, y = yPosition)
// 累加高，为下一个子项腾出空间
yPosition += placeable.height
}
}
}
}
源码级原理解析
在上面的自定义布局中，有两个关键的角色体现了底层的扁平化设计：
- Measurable （可测量物） ：它代表一棵树里的子节点。在传统 View 中，你拿到的是一个具体的 View 对象，你可以随时随地调用 view.measure()。但在 Compose 中，底层只给你包装过的 Measurable。
- Placeable （可放置物） ：一旦你调用了 measurable.measure(constraints)，你就会得到一个 Placeable 对象。一旦变成Placeable ，该子节点在此次布局帧中就再也无法被重新测量了。 你唯一能做的，就是在 layout() 阶段调用 placeRelative() 去指定它的坐标。
这种从 API 设计上进行的强约束，直接把开发者写出“多次测量导致卡顿”代码的可能性扼杀在了摇篮里。
4、 总结： Compose 控住 120 FPS 的铁律闭环
Jetpack Compose 能够让 UI 渲染稳稳咬住 120 FPS 这一铁律，并非靠单纯的硬件加速，而是靠一套精密的软件架构闭环：
- 结构扁平：用轻量级 LayoutNode 代替 View，用 Modifier 折叠代替布局嵌套。
- 算法扁平：严守单次测量铁律，时间复杂度永远锁死在 。
- 精确打击：重组、布局、绘制三阶段分离，配合快照系统，让状态变化引起的刷新永远只发生在最小的闭环内。
对于开发者而言，我们不再需要为了性能去小心翼翼地优化 XML 层级，Compose 已经在底层为你铺平了通往高刷时代的道路。
