Jetpack Compose 从重组到副作用的全方位解析

欢迎来到 Jetpack Compose 的世界！

Part 1. 重组的智慧：Compose 如何高效更新 UI

Compose 的高性能来源于其智能的重组（Recomposition）系统。它不会在每次数据变化时都重绘整个屏幕，而是只更新必要的部分。但这需要我们给它一些 "提示"。

1.1 组件的 "身份证"：调用点、位置与 key

Compose 如何识别界面上的每一个组件？

调用点 (Call Site)：默认情况下，Compose 通过你在代码中调用可组合函数的位置来唯一标识一个组件。
位置记忆 (Positional Memoization)：在循环中，Compose 会额外使用顺序（索引）来区分它们。

这在简单情况下工作得很好，比如在列表末尾添加元素。旧元素的索引和调用点都没变，Compose 就会跳过对它们的重组。

但陷阱在于：如果你在列表顶部或中间插入或删除元素，所有后续元素的位置都会改变。Compose 会认为它们的输入参数变了，从而导致整个列表不必要地重组，这不仅性能低下，还会导致状态错乱和副作用异常。

解决方案 ：使用 key 为动态列表中的每一项提供一个稳定且唯一的 "身份证"。

kotlin 复制代码

// 为列表中的每一项提供一个源自数据的、稳定的 key

LazyColumn {

  items(movies, key = { movie -> movie.id }) { movie ->

       MovieOverview(movie)

   }

}

原则：在任何通过循环动态生成 UI 的场景下，务必使用 key，并为其提供一个源自数据本身的、独一无二的稳定标识。

1.2 智能重组的秘密：可跳过性与稳定性

Compose 能够跳过重组的前提是：一个可组合函数的所有输入参数都是 "稳定" (Stable) 的。

什么是稳定类型？

一个类型向 Compose 编译器做出的 "承诺"，保证：

它的 equals 结果总是一致的。
如果它的公开属性发生变化，Compose 会得到通知。
它的所有公开属性也都是稳定类型。

不可变性 (Immutability) 是实现稳定的最佳方式。因此，所有基本类型、String、以及只包含稳定类型成员的 data class 默认都是稳定的。

问题：Compose 无法自动推断某些类型（如接口）的稳定性，会保守地将它们视为不稳定的。这会导致使用这些类型作为参数的组件永远无法被跳过。

解决方案 ：使用 @Stable 或 @Immutable 注解，手动向编译器做出 "承诺"。

kotlin 复制代码

// 告诉 Compose，这个接口的所有实现都将是稳定的

@Stable

interface UiState<T> {


}

原则：如果你的数据类型是稳定的，但 Compose 无法自动推断，请使用 @Stable 或 @Immutable 注解来帮助编译器进行优化。

Part 2. 副作用的艺术：驾驭 Compose 的生命周期

副作用（Side Effect）是指任何会 "逃逸" 出可组合函数作用域的操作，比如网络请求、数据库读写、或者与外部对象交互。在 Compose 中处理副作用需要使用特定的工具，以确保它们在正确的时机执行且不会造成内存泄漏。

2.1 最常用的武器：LaunchedEffect

LaunchedEffect 将一个协程的生命周期与一个可组合项的生命周期绑定在一起。

启动：当组件首次进入组合时启动。
取消：当组件退出组合时自动取消。
重启：当它的 key 参数发生变化时，会取消旧协程并重启一个新协程。

scss 复制代码

// 当 userId 发生变化时，这个效应会取消旧的加载，并用新的 userId 重新加载

LaunchedEffect(userId) {

  val userData = viewModel.loadUser(userId)

}

2.2 响应用户事件：rememberCoroutineScope

LaunchedEffect 只能在可组合函数中调用。如果你想在用户点击按钮这类事件回调中启动协程，就需要 rememberCoroutineScope。

它会返回一个与组件生命周期绑定的协程作用域 (CoroutineScope)。当组件销毁时，这个作用域以及由它启动的所有协程都会被取消。

ini 复制代码

val scope = rememberCoroutineScope()

Button(onClick = {

      // 在事件回调中，命令式地启动协程

       scope.launch {

           performAction()

       }

}) {

}

2.3 效应的 "神队友"：rememberUpdatedState

问题：如果我有一个长耗时、不希望重启的效应 (LaunchedEffect(true)), 但它内部又需要引用一个可能会变化的外部变量或回调，怎么办？

直接引用会导致效应捕获的是旧的、过时的值。

解决方案 ：使用 rememberUpdatedState。它会创建一个始终指向最新值的引用，而这个引用本身是稳定的。

kotlin 复制代码

@Composable

fun LandingScreen(onTimeout: () -> Unit) {

       // onTimeout 可能会变，但我们不希望效应因此重启

       val currentOnTimeout by rememberUpdatedState(onTimeout)

       // 这个效应只在启动时运行一次

       LaunchedEffect(true) {

           delay(3000L)

           // 调用时，它总能拿到最新的 onTimeout 函数

           currentOnTimeout()

       }

}

2.4 重启效应的黄金法则

如何为效应选择正确的 key？

黄金法则 ：应将效应中使用的变量添加为效应的参数 (key)，或使用 rememberUpdatedState 包装。

决策流程如下：

问：如果这个变量变了，效应的逻辑是否必须从头再来？

是 -> 把它放进 key 列表。

否 -> 不要把它放进 key 列表。
问：对于那些不放入 key 的变量，我是否需要在效应内部读取它的最新值？

是 -> 使用 rememberUpdatedState 包装它。

Part 3. 沟通的桥梁：连接 Compose 内外世界

Compose 也提供了强大的 API 来与非 Compose 的世界进行交互。

3.1 向外广播：SideEffect 和 snapshotFlow

SideEffect：用于将 Compose 状态同步到非 Compose 代码。它会在每次成功的重组之后执行。非常适合用于更新分析库、日志记录等。

arduino 复制代码

SideEffect {
       // 每次 user 变化，重组成功后，这里都会执行
       analytics.setUserProperty("userType", user.userType)
}

snapshotFlow ：将一个或多个 Compose State 对象转换成一个 Kotlin Flow。这使你可以利用 Flow 强大丰富的操作符（如 debounce, filter, map）来处理复杂的状态变化逻辑。

markdown 复制代码

LaunchedEffect(listState) {

       snapshotFlow { listState.firstVisibleItemIndex }

           .map { index -> index > 0 }

           .distinctUntilChanged()

           .filter { it }

           .collect {

               // 当用户首次滚过列表顶部时，执行一次

               analytics.sendScrolledPastFirstItemEvent()

           }

}

3.2 向内生产：produceState

produceState 的作用正好相反，它将外部的、非 Compose 的数据源（特别是异步的，如 Flow, LiveData, 网络回调）转换成 Compose UI 可以直接订阅的 State。

csharp 复制代码

// 将一个异步加载操作转换为 State

val imageState by produceState<Result<Image>>(initialValue = Result.Loading, url) {

       // 在后台协程中加载数据

       val image = imageRepository.load(url)

       // "生产"出最终结果

       value = if (image != null) Result.Success(image) else Result.Error

}

3.3 高级性能优化：derivedStateOf

当你某个状态变化非常频繁，但你只关心由它计算出的某个结果是否变化时，用 derivedStateOf 可以避免不必要的重组。

黄金法则 ：当你的计算结果的变化频率，远低于你所依赖的状态的变化频率时，才应该使用 derivedStateOf。

kotlin 复制代码

val listState = rememberLazyListState()

// listState.firstVisibleItemIndex 在滚动时频繁变化

// 但 showButton (true/false) 的变化频率很低

val showButton by remember {

   derivedStateOf {

       listState.firstVisibleItemIndex > 0

   }

}

错误用法 ：不要用它来简单地组合多个更新频率一致的状态，比如 fullName = "$firstName $lastName"。这只会增加不必要的开销。

结论

掌握 Jetpack Compose 的核心不仅仅是学习 API，更是理解其背后的声明式思维。通过深入理解重组的机制、善用稳定性和 key，并为不同的场景选择最合适的副作用处理工具，你就能构建出真正流畅、健壮且易于维护的现代化 Android 应用。