008 副作用、重组优化与调试：我的实战心得

在Compose的世界里摸爬滚打一阵子后，我深刻体会到，写出能跑的UI和写出高性能的UI完全是两码事。今天，我想和你分享我在处理副作用、优化重组以及调试时积累的一些实战经验和“避坑”指南。这些内容可能不会让你的UI立刻变得炫酷，但绝对能让你的应用运行得更丝滑、更健壮。

1. 副作用 API：我的工具箱

我们都知道，一个理想的Composable函数应该是“幂等”的——给它同样的输入，它就返回同样的UI描述。但现实是，我们总有些“副作用”需要处理，比如发起网络请求、显示一次性的提示、监听生命周期等。这时候，就不能蛮干，得用对工具。下面这个表格是我常用的“副作用工具箱”速查：

以 LaunchedEffect 为例：按需加载用户数据

让我举个最常用的例子。假设我们有一个用户详情页，需要根据传入的userId去加载数据。如果直接在Composable里调用viewModel.loadUser，那每次重组都可能触发请求，这显然不对。

我的做法是使用LaunchedEffect，并把userId作为key：

@Composable
fun UserDetail(userId: String, vm: UserViewModel = viewModel()) {
    // 关键在这里：userId变化时，取消旧协程，启动新协程
    LaunchedEffect(userId) {
        vm.loadUser(userId)
    }
    val state by vm.uiState.collectAsState()
    // ... 根据state渲染UI
}

这里有个千万要注意的坑：LaunchedEffect的key参数不能省。如果省略了，这个效果只会在初始组合时运行一次，userId变了也不会刷新。如果key给错了（比如给了个永远不会变的值），同样会导致数据不更新。我早期就犯过这种错误，调试了半天才发现是key没设置对。

2. derivedStateOf：让派生状态更智能

有时候，我们的UI状态是由其他几个状态“计算”出来的。比如，我想根据列表的滚动位置来决定是否显示一个“回到顶部”的浮动按钮。最直接的想法可能是：

val showFab = listState.firstVisibleItemIndex == 0

但这样写，listState的任何微小变化（比如滚动一点点）都会导致showFab被重新计算，并可能触发其所在Composable的重组。如果这个Composable包含大量子项，性能开销就大了。

这时，derivedStateOf就是我的救星。它只在计算结果真正发生变化时，才通知Compose进行重组：

val listState = rememberLazyListState()
val showFab by remember {
    derivedStateOf {
        // 只有 firstVisibleItemIndex 从0变为非0，或从非0变为0时，才会触发重组
        listState.firstVisibleItemIndex == 0
    }
}

这种感觉就像给计算逻辑加了一个智能的缓存，避免了大量不必要的重组计算。

3. 稳定性（Stability）：重组优化的幕后英雄

Compose编译器在背后会分析我们的代码，推断每个类型的“稳定性”。一个稳定的类型（参数）意味着Compose可以更自信地判断其内容是否变化，从而在父组件重组时，决定是否跳过该子组件的重组。这是Compose高性能的基石之一。

根据我的经验，要利用好这个特性，可以遵循以下原则：

• 尽量这样做：为列表的每一项使用data class，并且保持其字段是不可变的（val）。如果需要唯一标识，使用稳定的key属性。
• 尽量避免：向Composable传递不稳定的参数，比如一个没有用remember包裹的、每次重组都会新建的lambda表达式。这会让Compose的跳过优化失效。
  • 解决方案：对于回调函数，我常用remember(updatedState) { { ... } }来稳定它的引用，同时又能捕获最新的状态。

想深入了解编译器到底是怎么判断的，可以查阅官方的 Stability 说明文档。理解这些规则，能帮助我们写出对编译器更友好的代码。

4. 调试重组：让问题无处遁形

当UI表现不如预期，怀疑是重组问题时，我手头有几个好用的调试方法：

• Android Studio 内置工具：
  • Layout Inspector：对Compose有专门的支持，可以查看重组边界。
  • Recomposition Counts：这个功能太有用了！它可以直接在预览或运行的设备上，用数字显示每个Composable的重组次数。虽然它在不同AS版本中的菜单位置可能不一样，但找到它绝对是值得的。
• 开发时的小技巧：
  • 在怀疑的组件上临时加一个Modifier.border(width = 2.dp, Color.Red)，重组时边框会闪动，非常直观。
  • 或者，写一个简单的调试Composable，用SideEffect来打印日志：

@Composable
fun DebugRecompose(text: String) {
    SideEffect {
        Log.d("Compose_Debug", "重组发生了！内容: $text")
    }
    Text(text = text)
}

注意：这些调试手段仅限开发阶段，千万别带到生产代码里。

5. 组合阶段：只做描述，不做重活

这是我学Compose时最重要的一课：在@Composable函数里，只应该描述UI，不应该执行繁重的工作。

• 网络请求、数据库读写：这些统统应该放在ViewModel里，用协程处理。Composable只负责通过collectAsState()来观察和响应状态。
• 处理大型列表：一定要用LazyColumn或LazyRow。并且，为每个item设置一个稳定的key，在必要时使用itemContentType，这能极大提升列表滚动的性能。

记住，Compose的组合阶段（Composition）应该尽可能快、尽可能纯净。

6. 下一步学什么？我的进阶路线图

掌握了这些基础和优化知识后，Compose还有更多令人兴奋的部分等着我们去探索。我的个人学习路线建议如下：

• 动画：从简单的animate*AsState开始，到复杂的Transition动画和AnimatedVisibility。
• 手势：深入学习pointerInput，实现自定义的draggable、swipeable交互。
• 自定义布局：当内置布局不够用时，使用Layout Modifier或SubcomposeLayout来创造独一无二的布局效果。
• 测试：学习使用compose-ui-test框架和createComposeRule，为你的Composable UI编写可靠的测试。

7. 迁移或开启新项目前的自检清单

在开始一个新功能模块，或者将旧项目迁移到Compose之前，我都会对照下面这个清单检查一下，这能帮我避开很多常见的陷阱：

• [ ] 新的屏幕是否统一采用了 StateFlow + viewModel() 的模式来管理状态？
• [ ] 所有列表（LazyColumn）的项是否都设置了稳定且唯一的 key？
• [ ] 每个 LaunchedEffect 的 key 设置是否正确，是否覆盖了所有应该触发副作用的状态变化？
• [ ] 如果是混合使用 View 和 Compose 的页面，是否设置了合适的 ViewCompositionStrategy（如DisposeOnViewTreeLifecycleDestroyed）来管理生命周期？

好了，关于副作用和性能优化的核心经验就分享到这里。你可以回过头，再对照 000-Compose学习路径与分篇索引.md 看看，把这些点串联起来，形成自己的知识体系。Compose的学习是一个不断实践和优化的过程，希望我的这些经验能让你少走一些弯路。