前言

我曾经在一篇介绍 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 展开的：

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

registry 是一个 SaveableStateRegistry 。

恢复 key 的数据

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

通过 registry.consumeRestored 查找 key 获取 Saveable，
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 做的事情类似：

基于 key 恢复 bundle 数据，
基于 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 类型的关系，整理如下图

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 查找数据。查找返回的是一个 List 。因为存储时可能同一个 key 以此存储了多个值，所以当恢复数据时，以此恢复 List[0] 的数据。顺便吐槽一下 consumeRestored 这个名字，将 restore 这个 private 成员信息暴露给了外面，有些莫名其妙。

什么情况下同一个 key 会存储多个值？首先当开发者手动设置 key 的时候，无法保证 key 是否去重，即使使用默认的 Compoiler 生成的 key，也只有同 Group 下的 key 会去重。所以放眼整个运行时很可能存出现同一个 key 存储多个值的情况。

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 中的其它值不被移除

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 原理分析

前言