架构组件 ViewModel vs. savedInstanceState 包

Question

试图了解使用 ViewModel 保留 Activity 或 Fragment 的某些状态并使用 savedInstanceState 包保存它们有什么区别。

印象中，在配置更改等情况下，当 os 销毁活动/片段时，ViewModel 实例会保持活动状态，以便在 os 重新创建活动/片段时，可以从仍然有效的 ViewModel 实例中获取数据。

它是否适用于最小化应用程序并重新打开它？

做了一些测试，似乎最小化应用程序并重新打开应用程序，操作系统将使用 onCreate() 中的 stavedInstanceState 包重新创建活动/片段，而不是 null（调用 onSaveInstanceStae() 时保存的内容）。 但是 ViewModel 已被清除，因此创建了一个没有以前数据的新实例。

这是否意味着虽然在这种情况下操作系统可以检索保存的实例状态并传递给活动/片段的 onCreate()，但是 ViewModel 必须是一个没有先前实例数据的新实例，或者 viewModel 需要做一些额外的步骤为了跨实例存储/恢复数据？

Answer 1

如果有人仍然想了解 onSavedState 与 ViewModel 之间的区别，这里是详细解释：

1. onSavedInstanceState ： onSavedInstance 的主要用途不是处理方向更改，而是提供一种机制，在 Android 系统销毁应用程序/活动时检索数据。 当应用程序处于后台并且 Android 系统决定终止它时的示例情况，因为它需要一些其他高优先级进程的内存，然后在这种情况下，在活动被销毁之前 onSavedInstanceState 将被调用。

2. onSavedInstanceState 只存储 Parcelable 数据，它提供提示以在 Activity 重新启动时为用户恢复状态。 它将数据保存在作为单独进程的系统服务器中。

3. onSavedInstanceState 有数据限制。 只能保存少量 Parcelable 数据。

而对于 ViewModel

1. ViewModel 对象是应用程序进程内存的一部分，因此它能够承受配置更改。 一旦进程终止，ViewModel 就会消失并且所有保存的状态都将丢失。 因此，当活动重新启动时，ViewModel 中没有任何内容。

2. 它用作重物的缓存。

3. ViewModel 中没有限制。

重要提示：永远记住ViewModel 和 SavedState 一起工作。 它们不是彼此的替代品或替代品。

Answer 2

可以在这篇博文中找到一个很好的解释（以及您问题的解决方案）。 TLDR：视图模型托管在持久片段中，该片段与托管活动一起重新创建。

Answer 3

来自：Kristin Marsicano 书籍“Android 编程：大书呆子牧场指南，第 4 版”。 ：

ViewModel 与保存的实例状态

虽然保存的实例状态存储了跨进程死亡的活动记录，但它还存储了跨配置更改的活动记录。 首次启动活动时，保存的实例状态包为空。 当您旋转设备时，操作系统会在您的活动上调用onSaveInstanceState(Bundle) 。 然后，操作系统将您藏在包中的数据传递给onCreate(Bundle?) 。

当您使用ViewModel为活动编排动态数据时，它真的很出色

ViewModel使跨配置更改继续下载操作变得简单。 它还提供了一种简单的方法来保存在配置更改期间加载到内存中的数据开销很大。 而且，如您所见，一旦用户完成活动， ViewModel就会自动清理。

ViewModel不会在进程死亡场景中发光，因为它会与进程及其中的所有内容一起从内存中擦除。 这是保存的实例状态占据中心位置的地方。 但是保存的实例状态有其自身的局限性。 由于保存的实例状态被序列化到磁盘，你应该避免隐藏任何大型或复杂的对象。

Lifecycle-viewmodel-savedstate是一个刚刚发布的新库，它允许ViewModel在进程死亡时保存它们的状态。 这应该可以减轻将ViewModel与活动中保存的实例状态一起使用的一些困难。

使用保存的实例状态来存储重新创建 UI 状态所需的最少信息（例如，当前问题索引）。 使用ViewModel缓存在配置更改时在内存中填充 UI 所需的丰富数据集，以便快速轻松地访问。

在进程死亡后重新创建活动时，使用保存的实例状态信息来设置ViewModel ，就好像ViewModel和活动从未被销毁一样。

在撰写本文时，没有简单的方法可以确定是否在进程死亡与配置更改后重新创建活动。 为什么这很重要？ ViewModel在配置更改期间保留在内存中。 因此，如果您在配置更改后使用保存的实例状态数据来更新ViewModel ，那么您正在使您的应用程序执行不必要的工作。 如果工作导致用户等待或不必要地使用他们的资源（如电池），则这种冗余工作是有问题的。

解决此问题的一种方法是使您的ViewModel更智能一些。 当设置ViewModel值可能会导致更多工作时，请先检查数据是否新鲜，然后再进行拉入和更新其余数据的工作。