老实说，

前几天我的好同事彭于晏读完我前面几篇关于 Compose 的文章后准备在组内好好推广一下做一次分享。

他问了我一个很真实的问题：有没有什么技巧。讲出来能让大家觉得“这个人确实懂 Compose，而且还挺厉害”？

我想了想，答案还真有。

不是背 API，也不是堆概念。而是能说清楚：Compose 为什么会重组，状态在哪里被读取，还有如何控制它的影响范围。

好，正文开始！

Jetpack Compose 遵循"状态变更 → 重组 → UI 更新"的声明式范式。其实，

如果状态处理不当会引发不必要的重组。直接拖累页面性能，

这篇文章另一个值，中间不需要额外的处理过程或管线。用 derivedStateOf；

避开组合阶段

Text .offset // 组合阶段读取状态 .scale,// 组合阶段读取状态 text = "Animate" ) 

使用状态配合 Modifier 动态改变位置、大小、透明度是常见做法。

但如果在组合阶段直接读取变化很快的状态。每次状态更新都会迫使 Compose 重新执行整个 Composable 函数，引发高频重组。

Text.toInt) } // 布局阶段读取 .drawWithContent { // 绘制阶段读取 scale { } },text = "Animate" ) // 或者更推荐的图形变换方式： Text.toInt) } // 布局阶段读取 .graphicsLayer { // 绘制阶段读取 scaleX = animatedValue scaleY = animatedValue }。text = "Animate" ) 

这里的主要思路是 阶段降级 将状态的读取从“组合阶段”推迟到后续的渲染阶段。怎么说呢，

• 布局阶段 读取：使用 Lambda 形式的 Modifier
• 绘制阶段 读取：使用 drawWithContent 或 graphicsLayer { }

为什么阶段降级能提高性能？

Compose 的渲染流水线分为三个严格的先后阶段： 组合→ 布局→ 绘制 。

• 组合阶段 负责根据状态建立 UI 树。如果在这里读取状态，状态变化必定导致 UI 树重建。
• 布局阶段 仅安排组件位置，绘制阶段 仅负责将像素渲染到屏幕。

当我们在 offset { } 或 graphicsLayer { } 的 Lambda 内部读取状态时Compose 会智能地跳过组合阶段。状 态变化时只会触发对应组件的重新布局或重新绘制，从而彻底省去了最耗时的重组开销。

此法在此文中亦有提及。

缩小重组作用域

如果说上一个技巧是解决“在什么时间点读取”的问题，那么这个技巧则是解决“在 UI 树的什么位置读取”的问题。

⚠️ 欠佳示例

@Composable
private fun Parent {
var count by remember {
mutableIntStateOf
}
// 父组件直接读取了 count 状态
// count
变化时
Parent
会发生完整重组。连带其内部的其他子组件也可能受影响
ChildA(count
= count)
OrStaticChild
}
@Composable
private fun ChildA {
Text
}

在 Compose 中，重组的最小单位是 Composable 函数。Compose 会精准追踪每个状态被哪些 Composable 读取了。

在上述代码中，由于 count < / code> 是在 Parent < / code> 的作用域内被读取（作为参数传递给 ChildA < / code> ）。一旦 count < / code> 发生变化， Parent < / code> 就会被标记为需要重组。这会导致 Parent < / code> 内部的 OrStaticChild < / code> 等无关组件也面临被重新评估的风险。老实说，