问体系结构组件ViewModel与savedInstanceState包

EN

在这个博客上可以找到一个很好的解释(以及问题的解决方案)。TLDR:视图模型托管在一个持久化片段中，该片段与宿主活动一起重新创建。

如果有人还想了解onSavedState和ViewModel之间的区别，下面是详细的解释：

1. onSavedInstanceState : onSavedInstance的主要用途不是处理方向更改，而是在应用程序/活动被安卓系统破坏时提供一种检索数据的机制。例如，当应用程序处于后台，而Android系统决定关闭它，因为它需要一些其他高优先级进程的内存，那么在这种情况下，在活动被销毁之前，onSavedInstanceState将被调用。
2. onSavedInstanceState只存储Parcelable数据，在活动重新启动时为用户提供恢复状态的提示。它将数据保存在系统服务器中，这是一个单独的进程。
3. onSavedInstanceState有数据限制。只能保存少量的可解析数据。

时间为ViewModel

1. ViewModel对象是应用程序进程内存的一部分，因此它能够承受配置更改。一旦进程死亡，ViewModel就会消失，所有保存的状态都会丢失。因此，当活动重新启动时，ViewModel中没有任何内容。
2. 它用作重型对象的缓存。
3. 在ViewModel中没有任何限制。

重要：永远记住、ViewModel和SavedState一起工作。他们不是替代者，也不是替代者。

​

​

出发地:克里斯汀·马西卡诺( Kristin Marsicano)的书“Android编程:大尼尔德牧场指南”(第4版)：

ViewModel与保存的实例状态

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

当您使用ViewModel来编排活动的动态数据时，它确实会发光。

ViewModel使跨配置更改的下载操作变得简单。它还提供了一种简单的方法，通过配置更改将数据保存在内存中的开销很高。而且，正如您所看到的，一旦用户完成了活动，ViewModel就会自动清理。

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

lifecycle-viewmodel-savedstate是刚刚发布的一个新库，它允许ViewModels跨进程死亡保存它们的状态。这将减轻将ViewModels与保存的实例状态一起从您的活动中使用的一些困难。

使用保存的实例状态来存储重新创建UI状态所需的最小信息量(例如，当前的问题索引)。使用ViewModel缓存用于跨配置更改在内存中填充UI所需的丰富数据集，以便于快速访问。

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

在本文撰写之时，没有一种简单的方法可以确定某个活动是在进程死亡之后重新创建，还是在配置更改之后重新创建。这有什么关系？在配置更改期间，ViewModel将保留在内存中。因此，如果在配置更改后使用保存的实例状态数据来更新ViewModel，则会使应用程序做不必要的工作。如果该工作导致用户不必要地等待或使用他们的资源(如电池)，则此冗余工作是有问题的。

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