性能优化实战：如何定位冗余重组并榨干 Compose 的每一帧性能？

前言

作为一名 Android 老兵，你可能还记得当年为了减少 View 绘制开销，拼命优化 onDraw、减少 invalidate 调用的日子。

到了 Compose 时代，虽然我们不再直接操作 Canvas，但性能挑战依然存在。最常见的问题就是：冗余重组（Redundant Recomposition）。如果不加克制，一个微小的动画可能导致整个复杂的 UI 树每秒重组 60 次，导致低端机发热、掉帧。

今天，我们就来学习如何像专业架构师一样，使用工具定位瓶颈，并利用 Compose 的特性榨干每一帧性能。

在优化之前，我们必须先看到问题。

Layout Inspector：Android Studio 提供的利器。在运行应用时打开它，开启 "Show Recomposition Counts"。
观察指标 ：
- Recomposition count：该组件重组了多少次。
- Skipped count：该组件成功跳过了多少次重组。
- 目标：如果一个静态列表在滚动时，不相关的 Item 也在重组，那就是优化的目标。

Compose 编译器非常聪明，如果它能确定一个对象的属性不会变（Immutable），或者变化是可追踪的（Stable），它就会在重组时跳过依赖该对象的 Composable。

如果你传了一个普通的 List 或者一个没有标记的 Data Class（特别是跨模块的类），Compose 编译器可能会认为它是 Unstable。

想象一个场景：你需要根据列表滚动的距离来控制顶部标题的透明度。

kotlin 复制代码

// ❌ 错误做法：listState 每一像素的变化都会触发整个 Header 重组
val alpha = listState.firstVisibleItemScrollOffset / 1000f
Header(alpha)

正确做法：

kotlin 复制代码

// ✅ 只有当 alpha 的计算结果发生显著变化时，才会触发重组
val alpha by remember {
    derivedStateOf { listState.firstVisibleItemScrollOffset / 1000f }
}
Header(alpha)

老兵 Tips ：只要是"多变状态"转换成"较少变化的状态"，请务必使用 derivedStateOf。

这是 Compose 性能优化中最隐蔽、最高级的技巧。

常规做法 ：Modifier.offset(x = offset.dp)。这里的 offset 是在重组阶段读取的，意味着 offset 变 1 像素，重组就发生 1 次。
黑科技做法 ：Modifier.graphicsLayer { translationX = offset }。
- 原理：状态读取被推迟到了绘制阶段（Draw Phase） 。由于跳过了测量和布局阶段，Compose 可以直接在 GPU 上移动这个图层，重组次数直接降为 0！

检查列表 Item 的 Key ：在 LazyColumn 中，务必提供唯一的 key。这能避免在数据增删时导致整个列表重新创建。
避免在 Composable 内部进行昂贵计算 ：任何复杂的逻辑都应该放进 remember(key) 或 ViewModel 中。
Release 模式才是真相：永远不要在 Debug 模式下评估 Compose 性能。Debug 模式包含了大量的辅助检查逻辑，性能远低于 Release。
按需使用 R8/Proguard：Compose 编译器插件生成的代码非常多，混淆优化能显著提升运行效率。

Compose 的性能优化不是靠"玄学"，而是靠对稳定性 、状态读取时机 以及工具链的深度理解。当你掌握了这些，你会发现 Compose 不仅开发快，跑起来也一样如丝般顺滑。

如果你觉得有帮助，欢迎点赞关注，我们在代码上演进，在原理上深耕。