获课：jzit.top/22562/

《拒绝踩坑：Jetpack Compose初学者到高手的避坑指南——理解重组，才能驾驭声明式UI》

初学Jetpack Compose，你可能会遇到这样的困惑：明明数据没变，界面却反复刷新；滚动列表时莫名卡顿；在可组合函数里写了几行网络请求，结果App崩溃了。这些问题的根源，往往不是代码写错了，而是没理解Compose的“重组（Recomposition）机制”。

从新手到高手的分水岭，不在于背了多少API，而在于能否从“命令式”思维切换到“声明式”思维。以下是从官方文档和开发者社区中提炼的核心避坑原则，帮你避开那些最常见的陷阱。

避坑一：把Composable函数当onCreate()用

这是最容易被误解的一点。很多开发者会把网络请求、数据库写入直接写在Composable函数体里。然而，重组意味着函数体会被反复执行，动画的每一帧、状态的每次更新都可能触发重组。如果在函数体里直接做“副作用”操作（比如发请求、写数据库），这些操作就会被重复执行无数次。

正确做法是使用副作用API：一次性请求用LaunchedEffect，注册监听用DisposableEffect，同步状态用SideEffect。记住一条原则：Composable不是onCreate()，函数体只负责描述UI，不该做“事”。

避坑二：频繁执行高开销计算

Composable函数可以非常频繁地运行——动画的每一帧都可能触发重组。如果你在函数体里直接对列表做排序、做复杂的字符串处理，每次重组都会重复计算一遍，即使输入数据完全没变。

解决方案是使用remember缓存计算结果。例如，对一个联系人列表按名字排序，应该这样写：

val sortedList = remember(contacts) { contacts.sortedBy { it.name } }

这样，只有当contacts发生变化时才会重新排序，否则Compose直接复用缓存结果。它类似于前端世界里React的useMemo——缓存的是计算结果，而不是UI节点。

避坑三：LazyColumn/LazyRow忘记加key

在Compose的懒加载列表（LazyColumn）中，如果你只传递数据列表而不指定key，Compose会认为每次数据变化都是“整表刷新”，类似RecyclerView的notifyDataSetChanged()，即使你只修改了一项，整个列表都会被重组。

更严重的是，如果列表项内部有展开状态、输入框或动画，数据项移动位置后状态可能会“错位”到别的Item上。

解决办法很简单：为每个Item提供一个稳定的键。

LazyColumn {
    items(items = contacts, key = { it.id }) { contact ->
        ContactRow(contact)
    }}

有了key，Compose就能精确识别哪些项新增、哪些删除、哪些只是移动了位置，从而只重组真正变化的那一项，大幅提升列表滚动性能。

避坑四：状态“读得太早”导致大面积重组

这是新手最容易踩的性能陷阱。假设你在父级Composable里读取了滚动状态scroll.value，然后传给子组件使用。问题在于：scroll.value的读取发生在父级作用域，每次滚动值变化，Compose会让父级及其所有子组件都进入重组范围，即使只有最底层的Title组件真正需要这个值。

解决思路是“延迟读取”——把状态读取下放到真正需要它的地方，或者用lambda包装：

// 用lambda传递，而不是直接传值Title(offsetProvider = { scroll.value })

更进一步，对于频繁变化的偏移值，应使用Modifier.offset { ... }的lambda版本，而不是非lambda版本。官方注释明确说明：lambda版本的offset在偏移量变化时不会触发重组，只会重新布局和绘制，性能远优于前者。

避坑五：传递不稳定的参数类型

Compose在重组时会检查每个Composable函数的参数是否发生了变化，如果没变就跳过重组。但这个“跳过”有个前提：参数类型必须是“稳定”的（Stable）。

如果一个类使用了var属性（可变），或者内部包含不稳定的类型，Compose就认为它是“不稳定的”。每次父级重组时，即使这个对象的属性没变，Compose也会强制重绘它，造成性能浪费。

解决办法：优先使用data class并将属性声明为val（不可变），让Compose能确定它“不会变”，从而放心跳过重组。

避坑六：预览代码“随意写”

很多开发者在写@Preview时觉得“反正是预览而已”，于是忽略编码规范，甚至在里面做副作用操作。这不仅是坏习惯，还会导致实际运行时的预览结果与真实UI不一致。

把预览代码当成正式代码来写，遵守同样的规范。这能帮你养成好习惯，也确保预览真正反映运行时的表现。

小结：高手的思维方式

从新手到高手的转变，核心是理解重组在什么时候发生、影响范围有多大。记住这几条原则：

• 高开销计算用remember缓存；

• 懒加载列表必须加key；

• 状态读取尽量下移或延迟；

• 参数类型优先用不可变；

• 副作用别写在函数体里；

• 用Android Studio的布局检查器来“可视化”重组范围，这是调试性能问题最直观的工具。

掌握这些，你就不会在Compose的坑里反复横跳了。