Compose:长期副作用 + 智能重组 = 若智?(一)

简介: Compose:长期副作用 + 智能重组 = 若智?

笔者曾经写过一篇关于新手入坑Jetpack Compose的文章,其中谈到了rememberUpdateState的使用场景,但是最近的一次项目中还是踩坑了,而且收到了很多人反馈表示依然不理解如何正常使用这个Api,于是单独写一篇文章展开说说。

关于提到的文章传送门:妈!Jetpack Compose太难学了,别怕,这里帮你理清几个概念 - 掘金 (juejin.cn)

如果你完全不明白什么是智能重组副作用,可以先看看笔者写的这篇文章。


1.长期副作用


在Jetpack Compose的世界中,所谓的长期副作用基本就是等价于协程中的挂起函数,这个定义不一定对,但是足够覆盖绝大多数场景。

让我们看看一个长期副作用的样子:


@Composable
fun LongRunningSideEffectExample(){
    LaunchedEffect(Unit){
        delay(1000)
        // TODO: 我是长期副作用 
    }
}

可见,一个简单的长期副作用其实就是一个一段时间后才执行的逻辑,在大多数场景下,在delay结束后执行的逻辑都没有什么问题。


2.智能重组


众所周知,Jetpack Compose的编译器存在魔法,会在重组的时候,根据参数的是否发生了变化来决定是否充足当前的组件,这就是所谓的智能重组。

让我们看看一个智能重组的案例:


@Composable
fun RecompositionExample(
    text:String
){
    SideEffect {
        Log.d("重组记录","当前的值:$text")
    }
    Text(
        text=text
    )
}

SideEffectApi会在重组成功后调用lambda,因此我们可以通过观察日志来查看当前组件的重组时刻,通过实验得知,只有text参数发生变化的时候,SideEffect的lambda才会被执行,这就是所谓的智能重组,Compose会尽可能跳过没意义的重组。


3.长期副作用+智能重组=?


两者都是Jetpack Compose非常优秀的机制,但是两者在一起很容易出问题,例如下面这个组件:


@Composable
@Preview
fun LongRunningSideEffectWrongExample() {
    var count by remember {
        mutableStateOf(0)
    }
    Column {
        Button(onClick = { count++ }) {
            Text("当前的值:$count")
        }
        DelayOutputText(text = "$count")
    }
}
@Composable
fun DelayOutputText(
    text: String,
) {
    var delayOutputText by remember { mutableStateOf("") }
    LaunchedEffect(Unit) {
        delay(3000L)
        delayOutputText = text
    }
    Text("延迟输出的值:$delayOutputText")
}

组件非常简单,在出现DelayOutputText3秒后,尝试显示最新的text值,但是实际运行结果如下:

image.png

可见,3秒后并没有显示最新的值,而是显示初始化的值,不是说智能重组吗,怎么没重组,问题出在哪里了?

让我们回到LaunchedEffect本身的源码:


@Composable
@NonRestartableComposable
@OptIn(InternalComposeApi::class)
fun LaunchedEffect(
    key1: Any?,
    block: suspend CoroutineScope.() -> Unit
) {
    val applyContext = currentComposer.applyCoroutineContext
    remember(key1) { LaunchedEffectImpl(applyContext, block) }
}

LaunchEffect内部使用了一个remember来包裹LaunchedEffectImpl,总所周知,如果key没有发生变化,remember的lambda是不会重新被执行的,而我们通过LaunchedEffect传入的block参数,就在remember的lambda中,这导致了一个问题:

如果LaunchedEffect的key没有发生变化,LaunchedEffect内部的lambda拿到的block参数是旧的

回到上文提到的出问题的代码,

image.png

笔者框住的这个代码块,看似是3秒后用最新的text值赋值给delayOutputText,实际上这是一种思维误区,真实的情况则是:如果key没有发生变化的情况,即没有重启LaunchedEffect的情况下,lambda一直都是最初的那个实例,那个lambda实例取的text则是最初启动的时刻的值,因此3秒后,delayOutputText = text这段代码,实际上是将text第一次的值传给了delayoOutputText,后续的text值都被忽略了。

一切问题的根源是remember

remember忽视掉了新的lambda,最终执行的lambda都是最初那个,那么lambda内部的变量自然也是旧的了。

问题找到了,笔者想用一句经典的话来概括上述这段问题:

这不是一个bug,而是一个feature


目录
打赏
0
0
0
0
1
分享
相关文章
构建高效的Android应用:内存优化策略详解
随着智能手机在日常生活和工作中的普及,用户对移动应用的性能要求越来越高。特别是对于Android开发者来说,理解并实践内存优化是提升应用程序性能的关键步骤。本文将深入探讨针对Android平台的内存管理机制,并提供一系列实用的内存优化技巧,以帮助开发者减少内存消耗,避免常见的内存泄漏问题,并确保应用的流畅运行。
Compose:从重组谈谈页面性能优化思路,狠狠优化一笔
Compose:从重组谈谈页面性能优化思路,狠狠优化一笔
365 0
精简函数栈帧:优化创建和销毁过程的完全解析(建议收藏,提升内功)
精简函数栈帧:优化创建和销毁过程的完全解析(建议收藏,提升内功)
102 1
|
6月前
数据平台问题之在数据影响决策的过程中,如何实现“决策/行动”阶段
数据平台问题之在数据影响决策的过程中,如何实现“决策/行动”阶段
持续部署的内涵和实施路径问题之集成尽早进行每次集成很小的问题如何解决
持续部署的内涵和实施路径问题之集成尽早进行每次集成很小的问题如何解决
构建高效的Android应用:内存优化策略解析
【5月更文挑战第25天】在移动开发领域,性能优化一直是一个不断探讨和精进的课题。特别是对于资源受限的Android设备来说,合理的内存管理直接关系到应用的流畅度和用户体验。本文深入分析了Android内存管理的机制,并提出了几种实用的内存优化技巧。通过代码示例和实践案例,我们旨在帮助开发者识别和解决内存瓶颈,从而提升应用性能。
构建高效的Android应用:内存优化策略
【4月更文挑战第16天】 在移动开发领域,尤其是针对资源有限的Android设备,内存优化是提升应用性能和用户体验的关键因素。本文将深入探讨Android应用的内存管理机制,分析常见的内存泄漏问题,并提出一系列实用的内存优化技巧。通过这些策略的实施,开发者可以显著减少应用的内存占用,避免不必要的后台服务,以及提高垃圾回收效率,从而延长设备的电池寿命并确保应用的流畅运行。
Compose:长期副作用 + 智能重组 = 若智?(二)
Compose:长期副作用 + 智能重组 = 若智?
219 0

热门文章

最新文章

AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等