Compose中的副作用

什么是副作用

从本质上讲，副作用是任何超出函数控制和作用域的东西。副作用会使函数变得不确定，因此它们使开发人员难以推理代码。

想象有一个函数，它被期望对两个数相加：

对于相同的输入值，其结果永远不会变化，也就是说，不会因为运行次数的增加导致输出结果的不同，因为该函数所做的唯一一件事就是将它们相加。因此，我们可以说这个函数是确定的，我们可以很容易地对它进行推理。这样的函数也经常被称为 “纯函数”，因为它只使用它的输入来计算结果。

现在，让我们考虑添加一些附带行为:

我们引入了一个计算缓存来节省计算时间，如果之前已经计算过结果的话，将会直接返回缓存的结果。但是这个缓存逃脱了函数的控制，因此没有任何东西告诉我们从它读取的值是否自上次执行以来没有被修改过。想象一下，这个缓存正在从一个不同的线程并发更新，突然发现两次连续的调用get(a, b) 方法，对相同的输入却返回了两个不同的值：

add 函数对于相同的输入返回不同的值，因此它不再是确定性的。同样，假设这个缓存不在内存中，而是依赖于一个数据库。我们可以获得由 get 和 store 调用引发的异常，这取决于当前缺少到数据库的连接等情况。我们对 add 的调用也可能在意想不到的情况下失败。

概括一下，我们可以说副作用是发生在一侧的意想不到的动作，超出了调用者对函数的期望，并且可以改变它的行为。副作用使开发人员难以推理代码，也消除了可测试性，为不稳定打开了大门。

这对于React、Compose这类的声明式UI框架至关重要，因为它们都是通过函数（组件）的反复执行来渲染UI的，函数执行的时机和次数都不可控，但是函数的执行结果必须可控，因此，我们要求这些函数组件必须用没有副作用的纯函数实现。

虽然副作用是不应该出现的，但是有时副作用是合理的，且必要的，例如，内存缓存、数据库、执行网络请求、文件读取、日志处理、弹出toast提醒、页面跳转等等。这些操作必须在能感知Composable生命周期的受控环境中执行，否则有可能打断 Compose 的施法。为此 Compose 提供了很多副作用API，使用这些API可以保证对应的操作在Composable的生命周期的特定阶段被执行，确保行为的可预期性。

Compose 中的副作用

我们了解了在 Composable 函数中执行副作用时如何陷入同样的问题，因为这有效地使副作用逃脱了 Composable 生命周期施加的控制和约束。

我们还知道，可组合函数的属性之一就是可重新启动的，任何 Composable 都可能遭受多次重组。因此，直接在 Composable 中运行副作用并不是一个好主意。

在 Composable 中运行副作用的风险太大了，因为它可能会破坏代码的完整性和应用程序状态。让我们看下面的一个例子：一个从网络加载其状态的可组合函数

这里的副作用将运行在每一个重组，这可能不是我们想要的。runtime 可能需要在很短的时间内多次重新组合这个 Composable。结果是将导致许多副作用同时发生，而它们之间没有任何协调。我们可能想要的是在第一次组合时只运行一次副作用，并在整个 Composable 生命周期中保持该状态。

现在，让我们想象我们的用例是 Android UI，所以我们使用 compose-ui 来构建一个可组合树。任何Android 应用程序都有副作用。下面是保持外部状态更新可能产生的副作用的示例。

这个组合描述了一个带有触摸处理支持的 drawer 的屏幕。drawer 状态初始化为 Closed，但随着时间的推移可能会更改为 Open。对于每个组合和重组，可组合对象通知 TouchHandler 关于当前 drawer 状态，只有当它是 Open时才启用触摸处理支持。

这一行 drawerTouchHandler.enabled = drawerState.isOpen 就是一个副作用。我们在组合函数内对一个外部对象赋值一个回调引用，这个操作将成为组合的副作用。

回到网络请求的例子，如果一个触发网络请求的组合在完成之前就离开了，会发生什么？那时候我们可能更倾向于取消任务，对吧？

因为编写有状态程序需要副作用，所以 Jetpack Compose 提供了以生命周期感知的方式运行副作用的机制，因此可以在多个重组之间跨任务，或者在可组合对象离开组合时自动取消任务。这些机制称为 副作用处理程序（Effect handlers）。

在其他 runtime 执行策略中，组合可以转发到不同的线程、并行执行或以不同的顺序执行。这是一扇通向各种潜在优化的大门。Compose 团队想要保持开放，这也是为什么我们不想在没有任何控制的情况下，在 Compose 过程中立即运行我们的副作用。

总的来说，我们需要一些机制来确保：

• 副作用运行在正确的可组合生命周期步骤。不早不晚。就在可组合的时候。
• 挂起的副作用运行在一个方便配置的 runtime (协程和CoroutineContext)。
• 捕获引用的副作用有机会在离开组合时销毁这些引用。
• 当离开组合时，正在进行的挂起的副作用将被取消。
• 依赖于随时间变化的输入的副作用会在每次变化时自动销毁/取消并重新启动。

这些机制由 Jetpack Compose 提供，称为 副作用处理程序（Effect handlers）。

Compose 中的副作用处理程序（Effect Handlers）

我们可以将副作用处理程序分为两类:

• 非挂起的副作用：例如当 Composable 进入组合时，运行一个副作用来初始化一个回调，当 Composable 离开组合，销毁这个回调。
• 挂起的副作用：例如从网络加载数据以提供一些UI状态。

在介绍它们之前，让我们先了解一下 @Composable 的生命周期，因为这一点跟副作用是紧密相关的。

Compose 的生命周期

任何 Composable 在屏幕上具体化时进入组合，最后从 UI 树中移除时离开组合。在这两个事件之间，副作用都可能会运行。有些副作用可以比可组合的生命周期更持久，因此你可以跨组合扩展一个副作用。

每个Composable函数最终会对应LayoutNode节点树中的一个LayoutNode节点，可简单的为其定义生命周期：

• onActive: 进入重组作用域， Composable对应的LayoutNode节点被挂接到节点树上
• onUpdate：触发重组， Composable对应的LayoutNode节点被更新（0次或者多次）
• onDispose: 离开重组作用域， Composable对应的LayoutNode节点从节点树上移除

非挂起的副作用

DisposableEffect

它表示组合生命周期的副作用。DisposableEffect可以感知Composable的onActive和onDispose，允许通过副作用完成一些预处理和收尾工作。

• 用于需要释放、销毁的非挂起的副作用。
• 第一次（当 Composable 进入组合时）以及每次它的key改变的时候运行。
• 在结束时需要调用一个 onDispose 回调。它在可组合对象离开组合时被释放，在其key发生变化时也会在每次重组时被释放。在这种情况下，副作用被销毁并重新启动。

例如监听处理系统返回键的例子：

@Composable
fun BackPressHandler(enabled: Boolean = true, onBackPressed: () -> Unit) {
    val backDispatcher = LocalOnBackPressedDispatcherOwner.current?.onBackPressedDispatcher
    val currentOnBack by rememberUpdatedState(onBackPressed)

    val backCallback = remember {
        object : OnBackPressedCallback(enabled) {
            override fun handleOnBackPressed() {
                currentOnBack()
            }
        }
    }

    // backDispatcher 发生变化时重新执行
    DisposableEffect(backDispatcher) {
        backDispatcher?.addCallback(backCallback) // onActive时添加回调
        // 当 Composable 进入 onDispose 时执行
        onDispose {
            backCallback.remove() // onDispose时移除回调 避免内存泄漏
        }
    }
}

Compose 中自带的BackHandler组件内部就是基于DisposableEffect实现 的。

它将一个回调添加到一个从 CompositonLocal 获得的Dispatcher调度程序。我们希望在可组合对象进入组合时以及当Dispatcher发生变化时添加回调。要实现这一点，我们可以将 dispatcher 作为副作用处理程序 key 传递。这将确保在这种情况下副作用被销毁并重新启动。

当可组合对象最终离开组合时，回调也会被释放。

DisposableEffect的lambda中必须跟随一个onDispose{...}代码块的调用，否则会编译报错。onDispose一般常用于反注册接口回调，及一些资源清理工作，防止内存泄漏。当有新的副作用来临时，前一次的副作用就会执行onDispose{...}代码块中的代码。

DisposableEffect可以接受一个key作为参数，如果key是可变状态，当key发生变化时，会重新执行副作用中的代码块。

如果你想要副作用在进入组合时只运行一次，并在离开时释放它，你可以传递一个Unit或true这样的常量作为key ：DisposableEffect(true) 或 DisposableEffect(Unit) ，则副作用代码块只在onActive时执行一次。

注意，DisposableEffect总是至少需要一个 key。

DisposableEffect 非常适合用于 Composable 在离开组合树时执行一些清理工作。

SideEffect

这个副作用有点特殊，因为它的含义类似于 “在组合中触发或者忽略它”。SideEffect仅会在每次重组成功时执行，如果由于任何原因导致组合失败，它将被丢弃。因此它能正确的向外传递状态。 其中不能用来处理耗时和异步任务。（注意Composable函数不一定每次都会执行重组也不一定每次重组都会执行成功）

• 用于不需要释放/销毁的副作用。
• 在每一次组合/重组成功后运行。
• 用于向外部状态发布更新。

如果你对 Compose runtime 的内部机制有一定的了解，注意 SideEffect 是一个没有存储在 slot table 中的副作用，这意味着它不会在 Composition 中存活下来，也不会在未来的 Composition 中重新尝试运行等等。

@Composable
fun MyScreen(drawerTouchHandler: TouchHandler) {
    val drawerState = rememberDrawerState(DrawerValue.Closed)

    SideEffect { // 将 drawerState 通知外部
        drawerTouchHandler.enabled = drawerState.isOpen
    }
}

这里我们关心 drawer 的当前状态，因为它可能随时变化。因此，我们需要在每个组合或重新组合中通知它。此外，如果 TouchHandler 是一个单例，在整个应用程序执行期间始终存在，因为这是我们的主屏幕（始终可见），我们可能根本不想释放引用。

我们可以将 SideEffect 理解为这样一个副作用处理程序：它旨在将更新发布到某些不受组合状态系统管理的外部状态，以保持其始终同步。

@Composable
fun rememberAnalytics(user: User): FirebaseAnalytics {
    val analytics: FirebaseAnalytics = remember {
        /* ... */
    }

    // On every successful composition, update FirebaseAnalytics with
    // the userType from the current User, ensuring that future analytics
    // events have this metadata attached
    SideEffect {
        analytics.setUserProperty("userType", user.userType)
    }
    return analytics
}

currentRecomposeScope

它更像是一个副作用而不是一个副作用处理程序。作为Android开发者，你可能熟悉View 系统中的 invalidate 方法，它基本上强制执行新的测量、布局和绘制过程。例如，它被广泛用于使用 Canvas 创建基于帧的动画。因此，在每个绘制周期中，你会使View视图无效，从而根据需要重新绘图。

currentRecomposeScope 是一个在任何Composable函数中都能访问的成员，我们可以在androidx.compose.runtime.Composables.kt中找到它的定义：

/**
 * Returns an object which can be used to invalidate the current scope at this point in composition.
 * This object can be used to manually cause recompositions.
 */
val currentRecomposeScope: RecomposeScope
    @ReadOnlyComposable
    @OptIn(InternalComposeApi::class)
    @Composable get() {
        val scope = currentComposer.recomposeScope ?: error("no recompose scope found")
        currentComposer.recordUsed(scope)
        return scope
    }

其中RecomposeScope 是一个具有单一方法的接口：

interface RecomposeScope {
    /**
     * Invalidate the corresponding scope, requesting the composer recompose this scope. 
     * This method is thread safe.
     */
    fun invalidate()
}

因此，currentRecomposeScope 的作用与View#invalidate方法类似，通过调用 currentRecomposeScope.invalidate()，它将使当前时刻的本地组合无效，并强制触发重组。一般用于手动触发重组。

当使用非组合状态快照的数据源时，它可能很有用

这里我们有一个 Presenter ，当有结果时，我们手动使其失效以强制重组，因为我们没有以任何方式使用 State。当然这显然是一个非常剑走偏锋的示例，所以在大多数情况下你可能更喜欢利用 State 和智能重组。

所以总的来说，要谨慎使用！当状态可能变化时，使用State进行智能重组，这才是正常手段，因为这将确保最大限度地利用 Compose runtime。

挂起的副作用

LaunchedEffect

这是一种用于加载 Composable 初始状态的挂起变体，它会在 Composable 进入组合时立即运行。

• 当进入组合时运行副作用。
• 离开组合时取消副作用。
• 当key发生变化时取消并重新启动副作用。
• 对于跨组合扩展作业很有用。
• 当进入组合时，在Applier的调度器上运行副作用（通常是 AndroidUiDispatcher.Main）。

当副作用中需要处理异步任务的需求时，可以使用 LaunchedEffect， 在 Composable 进入组合 (onActive)时，LaunchedEffect 会启动协程执行 block 中的内容，一般用来启动子协程或者调用挂起函数。

当 Composable 离开组合 (onDispose)时，LaunchedEffect启动的协程会自动取消，因此 LaunchedEffect 不需要实现onDispose{...}

当 LaunchedEffect 设置的 key 发生变化时，当前协程自动结束，同时开启新的协程。

@Composable
fun MyApp(
    state: UiState<List<Movie>>,
    scaffoldState: ScaffoldState = rememberScaffoldState()
) {
    // 当 state 中包含错误时，显示一个 SnackBar,
    if (state.hasError) {
        // 显示一个 SnackBar 的显示需要一个协程环境，而 LaunchedEffect 会为其提供
        // 当 scaffoldState.snackbarHostState变化时，将启动一个新的协程, SnackBar重新显示一次
        // 当 state.hasError 变成 false 时，LaunchedEffect 进入 onDispose, 协程会被自动取消，SnackBar也会随之消失
        LaunchedEffect(scaffoldState.snackbarHostState) {
            scaffoldState.snackbarHostState.showSnackbar(
                message = "Error message",
                actionLabel = "Retry message"
            )
        }
    }
}

注意：使用LaunchedEffect时，务必要提供一个key，如果不这样做，那么它所处的Composable函数发生重组时，上一次的LaunchedEffect仍然在运行，其持有的状态仍然是上一次的，容易导致程序混乱，而且非常容易导致内存泄漏。

关于 LaunchedEffect(Unit)

我们通常会在一些示例代码中看到这样的写法:

它的作用是只执行一次副作用（这里是将Unit当作常量来使用，这里的Unit是kotlin中的一个object单例对象，其实这里传入其他任何常量也是可以的），也就是说当LaunchedEffect的key为常量时，不会依赖外部状态变化而反复执行，首次进入组合时开始执行，执行完毕就完了，即便重组也不会再次执行。

通常使用LaunchedEffect(Unit)可能是为了用来执行一次性的任务，例如首次进入时执行初始动画api；或者是纯粹的为了给挂起函数提供一个运行环境，例如进入时就开始观察某个Flow的数据变化，由于collect是挂起函数，所以必须在协程作用域中运行。

至于在实际中LaunchedEffect的key要不要设置为一个常量，只需要思考你的任务是否是需要跟随重组反复执行的，还是说只是在界面呈现时只执行一次而忽略后续重组。通常来说，如果你的任务是依赖于某个mutableStateof的可变状态，那么一般就使用该状态做key。

rememberCoroutineScope

由于 LaunchedEffect 是可组合函数， 因此只能在Composable函数中调用，如果想在非Composable环境中使用协程，例如 Button 的 onClick 方法中， 可以使用 rememberCoroutineScope，它会返回一个CoroutineScope 协程作用域，可以用来启动新的协程。 当 Composable 进入 onDispose 时，启动的协程会自动取消。如果你需要手动控制一个或多个协程的生命周期，可以考虑使用它，例如在用户事件发生时取消动画等。

• 用于运行绑定到组合生命周期的挂起的副作用。
• 创建绑定到这个组合生命周期的协程作用域CoroutineScope。
• 离开组合时，Scope 被取消。
• 在不同的组合中返回相同的作用域，因此我们可以继续向它提交更多的任务，所有正在进行的任务将在最终离开时被取消。
• 用于启动可响应用户交互的作业。
• 当进入组合时，在Applier的调度器上运行副作用（通常是 AndroidUiDispatcher.Main）。

下面的示例在点击按钮时，通过 rememberCoroutineScope 创建的协程作用域来启动一个的协程用于显示Snackbar：

@Composable
fun MyApp(scaffoldState: ScaffoldState = rememberScaffoldState()) {
    // 创建一个绑定 MyApp 生命周期的协程作用域
    val scope = rememberCoroutineScope()
    Scaffold(scaffoldState = scaffoldState) { padding ->
        Column(Modifier.padding(padding)) {
            Button(
                onClick = {
                    // 点击按钮时创建一个新的协程作用域，用于显示Snackbar
                    scope.launch {
                        scaffoldState.snackbarHostState.showSnackbar("Something happened!")
                    }
                }
            ) {
                Text(text = "Press me")
            }
        }
    }
}

下面的例子是一个 UI 端的限流操作：

在过去，你可能用过 View 系统的 postDelayed 或 Handler 来实现这个功能。每当文本输入发生变化时，我们希望取消之前正在进行的任何作业，并在延迟后发布一个新的作业，以便始终在潜在的网络请求之间强制执行最小的延迟。

与 LaunchedEffect 不同的是，LaunchedEffect 用于限定由组合发起的作业的作用域，而rememberCoroutineScope 则用于限定由用户交互发起的作业的作用域。

前面提到页面跳转其实也是一种副作用，在 Jetpack Compose中的导航路由 中提到过，使用 NavController 进行导航时，如果目标路由页面不存在，会直接抛出异常导致应用崩溃，当时给出的方法是使用 try-catch 或者定义一个方便的扩展函数来使用。其实最好的解决方案就是使用这里的 rememberCoroutineScope() 来解决：

@Composable
fun WelcomeScreen(navController : NavController) {
    Column(
        modifier = Modifier.fillMaxSize(),
        horizontalAlignment = Alignment.CenterHorizontally,
        verticalArrangement = Arrangement.Center
    ) {
        Text("WelcomeScreen", fontSize = 20.sp)
        val scope = rememberCoroutineScope()
        val context = remember {
            SupervisorJob() + Dispatchers.Main + CoroutineExceptionHandler { context, throwable ->
                println("${context[CoroutineName]} 发生了异常: $throwable")
            } + CoroutineName("跳转LoginScreen")
        }
        Button(onClick = {
            scope.launch(context) { navController.navigate("Login") }
        }) {
            Text(text = "Go to LoginScreen")
        }
    }
}

这里调转到Login路由页面时，使用 scope.launch(context) 在指定的协程上下文中运行，该协程上下文由 SupervisorJob() （用来隔离协程作用域，防止异常传播）、一个主线程调度器、一个协程异常处理器（用来打印异常日志）以及一个协程名称组成。这样即便目标路由页面不存在，也不会导致应用崩溃。我们可以在控制台看到如下日志：

CoroutineName(跳转LoginScreen) 发生了异常: java.lang.IllegalArgumentException: 
Navigation destination that matches request NavDeepLinkRequest{ uri=android-app://androidx.navigation/Login } 
cannot be found in the navigation graph NavGraph(0x0) startDestination={Destination(0x43892b15) route=Welcome}

rememberUpdatedState

rememberUpdatedState可以在不中断副作用的情况下感知外界的变化，一般用来获取观察状态的最新状态值。

@Composable
fun MyScreen(onTimeOut: () -> Unit) { 
    val currentOnTimeout by rememberUpdatedState(onTimeOut)
    // key为Unit时不会因为MyScreen的重组重新执行
    LaunchedEffect(Unit) {
        delay(300)
        currentOnTimeout() // 总是能获取到最新的 onTimeOut
    }
}

看下面的例子更加容易理解：

@Composable
private fun UpdatedRememberExample() {
    var myInput by remember { mutableStateOf(0) }

    Column(Modifier.height(100.dp)) {
        OutlinedButton(
            modifier = Modifier.fillMaxWidth().padding(vertical = 8.dp),
            onClick = { myInput++ }
        ) {
            Text("Increase rememberInput: $myInput")
        }
        Calculation(input = myInput)
    }
}
@Composable
private fun Calculation(input: Int) {
    val rememberUpdatedStateInput by rememberUpdatedState(input)
    val rememberedInput by remember { mutableStateOf(input) }
    Text("updatedInput: $rememberUpdatedStateInput, rememberedInput: $rememberedInput")
}

可以看到在Calculation组件中，使用rememberUpdatedState方式的每次都能读取到外部更新后的最新的状态值，而普通方式则不行。当然这里也可以使用 remember(key) { } 的方式也能达到效果。

查看rememberUpdatedState可知它就是不断的将新值赋值给自身的value而已：

@Composable
fun <T> rememberUpdatedState(newValue: T): State<T> = remember {
    mutableStateOf(newValue)
}.apply { value = newValue }

一般当需要使用Composable函数参数中传入的lambda或者需要在副作用API中使用传入的lambda参数时，建议将lambda包裹在rememberUpdateState中。

snapshotFlow

snapshotFlow 可以将 Compose 的 State 转换为 Flow。每当State变化时，flow就会发送新数据（但是冷流，调用collect才会发） snapshotFlow 会在收集到块时运行该块，并发出从块中读取的 State 对象的结果。当在 snapshotFlow 块中读取的 State 对象之一发生变化时，如果新值与之前发出的值不相等，Flow 会向其收集器发出新值（此行为类似于 Flow.distinctUntilChanged 的行为）。

@Composable
fun MyScreen2() {
    val pagerState = rememberPagerState()
    LaunchedEffect(pagerState) {
        snapshotFlow { pagerState.currentPage } .collect { page ->
            // currentPage发生变化
        }
    }
    HorizontalPager(
        count = 10,
        state = pagerState,
    ) { page ->
        // ...
    }
}

@Composable
fun SnapshotFlowDemo() {
    val scaffoldState = rememberScaffoldState()
    LaunchedEffect(scaffoldState) {
        snapshotFlow { scaffoldState.snackbarHostState }
            .mapNotNull { it.currentSnackbarData?.message }
            .distinctUntilChanged()
            .collect { message ->
                println("A SnackBar with message $message was shown")
            }
    }
}

produceState

produceState 和 derivedStateOf 都是状态创建的副作用API。从本质上讲，remember 也是一种副作用API，只在组件OnActive时被创建一次，不跟随重组反复创建。

produceState可以将任意数据源转换成一个State供给Composable函数使用

它实际上是建立在 LaunchedEffect 之上的语法糖。

@Composable
fun <T> produceState(
    initialValue: T,
    key1: Any?,
    key2: Any?,
    producer: suspend ProduceStateScope<T>.() -> Unit
): State<T> {
    val result = remember { mutableStateOf(initialValue) }
    LaunchedEffect(key1, key2) {
        ProduceStateScopeImpl(result, coroutineContext).producer()
    }
    return result
}

即produceState 会创建一个协程，它也可用于观察非挂起的数据源。 该协程将作用域限定为可将值推送到返回的 State 的组合。使用此协程将非 Compose 状态转换为 Compose 状态，例如将外部订阅驱动的状态（如 Flow、LiveData 或 RxJava）引入组合。

produceState 创建的协程会在进入组合时启动，在其退出组合时取消。设置相同的值不会触发重组。

以下是使用示例：

@Composable
fun loadNetWorkImage(
    url: String,
    imageRepository: ImageRepository
) : State<Result> {
    // produceState 观察 url 和 imageRepository 两个参数，当它们发生变化时，producer会重新执行
    // produceState的实现是通过 remember { mutableStateOf() } + LaunchedEffect （具有学习意义）
    // produceState 中的任务会随着 LaunchedEffect 的 onDispose 被自动停止。
    return produceState<Result>(initialValue = Result.Loading, url, imageRepository) {
        // 通过挂起函数请求图片
        val image = imageRepository.load(url)
        // 根据请求结果设置 Result
        // 当 Result 变化时，读取此 State 的 Composable 会触发重组
        value = if (image == null) {
            Result.Error
        } else {
            Result.Success(image)
        }
    }
}
@Composable
fun ProduceStateSampleButton() {
    var loadImage by remember { mutableStateOf(false) }
    Column(
        modifier = Modifier.fillMaxWidth(),
        horizontalAlignment = Alignment.CenterHorizontally
    ) {
        // Display a load image button when image is not loading
        OutlinedButton(onClick = { loadImage = !loadImage }) {
            Text(text = "Click to load image with produceState $loadImage")
        }
        if (loadImage) {
            ProduceStateExample()
        }
    }
}
@Composable
private fun ProduceStateExample() {
    val context = LocalContext.current
    val url = "www.example.com"
    val imageRepository = remember { ImageRepository() }
    val imageState = loadNetworkImage(url = url, imageRepository)
    when (imageState.value) {
        is Result.Loading -> {
            println("🔥 ProduceStateExample() Result.Loading")
            with(context) {showToast("🔥 ProduceStateExample() Result.Loading")}
            CircularProgressIndicator()
        }
        is Result.Error -> {
            println("❌ ProduceStateExample() Result.Error")
            with(context) {showToast("❌ ProduceStateExample() Result.Error")}
            Image(imageVector = Icons.Default.Error, contentDescription = null)
        }
        is Result.Success -> {
            println("✅ ProduceStateExample() Result.Success")
            with(context) {showToast("✅ ProduceStateExample() Result.Success")}
            val image = (imageState.value as Result.Success).image
            Image(
                painterResource(id = image.imageIdRes),
                contentDescription = null
            )
        }
    }
}
private fun Context.showToast(msg: String) = Toast.makeText(this, msg, Toast.LENGTH_SHORT).show()
sealed class Result {
    object Loading : Result()
    object Error : Result()
    class Success(val image: ImageRes) : Result()
}
class ImageRes(val imageIdRes: Int) 
class ImageRepository {     /**
     * Returns a drawable resource or null to simulate Result with Success or Error states
     */
    suspend fun load(url: String): ImageRes? {
        delay(2000) 
        // Random is added to return null if get a random number that is zero.
        // Possibility of getting null is 1/4
        return if (Random.nextInt(until = 4) > 0) { 
            val images = listOf(
                R.drawable.avatar_1_raster,
                R.drawable.avatar_2_raster,
                R.drawable.avatar_3_raster,
                R.drawable.avatar_4_raster,
                R.drawable.avatar_5_raster,
                R.drawable.avatar_6_raster,
            ) 
            // Load a random id each time load function is called
            ImageRes(images[Random.nextInt(images.size)])
        } else {
            null
        }
    }
}

你可以为produceState 提供一个可选的初始默认值initialValue ，也可以提供一个或多个key。

唯一需要注意的是，produceState 允许不传递任何key，在这种情况下，它将使用Unit作为key调用 LaunchedEffect，这会使其能够跨越组合。请注意这一点，因为API 接口文档中没有显式的说明这一点。

还可以在 produceState 中使用 awaitDispose 清理资源避免内存泄漏：

val currentPerson by produceState(null, viewModel) {
    val disposeable = viewModel.registerPersonObserver { person ->
        value = person
    }
    awaitDispose {
        // 当 Composable 进入 onDispose时，进入此处
        disposeable.dispose()
    }
}

derivedStateOf

derivedStateOf 用来将一个或多个 State 转成另一个用于观察的 State， derivedStateOf{...} 的 block 中可以依赖其他 State 创建并返回一个 DerivedState, 当 block 中依赖的 State 变化时，会更新此 DerivedState，依赖 DerivedState 的所有 Composable 会随之重组。

• 依赖的其他状态改变的时候，自身状态也会跟着改变。
• 通常配合 remember(key) 一起使用：val value by remember(otherState) { derivedStateOf{...使用otherState处理...}}
• 如果一个 List 是根据另一个 List 的处理之后的结果来展示。

以下示例展示了基本的“待办事项”列表，其中具有用户定义的高优先级关键字的任务将首先显示：

@Composable
fun TodoList(highPriorityKeywords: List<String> = listOf("Review", "Unblock", "Compose")) {

    val todoTasks = remember { mutableStateListOf<String>() }

    // Calculate high priority tasks only when the todoTasks or highPriorityKeywords
    // change, not on every recomposition
    val highPriorityTasks by remember(highPriorityKeywords) {
        derivedStateOf { todoTasks.filter { it.containsWord(highPriorityKeywords) } }
    }

    Box(Modifier.fillMaxSize()) {
        LazyColumn {
            items(highPriorityTasks) { /* ... */ }
            items(todoTasks) { /* ... */ }
        }
        /* Rest of the UI where users can add elements to the list */
    }
}

在以上代码中，derivedStateOf 保证每当 todoTasks 发生变化时，系统都会执行 highPriorityTasks 计算，并相应地更新界面。如果 highPriorityKeywords 发生变化，系统将执行 remember 代码块，并且会创建新的派生状态对象并记住该对象，以代替旧的对象。由于执行过滤以计算 highPriorityTasks 的成本很高，因此应仅在任何列表发生更改时才执行，而不是在每次重组时都执行。

此外，更新 derivedStateOf 生成的状态不会导致可组合项在声明它的位置重组，Compose 仅会对返回状态为已读的可组合项（在本例中，指 LazyColumn 中的可组合项）进行重组。

该代码还假设 highPriorityKeywords 的变化频率显著低于 todoTasks。否则，该代码会使用 remember(todoTasks, highPriorityKeywords) 而不是 derivedStateOf。

@Composable
fun SearchScreen() {
    val postList = remember { mutableStateListOf<String>() }
    val keyWord by remember { mutableStateOf("") }

    // 这里 postList 和 keyWord任意一个变化时，会更新 result
    val result by remember {
        derivedStateOf { postList.filter { it.contains(keyWord) } }
    }

    Box(modifier = Modifier.fillMaxSize()) {
        LazyColumn {
            items(result) { item ->
                Text(item)
            }
        }
    }
}

也可以使用 remember 实现：

val result2 = remember(postList, keyWord) {
     postList.filter { it.contains(keyWord) }
 }

但是这样写意味着postList 和 keyWord任意一个变化时，Composable会重组，与之相比 derivedStateOf 只有当输出的 DerivedState变化才会导致Composable重组，所以当一个计算结果依赖较多的 State 时，derivedStateOf 有助于减少重组次数，提高性能。

derivedStateOf 只能监听block内的 state，一个非State类型的数据变化则可以通过remember的key进行监听。

remember(key)

remember 函数有多个重载版本，其中我们最常用的写法是不带参数的版本: remember { mutableStateOf() }，但是它还可以传递多个 key 作为参数：remember(key1，key2, ...) { mutableStateOf() } 它根据参数 key 是否变化，来决定使用缓存的效果，当 key 的值发生变化后，重新执行 { } 里面的初始化代码，否则就一直返回内部的缓存值。

下面是一个简单计数器的例子，每当当前计算方式发生变化时，counter 的值会被重置：

@Composable
fun RememberKeyExample() {
    var operation by remember { mutableStateOf(MathOperation.INCREASE) }
    var counter by remember(operation) { mutableStateOf(0) }
    Button(
        modifier = Modifier.fillMaxWidth(),
        onClick = {
            operation = when (operation) {
                MathOperation.INCREASE -> MathOperation.DECREASE
                MathOperation.DECREASE -> MathOperation.INCREASE
            }
        }
    ) {
        val text = when (operation) {
            MathOperation.INCREASE -> "Increase"
            MathOperation.DECREASE -> "Decrease"
        }
        Text("Current operation $text")
    }
    Button(
        modifier = Modifier.fillMaxWidth(),
        onClick = {
            when (operation) {
                MathOperation.INCREASE -> counter++
                MathOperation.DECREASE -> counter--
            }
        }
    ) {
        Text(text = "Counter $counter")
    }
}
enum class MathOperation { INCREASE, DECREASE }

副作用的观察参数

很多副作用Api都允许指定观察参数key，当key变化时，执行中的副作用会终止。 key的频繁变化会影响执行效率。因此关于key的使用应当遵循以下原则： 当一个状态的变化需要造成副作用终止时，才将其添加为观察参数key, 否则应该将其通过rememberUpdatedState包装后，在副作用中使用，以避免打断执行中的副作用。

@Composable
fun HomeScreen(
    lifecycleOwner: LifecycleOwner = LocalLifecycleOwner.current,
    onStart: () -> Unit,
    onStop: () -> Unit,
) {
    val currentOnStart by rememberUpdatedState(onStart)
    val currentOnStop by rememberUpdatedState(onStop)

    DisposableEffect(lifecycleOwner) {
        val observer = LifecycleEventObserver { _, event ->
            // 回调 currentOnStart() 或 currentOnStop()
            when(event) {
                Lifecycle.Event.ON_START -> currentOnStart()
                Lifecycle.Event.ON_STOP -> currentOnStop()
                else -> { }
            }
        }
        lifecycleOwner.lifecycle.addObserver(observer)
        onDispose {
            lifecycleOwner.lifecycle.removeObserver(observer)
        }
    }
}

上面的示例中，当 lifecycleOwner 变化时，需要终止对当前 lifecycleOwner 的监听，并重新注册Observer, 因此这里才将其添加为key。而 onStart 和 onStop 只要保证在回调它们时，可以获取最新的值即可，所以应该使用rememberUpdatedState包装，不应该作为观察参数因为它们的变动终止副作用执行。

什么情况下该用 derivedStateOf { } Or remember(key) { } ？

记住以下原则即可：

也就是说，如果使用 derivedStateOf 一般是你确定你所观察的状态或key的变化频率远高于你所期望的更新频率；而如果使用 remember(key) 则是你确定你的状态和传入的key的变化频率一样，换句话说就是你的状态每次都跟着你的key的变化而变化。

比如下图的示例中，submitEnabled在输入框文本内容合法时会变成true，代表提交按钮变为可用状态：

当输入框的内容从空白变成一个字符时，提交按钮从不可用变成可用状态，这没有问题，然而在当我们继续向输入框中输入文字时，情况有所不同：

可以看到后续向输入框持续输入内容时，已经变成true的submitEnabled仍然会被反复更新为true，而每次submitEnabled被更新为true时，界面都会触发重组流程。这不是我们想要的效果，我们想要的是只有在submitEnabled状态的值发生不同的改变时，才会重组，即在从false变成true以后，只有再次从true变成false时才会重复，而不是每次都重组。

这时正是使用 derivedStateOf 的场景：

我们发现如果换成 derivedStateOf { } 后，同样的场景submitEnabled只会触发三次更新：

另外一个典型的常见例子就是在列表中显示一个 “回到顶部” 的按钮：

假如我们这样做，那么 LazyList 在滚动的每一帧都会更新 listState, 这会导致读取listState的地方不停的进行重组。此时可以使用derivedStateOf避免滑动过程中每一帧更新listState导致重组，而是只在索引值发生从 【等于0】到【大于0】之间的变化时，才会更新showButton的状态。

但并不是每次创建衍生的新状态时都需要使用 derivedStateOf，比如计算列表的大小时，此时 contacts.size的变化频率跟contactCount的是一样的，完全没有必要，还会增加额外开销：

下面再看一个模拟购物车增加商品数量的代码示例：

@Composable
private fun DerivedStateOfExample() {
    var numberOfItems by remember { mutableStateOf(0) }

    Column(modifier = Modifier.padding(horizontal = 8.dp).height(100.dp)) {
        Surface {
            Row(verticalAlignment = Alignment.CenterVertically) {
                Text(text = "Amount to buy: $numberOfItems", modifier = Modifier.weight(1f))
                IconButton(onClick = { numberOfItems++ }) {
                    Icon(imageVector = Icons.Default.Add, contentDescription = "add")
                }
                Spacer(modifier = Modifier.width(4.dp))
                IconButton(onClick = { if (numberOfItems > 0) numberOfItems-- }) {
                    Icon(imageVector = Icons.Default.Remove, contentDescription = "remove")
                }
            }
        }

        Surface {
            val derivedStateMax by remember {
                derivedStateOf { numberOfItems > 5 }
            }

            if (derivedStateMax) {
                println("🤔 COMPOSING...")
                Text("You cannot buy more than 5 items",
                    color = Color(0xffE53935),
                    modifier = Modifier.fillMaxWidth().background(getRandomColor())
                )
            }
        }
        Surface {
            val derivedStateMax2 by remember(numberOfItems) {
                mutableStateOf(numberOfItems > 5)
            }

            if (derivedStateMax2) {
                println("🤔 COMPOSING...2")
                Text("You cannot buy more than 5 items",
                    color = Color(0xffE53935),
                    modifier = Modifier.fillMaxWidth().background(getRandomColor())
                )
            }
        }
    }
}

上面代码中列出了两种对比状态：第一个derivedStateMax使用 derivedStateOf { } 方式的状态，而第二个derivedStateMax2 使用 remember(key) { } 方式的状态。运行效果如下：

很显然，可以看到使用 derivedStateOf { } 方式的状态，当数量超过5之后，继续增加数量也不会再导致状态更新了，只有数量再次减到5以下才会更新一次；而下面使用 remember(key) { } 方式的状态值则每次都会更新状态触发重组。我想这个例子应该能很好的表达二者的区别。

假如我们有一个比较复杂的函数，它依赖于输入参数进行一些比较”昂贵”的计算处理，然后我们的UI需要根据函数的输出来更新，这时就适合需要使用 remember(key) { } 的场景，因为我们期望UI跟随key的变化而变化，即对于相同的输入我们期望有相同的输出(即避免重复计算)，而对不同的输入有不同的输出。

val output = remember(input) { expensiveCalculate(input) } 

derivedStateOf 需要总是被 remembered 吗？

如果你使用 derivedStateOf 是在Composable函数内部，是的，它需要跟mutableStateof以及其他需要跨越重组而存活的对象一样，需要使用一个remember{ }来包裹，否则在每次重组时都将被初始化为一个新的对象实例。

@Composable
fun MyComposable() {
	// we need to use remember here to survive recomposition
	val state = remember { derivedStateOf {...} }
}

但是如果你是在状态容器中使用 derivedStateOf ，那就不一定需要remember{ }来包裹了，比如在ViewModel中，因为ViewModel本身就是甚至能超越Activity的生死而存在的东西。

class MyViewModel: ViewModel() {
	// we don't need remember here (nor could we use it) because the ViewModel is outside of Composition.
	val state = derivedStateOf {...}
}

第三方库适配

我们经常需要使用来自第三方库的其他数据类型，例如 Observable、Flow 或 LiveData。Jetpack Compose 为最常见的第三方类型提供了适配器，因此取决于库，你需要获取不同的依赖项。

所有这些适配器最终都会委托给副作用处理程序。它们都使用第三方库的 API 来添加观察者，并将每个发出的元素映射到一个特定的 MutableState 上，该 MutableState 作为不可变的 State 在适配器函数中公开。

下面是不同库的一些示例

LiveData

observeAsState的实际实现依赖于DisposableEffect处理程序。

RxJava2

同样的扩展对 Flowable 也适用。

KotlinX Coroutines Flow

collectAsState 的实现有点不同，因为Flow需要从挂起的上下文中消费。这就是为什么它依赖produceState而不是委托launchedeeffect的原因。

所有这些适配器都依赖于前面提到的副作用处理API，如果您有一个要集成的库，您可以按照相同的模式轻松编写自己的适配器。

总结