首页 > 其他分享 >Compose 状态保存：rememberSaveable 原理分析

Compose 状态保存：rememberSaveable 原理分析

时间：2023-06-19 10:35:26浏览次数：43  
标签：rememberSaveable Compose val SaveableStateRegistry list value key 原理


前言

我曾经在一篇介绍 Compose Navigation 的文章 中提到了 Navigation 的状态保存实际是由 rememberSaveable 实现的，有同学反馈希望单独介绍一下 rememberSaveable 的功能及实现原理。

我们都知道 remember 可以保存数据、避免状态因重组而丢失，但它依然无法避免在 ConfigurationChanged 时的数据丢失。想要在横竖屏切换等场景下依然保存状态，就需要使用 rememberSavable。

从一个报错说起

首先，在代码使用上 rememberSaveable 和 remember 没有区别：

//保存列表状态
val list = rememberSaveable {
    mutableListOf<String>()
}

//保存普通状态
var value by rememberSaveable {
    mutableStateOf("")
}

如上，只要将 remember 改为 rememberSaveable，我们创建的状态就可以跨越横竖屏切换甚至跨越进程持续保存了。不过 rememberSaveable 中并非任何类型的值都可以存储：

data class User(
    val name: String = ""
)

val user = rememberSaveable {
    User()
}

上面代码运行时会发生错误：

java.lang.IllegalArgumentException: User(name=) cannot be saved using the current SaveableStateRegistry. The default implementation only supports types which can be stored inside the Bundle. Please consider implementing a custom Saver for this class and pass it to rememberSaveable().

User 无法存入 Bundle。这非常合理，因为 rememberSaveable 中数据的持久化最终在 ComponentActivity#onSaveInstanceState 中执行，这需要借助到 Bundle 。

rememberSaveable 源码分析

那么，rememberSaveable 是如何关联到 onSaveInstanceState 的呢？接下来简单分析一下内部实现

@Composable
fun <T : Any> rememberSaveable(
    vararg inputs: Any?,
    saver: Saver<T, out Any> = autoSaver(),
    key: String? = null,
    init: () -> T
): T {
    //...

    // 通过 CompositionLocal 获取 SaveableStateRegistry
    val registry = LocalSaveableStateRegistry.current

    // 通过 init 获取需要保存的数据
    val value = remember(*inputs) {
        // registry 根据 key 恢复数据，恢复的数据是一个 Saveable
        val restored = registry?.consumeRestored(finalKey)?.let {
            // 使用 Saver 将 Saveable 转换为业务类型
            saver.restore(it)
        }
        restored ?: init()
    }

    // 用一个 MutableState 保存 Saver，主要是借助 State 的事务功能避免一致性问题发生
    val saverHolder = remember { mutableStateOf(saver) }
    saverHolder.value = saver

    if (registry != null) {
        DisposableEffect(registry, finalKey, value) {
            //ValueProvider：通过 Saver#save 存储数据
            val valueProvider = {
                with(saverHolder.value) { SaverScope { registry.canBeSaved(it) }.save(value) }
            }
            //试探数值是否可被保存
            registry.requireCanBeSaved(valueProvider())
            //将ValueProvider 注册到 registry ，等到合适的时机被调用
            val entry = registry.registerProvider(finalKey, valueProvider)
            onDispose {
                entry.unregister()
            }
        }
    }
    return value
}

如上，逻辑很清晰，主要是围绕 registry 展开的：

  1. 通过 key 恢复持久化的数据
  2. 基于 key 注册 ValueProvider，等待合适时机执行数据持久化
  3. 在 onDispose 中被注销注册

registry 是一个 SaveableStateRegistry 。

恢复 key 的数据

rememberSaveable 是加强版的 remember，首先要具备 remember 的能力，可以看到内部也确实是调用了 remember 来创建数据同时缓存到 Composition 中。init 提供了 remember 数据的首次创建。被创建的数据在后续某个时间点进行持久化，下次执行 rememberSaveable 时会尝试恢复之前持久化的数据。具体过程分为以下两步：

  1. 通过 registry.consumeRestored 查找 key 获取 Saveable，
  2. Saveable 经由 saver.restore 转换为业务类型。

上述过程涉及到两个角色：

  • SaveableStateRegistry：通过 CompositionLocal 获取，它负责将 Bundle 中的数据反序列化后，返回一个 Saveable
  • Saver：Saver 默认有 autoSaver 创建，负责 Saveable 与业务数据之间的转换。

Saveable 并不是一个在具体类型，它可以是可被持久化（写入 Bundle）的任意类型。对于 autoSaver 来说， 这个 Saveable 就是业务数据类型本身。

private val AutoSaver = Saver<Any?, Any>(
    save = { it },
    restore = { it }
)

对于一些复杂的业务结构体，有时并非是所有字段都需要持久化。Saver 为我们提供了这样一个机会机会，可以按照需要将业务类型转化为可序列化类型。Compose 也提供了两个预置的 Saver：ListSaver 和 MapSaver，可以用来转换成 List 或者 Map。

关于恢复数据的 Key ：可以看到数据的保存和恢复都依赖一个 key，按道理 key 需要在保存和恢复时严格保持一致 ，但我们平日调用 rememberSaveable 时并没有指定具体的 key，那么在横竖屏切换甚至进程重启后是如何恢复数据的呢？其实这个 key 是 Compose 自动帮我们设置的，它就是编译期插桩生成的基于代码位置的 key ，所以可以保证每次进程执行到此处都保持不变

注册 ValueProvider

SaveableStateRegistry 在 DisposableEffect 中关联 key 注册 ValueProvider。 ValueProvider 是一个 lambda，内部会调用 Saver#save 将业务数据转化为 Saveable。

Saver#save 是 SaverScope 的扩展函数，所以这里需要创建一个 SaverScope 来调用 save 方法。SaverScope 主要用来提供 canBeSaved 方法，我们在自定义 Saver 时可以用来检查类型是否可被持久化

ValueProvider 创建好后紧接着会调用 registry.registerProvider 进行注册，等待合适的时机（比如 Activity 的 onSaveInstanceState）被调用。在注册之前，先调用 requireCanBeSaved 判断数据类型是否可以保存，这也就是文章前面报错的地方。先 mark 一下，稍后我们看一下具体检查的实现。

注销 registry

最后在 onDispose 中调用 unregister 注销之前的注册 。

rememberSaveable 的基本流程理清楚了，可以看见主角就是 registry，因此有必要深入 SaveableStateRegistry 去看一下。我们顺着 LocalSaveableStateRegistry 可以很容易找到 registry 的出处。

DisposableSavableStateRegistry 源码分析

override fun setContent(content: @Composable () -> Unit) {
    //...
    ProvideAndroidCompositionLocals(owner, content)
    //...
}

@Composable
@OptIn(ExperimentalComposeUiApi::class)
internal fun ProvideAndroidCompositionLocals(
    owner: AndroidComposeView,
    content: @Composable () -> Unit
) {
    val view = owner
    val context = view.context

    //...

    val viewTreeOwners = owner.viewTreeOwners ?: throw IllegalStateException(
        "Called when the ViewTreeOwnersAvailability is not yet in Available state"
    )
    val saveableStateRegistry = remember {
        DisposableSaveableStateRegistry(view, viewTreeOwners.savedStateRegistryOwner)
    }

    //...
    CompositionLocalProvider(
        //...
        LocalSaveableStateRegistry provides saveableStateRegistry,
        //...
    ) {
        ProvideCommonCompositionLocals(
            owner = owner,
            //...
            content = content
        )
    }
}

如上，我们在 Activity 的 setContent 中设置各种 CompositionLocal，其中就有 LocalSaveableStateRegistry，所以 registry 不仅是一个 SaveableStateRegistry，更是一个 DisposableSaveableStateRegistry 。

接下来看一下 DisposableSaveableStateRegistry 的创建过程 。

saveableStateRegistry 与 SavedStateRegistry

注意下面这个 DisposableSaveableStateRegistry 不是真正的构造函数，它是同名构造函数的一个 Wrapper，在调用构造函数创建实例之前，先调用 androidxRegistry 进行了一系列处理：

internal fun DisposableSaveableStateRegistry(
    id: String,
    savedStateRegistryOwner: SavedStateRegistryOwner
): DisposableSaveableStateRegistry {
    //基于 id 创建 key
    val key = "${SaveableStateRegistry::class.java.simpleName}:$id"

    // 基于 key 获取 bundle 数据
    val androidxRegistry = savedStateRegistryOwner.savedStateRegistry
    val bundle = androidxRegistry.consumeRestoredStateForKey(key)
    val restored: Map<String, List<Any?>>? = bundle?.toMap()

    // 创建 saveableStateRegistry，传入 restored 以及 canBeSaved
    val saveableStateRegistry = SaveableStateRegistry(restored) {
        canBeSavedToBundle(it)
    }

    val registered = try {
        androidxRegistry.registerSavedStateProvider(key) {
            //调用 register#performSave 并且转为 Bundle
            saveableStateRegistry.performSave().toBundle()
        }
        true
    } catch (ignore: IllegalArgumentException) {
        false
    }

    return DisposableSaveableStateRegistry(saveableStateRegistry) {
        if (registered) {
            androidxRegistry.unregisterSavedStateProvider(key)
        }
    }
}

androidxRigistry 跟 rememberSaveable 中的 registry 做的事情类似：

  1. 基于 key 恢复 bundle 数据，
  2. 基于 key 注册 SavedStateProvider。

但 androidxRegistry 不是一个 SaveableStateRegistry 而是一个 SavedStateRegistry。名字上有点绕，后者来自 androidx.savedstate ，属于平台代码，而 SaveableStateRegistry 属于 compose-runtime 的平台无关代码。可见这个构造函数的同名 Wrapper 很重要，他就像一个桥梁，解耦和关联了平台相关和平台无关代码。

DisposableSaveableStateRegistry 与 SaveableStateRegistryImpl

DisposableSaveableStateRegistry 真正的构造函数定义如下：

internal class DisposableSaveableStateRegistry(
    saveableStateRegistry: SaveableStateRegistry,
    private val onDispose: () -> Unit
) : SaveableStateRegistry by saveableStateRegistry {

    fun dispose() {
        onDispose()
    }
}

这里用了参数 saveableStateRegistry 作为 SaveableStateRegistry 接口的代理。saveableStateRegistry 实际是一个 SaveableStateRegistryImpl 对象，它像这样创建:

val saveableStateRegistry = SaveableStateRegistry(restored) {
    canBeSavedToBundle(it)
}

fun SaveableStateRegistry(
    restoredValues: Map<String, List<Any?>>?,
    canBeSaved: (Any) -> Boolean
): SaveableStateRegistry = SaveableStateRegistryImpl(restoredValues, canBeSaved)

SaveableStateRegistryImpl 被创建时传入两个参数：

  • restoredValues：androidxRegistry 恢复的 bundle 数据，是一个 Map 对象。
  • canBeSaved : 用来检查数据是否可持久化，可以的看到这里实际调用了 canBeSavedToBundle。

canBeSavedToBundle

文章开头的报错就是 requireCanBeSaved -> canBeSavedToBundle 检查出来的，通过 canBeSavedToBundle 看一下 rememberSaveable 支持的持久化类型：

private fun canBeSavedToBundle(value: Any): Boolean {
    // SnapshotMutableStateImpl is Parcelable, but we do extra checks
    if (value is SnapshotMutableState<*>) {
        if (value.policy === neverEqualPolicy<Any?>() ||
            value.policy === structuralEqualityPolicy<Any?>() ||
            value.policy === referentialEqualityPolicy<Any?>()
        ) {
            val stateValue = value.value
            return if (stateValue == null) true else canBeSavedToBundle(stateValue)
        } else {
            return false
        }
    }
    for (cl in AcceptableClasses) {
        if (cl.isInstance(value)) {
            return true
        }
    }
    return false
}

private val AcceptableClasses = arrayOf(
    Serializable::class.java,
    Parcelable::class.java,
    String::class.java,
    SparseArray::class.java,
    Binder::class.java,
    Size::class.java,
    SizeF::class.java
)

首先， SnapshotMutableState 允许被持久化，因为我们需要在 rememberSaveable 中调用 mutableStateOf；其次，SnapshotMutableState 的泛型必须是 AcceptableClasses 中的类型，我们自定义的 User 显然不符合要求，因此报了开头的错误。

SaveableStateRegistryImpl 源码分析

前面理清了几个 Registry 类型的关系，整理如下图

Compose 状态保存：rememberSaveable 原理分析_android

SaveableStateRegistry 接口的各主要方法都由 SaveableStateRegistryImpl 代理的：

  • consumeRestored：根据 key 恢复数据
  • registerProvider：注册 ValueProvider
  • canBeSaved：用来检查数据是否是可保存类型
  • performSave：执行数据保存

canBeSaved 前面介绍过，其实会回调 canBeSavedToBundle。接下来看一下 SaveableStateRegistryImpl 中其他几个方法是如何实现的：

consumeRestored

override fun consumeRestored(key: String): Any? {
        val list = restored.remove(key)
        return if (list != null && list.isNotEmpty()) {
            if (list.size > 1) {
                restored[key] = list.subList(1, list.size)
            }
            list[0]
        } else {
            null
        }
    }

我们知道 restored 是从 Bundle 中恢复的数据，实际是一个 Map了类型。而 consumeRestored 就是在 restored 中通过 key 查找数据。restore 的 Value 是 List 类型。当恢复数据时，只保留最后一个只。顺便吐槽一下 consumeRestored 这个名字，将 restore 这个 private 成员信息暴露给了外面，有些莫名其妙。

registerProvider

override fun registerProvider(key: String, valueProvider: () -> Any?): Entry {
        require(key.isNotBlank()) { "Registered key is empty or blank" }
        @Suppress("UNCHECKED_CAST")
        valueProviders.getOrPut(key) { mutableListOf() }.add(valueProvider)
        return object : Entry {
            override fun unregister() {
                val list = valueProviders.remove(key)
                list?.remove(valueProvider)
                if (list != null && list.isNotEmpty()) {
                    // if there are other providers for this key return list back to the map
                    valueProviders[key] = list
                }
            }
        }
    }

将 ValueProvider 注册到 valueProviders ，valueProviders 也是一个值为 List 的 Map，同一个 Key 可以对应多个 Value。返回的 Entry 用于 onDispose 中调用 unregister。

DisposableSaveableStateRegistry 是一个 CompositionLocal 单例，所以需要 unregister 避免不必要的泄露。注意这里要确保同一个 key 中的 List 中的其它值不被移除

不解：什么情况下同一个 key 会 registerProvider 多个值呢？

performSave

override fun performSave(): Map<String, List<Any?>> {
        val map = restored.toMutableMap()
        valueProviders.forEach { (key, list) ->
            if (list.size == 1) {
                val value = list[0].invoke()
                if (value != null) {
                    check(canBeSaved(value))
                    map[key] = arrayListOf<Any?>(value)
                }
            } else {
                map[key] = List(list.size) { index ->
                    val value = list[index].invoke()
                    if (value != null) {
                        check(canBeSaved(value))
                    }
                    value
                }
            }
        }
        return map
    }

在这里调用了 ValueProvider 获取数据后存入 restored ，这里也是有针对 Value 是 List 类型的特别处理。performSave 的调用时机前面已经出现了，是 androidxRegistry 注册的 Provider 中调用：

androidxRegistry.registerSavedStateProvider(key) {
            //调用 register#performSave 并且转为 Bundle
            saveableStateRegistry.performSave().toBundle()
        }

SavedStateProvider 会在 onSaveInstance 时被执行。

至此， rememberSaveable 持久化发生的时机与平台进行了关联。

最后回看 androidxRegistry

最后我们再回看一下 DisposableSavableStateRegistry，主要是使用 androidxRegistry 获取 key 对应的数据，并注册 key 对应的 Provider。那么 androidxRegistry 和 key 是怎么来的？

internal fun DisposableSaveableStateRegistry(
    id: String,
    savedStateRegistryOwner: SavedStateRegistryOwner
): DisposableSaveableStateRegistry {

    val key = "${SaveableStateRegistry::class.java.simpleName}:$id"

    val androidxRegistry = savedStateRegistryOwner.savedStateRegistry

    //...

 }

先说 key 。key 由 id 唯一决定，而这个 id 其实是 ComposeView 的 layoutId。我们知道 ComposeView 是 Activity/Fragment 承载 Composable 的容器，rememberSaveable 会按照 ComposeView 为单位来持久化数据。

因为你 ComposeView 的 id 决定了 rememberSaveable 存储数据的位置，如果 Activity/Fragment 范围内如果有多个 ComposeView 使用了同一个 id，则只有第一个 ComposeView 能正常恢复数据，这一点要特别注意

再看一下 androidxRegistry，他由 SavedStateRegistryOwner 提供，而这个 owner 是ComposeView 被 attach 到 Activity 时赋的值，就是 Activity 本身：

public class ComponentActivity extends androidx.core.app.ComponentActivity implements
        ContextAware,
        LifecycleOwner,
        ViewModelStoreOwner,
        HasDefaultViewModelProviderFactory,
        SavedStateRegistryOwner, // ComponentActivity 是一个 SavedStateRegistryOwner
        OnBackPressedDispatcherOwner,
        ActivityResultRegistryOwner,
        ActivityResultCaller {

    //...

    public final SavedStateRegistry getSavedStateRegistry() {
        return mSavedStateRegistryController.getSavedStateRegistry();
    }

    //...
}

mSavedStateRegistryController 会在 Activity 重建时 onCreate 中调用 performRestore；在 onSaveInstanceState 时执行 performSave。

protected void onCreate(@Nullable Bundle savedInstanceState) {
    mSavedStateRegistryController.performRestore(savedInstanceState);
    //...
}

protected void onSaveInstanceState(@NonNull Bundle outState) {
    //...
    mSavedStateRegistryController.performSave(outState);
}

mSavedStateRegistryController 最终调用到 SavedStateRegistry 的同名方法，看一下 SavedStateRegistry#performSave：

fun performSave(outBundle: Bundle) {
    //...
    val it: Iterator<Map.Entry<String, SavedStateProvider>> =
        this.components.iteratorWithAdditions()
    while (it.hasNext()) {
        val (key, value) = it.next()
        components.putBundle(key, value.saveState())
    }
    if (!components.isEmpty) {
        outBundle.putBundle(SAVED_COMPONENTS_KEY, components)
    }
}

components 是注册 SavedStateProvider 的 Map。 performSave 中调用 Provider 的 saveState 方法获取到 rememberSaveable 中保存的 bundle，然后存入 outBundle 进行持久化。

至此，rememberSaveable 在 Android 平台完成了横竖屏切换时的状态保存。

最后我们用一个图收尾，红色是保存数据时的数据流流向，绿色是恢复数据时的数据流流向：

Compose 状态保存：rememberSaveable 原理分析_持久化_02

作者：fundroid

最后

如果想要成为架构师或想突破20~30K薪资范畴，那就不要局限在编码，业务，要会选型、扩展，提升编程思维。此外，良好的职业规划也很重要，学习的习惯很重要，但是最重要的还是要能持之以恒，任何不能坚持落实的计划都是空谈。

如果你没有方向，这里给大家分享一套由阿里高级架构师编写的《Android八大模块进阶笔记》，帮大家将杂乱、零散、碎片化的知识进行体系化的整理，让大家系统而高效地掌握Android开发的各个知识点。

Compose 状态保存：rememberSaveable 原理分析_ide_03


相对于我们平时看的碎片化内容，这份笔记的知识点更系统化，更容易理解和记忆，是严格按照知识体系编排的。

标签：rememberSaveable,Compose,val,SaveableStateRegistry,list,value,key,原理
From： https://blog.51cto.com/u_16163480/6511306

相关文章

  • 一文读懂ChatGPT的工作原理：大语言模型是个啥？它到底咋工作的？
    继AI绘画后，ChatGPT横空出世。聊天、翻译、文案、代码……ChatGPT的功能如此强大，以至于连马斯克都认为“我们离强大到危险的AI不远了。”在感慨ChatGPT如此强大的同时，人们也开始对ChatGPT的工作原理产生了好奇：ChatGPT是什么？它到底是如何运行的？怎样才能丝滑地与它对话呢？想要了解Ch......
  • Airtest图像识别测试工具原理解读&最佳实践
    1Airtest简介Airtest是一个跨平台的、基于图像识别的UI自动化测试框架，适用于游戏和App，支持平台有Windows、Android和iOS。Airtest框架基于一种图形脚本语言Sikuli，引用该框架后，不再需要一行行的写代码，通过截取按钮或输入框的图片，用图片组成测试场景，这种方式学习成本低，简单易上手......
  • cppchecker简单介绍和原理初窥
    1.概述：c/c++代码静态分析工具，用于检查编译器难以觉察的bug，其设计目标是没有漏报2.准确率：不能包治百病，但配合testing、instrumenting，可以极大减少bug3.检查内容：64位兼容性自动变量生存周期检查数组越界检查类检查，包括缺少构造函数，变量在构造函数中是否初始化及其初始化顺......
  • 用户态多线程实现的基本原理
    本文参考了用户态非抢占式线程库实现一文以及GNUPth。前者是一种用户态线程库的简单实现，属于一个很好的demo，后者就是大家熟知的Pthread的用户态实现，比较完善。 Keywords:User-SpaceMultiThreading,Pth 所谓多线程，简单讲就是能够让几个不同的代码片段轮流执行。内核实现多线......
  • 【Unity3D】阴影原理及应用
    1阴影原理​光源照射到不透明物体上，会向该物体的后面投射阴影，如果阴影区域存在其他物体，这些物体不被光源照射的部分就需要渲染阴影。因此，我们可以将阴影的生成抽象出2个流程：物体投射阴影、物体接收阴影。1.1阴影相关开关​1）开启Light组件渲染阴影NoShadows......
  • k8s 深入篇———— 一些容器操作的原理[三]
    前言简单介绍一下一些容器的操作原理。正文dockerexec是怎么做到进入容器里的呢。比如说：这里有一个容器，我们可以exec进去:dockerexec-itb265/bin/sh我们为什么能看到和容器内部一样的场景呢？首先我们知道了为什么容器进程只能看到规定的namespace了，那么如果我们......
  • 通过 docker-compose 快速部署 Apache Ambari 保姆级教程
    目录一、概述二、前期准备1）部署docker2）部署docker-compose三、ApacheAmbari编排部署1）获取Ambari安装包2）yum源配置文件3）用户和库初始化sql文件4）启动脚本bootstrap.sh5）修改源码6）构建镜像Dockerfile7）配置hosts8）编排docker-compose.yaml9）开始部署10）检测五、通过ApacheAmb......
  • SpringBoot自动配置的原理
    以WebMvcAutoConfiguration自动配置的原理为例，SpringBoot内部对大量的第三方库或Spring内部库进行了默认配置，这些配置是否生效，取决于我们是否引入了对应库所需的依赖，如果有那么默认配置就会生效。如果引入springboot-starter-web那么对应的web配置就会自动配置。那么是如何自动配......
  • per-CPU变量的静态和动态分配原理
    per-CPU是2.6内核中引入的，访问per-CPU变量几乎不需要锁，每个处理器都在其自己的副本上工作。这些副本是如何生成的呢？本文尝试解答这个问题。静态per-CPU结构设计思路大体可以分为两个阶段：编译阶段和运行时阶段在编译阶段，实际上只生成了一个CPU原本。系统中所有per-CPU结构都放到了一......
  • kafka工作原理
    1.工作流程以及文件存储机制 kafka中的消息是以topic进行分类的，生产消费消息都是面向topic。 topic是逻辑上的概念，partition分区是物理上的概念，每个分区对应一个log文件，该log文件存储的就是producer生产的log数据。producer生产的数据会追加到文件末端。消费者组中的每个消费......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99