幸存的配置更改机制如何工作？

Question

我有三个类似的关于配置更改的问题。我知道在配置更改时保留对象的三种方法，但我不知道它们是如何工作的。

1. 覆盖onSaveInstanceState。我知道它将数据放在包中。但它如何在配置更改中幸存下来？真正的捆绑是什么？它属于活动吗？我们的应用程序中只有一个捆绑包吗？ （我知道我们可以制作不同的实例，但是当我们使用putExtra 或onSaveInstanceState 或任何其他方法放置数据时，它们会去同一个地方吗？）

2. 使用onRetainNonConfigurationInstance() 和getLastNonConfigurationInstance()。这用于在配置更改时保留viewModelStore。那么它是如何工作的以及将数据放在哪里？（我知道贬值）

3. Retained(Holder) 片段和片段中的setRatinInstance() 方法。同样的问题（我认为活动只是为此使用onRetainNonConfigurationInstance()，如果我错了，请纠正我）

我为此搜索了网络和 StackOverflow，但找不到任何东西。我也尝试过查看实际代码，但没有运气！
因为这些问题是相关的，所以我想我把它们都放在一个问题上。希望没事。

Answer 1

覆盖 onSaveInstanceState。我知道它将数据放在包中。但它如何在配置更改中幸存下来？真正的捆绑是什么？它属于活动吗？我们的应用程序中只有一个捆绑包吗？ （我知道我们可以创建不同的实例，但是当我们使用 putExtra 或 onSaveInstanceState 或任何其他方法放置数据时，它们会去同一个地方吗？）

这并不是真正的“配置更改保留”，而是“保存在进程级别的持久性”，然后重新用于配置更改。我不认为它“保留”的原因是因为对象被打包为 Parcelable，然后在恢复时创建一个副本。

不管怎样the ActivityRecord has a bundle，每个任务栈都有自己的ActivityRecords，当进程死亡发生时，任务栈由系统保存和恢复。这种机制恰好“也处理配置更改”。

Intent.putExtra 的工作原理非常相似，是的。

使用 onRetainNonConfigurationInstance() 和 getLastNonConfigurationInstance()。这用于在配置更改时保留 viewModelStore。那么它是如何工作的以及将数据放在哪里？（我知道贬值）

与onSaveInstanceState 不同，这实际上是一个操作系统级回调，仅用于在配置更改时保留对象。曾经有onRetainCustomNonConfigurationInstance/getLastCustomNonConfigurationInstance，但它已被弃用，取而代之的是 ViewModel，因为 ViewModel 旨在成为跨配置更改保留的“唯一标准”方式。不过，在内部，它只是 viewModelStore（这是一张地图）中的 onRetainNonConfigurationInstance。

Retained(Holder) 片段中的片段和 setRetainInstance() 方法。同样的问题（我认为活动只是为此使用了 onRetainNonConfigurationInstance()，如果我错了，请纠正我）

是的，但不幸的是，最新的 Jetpack Fragments 版本也弃用了这一点（为了简化 Fragment 的交互及其生命周期）。片段管理器作为非配置保留，保留的片段与它一起保留，使用FragmentActivity的onRetainNonConfigurationInstance()（我想现在它被称为FragmentManagerViewModel）。

非配置实例保存在the ActivityClientRecord 中，ActivityStack 不会保留这些实例。

希望涵盖的内容足够多。