ViewModel类是用来存储和管理与UI相关的数据，在设计之初就考虑到生命周期的影响。ViewModel允许数据在屏幕旋转等配置变化后存活。
Note: 如何在Android项目中引入
ViewModel, 请参阅 adding components to your project.
Android framework管理UI控制器（如Activity和Fragment）的生命周期。 framework可能会决定销毁或重新创建UI控制器，以响应完全不受控制的某些用户操作或设备事件。
如果系统销毁或重新创建UI控制器，则存储在其中的所有临时的UI相关数据都将丢失。 举个例子，您的应用中的一个Activity可能包含用户列表。 当因配置更改重新创建Activity时，新Activity必须重新获取用户列表。 对于简单数据，活动可以使用onSaveInstanceState()方法并从onCreate()中的数据包中恢复其数据，但是此方法仅适用于可以序列化然后反序列化的少量数据，而不适用于潜在的大量数据,例如用户列表或位图。
另一个问题是UI控制器经常需要异步请求，需要一些时间才能获取结果。 UI控制器需要管理这些请求，确保在系统销毁自己时，清理这些请求以避免潜在的内存泄漏。 这种管理需要大量的维护代码，并且在因配置更改而重新创建UI控制器的时，可能不得不重新发出已经发出过的请求，这样会浪费许多资源。
UI控制器（如Activity和Fragment）主要用于显示UI数据，对用户操作做出响应，或处理与操作系统之间的通信（如权限请求）。 再让UI控制器负责从数据库或网络加载数据，会导致该类过度臃肿。 给UI控制器分配过多的工作，可能会导致一个类去单独处理应用程序的所有工作，而不是将工作委托给其他类。 给UI控制器分配过多的工作也使得测试工作变得更加困难。
将视图数据的所有权从UI控制器逻辑中分离出来，会让项目更简单，更高效。
实现ViewModel
Architecture Components为UI控制器提供了ViewModel助手类，以便给UI准备数据。ViewModel对象在配置更改期间会自动保留，以便它们保存的数据可以立即提供给新的Activity或Fragment实例。 例如，您如果需要在应用程序中显示用户列表，请确保将获取用户列表的工作让ViewModel去做，而不是Activity或Fragment，如以下示例代码所示：
public class MyViewModel extends ViewModel {
private MutableLiveData<List<User>> users;
public LiveData<List<User>> getUsers() {
if (users == null) {
users = new MutableLiveData<List<Users>>();
loadUsers();
}
return users;
}
private void loadUsers() {
// Do an asyncronous operation to fetch users.
}
}
然后，您可以在Activity中按如下方式访问用户列表：
public class MyActivity extends AppCompatActivity {
public void onCreate(Bundle savedInstanceState) {
// Create a ViewModel the first time the system calls an activity's onCreate() method.
// Re-created activities receive the same MyViewModel instance created by the first activity.
MyViewModel model = ViewModelProviders.of(this).get(MyViewModel.class);
model.getUsers().observe(this, users -> {
// update UI
});
}
}
如果重新创建Activity，它将接收由第一个Activity创建的那个MyViewModel实例。 当持有ViewModel的Activity被FINISHED之后，framework将调用ViewModel对象的onCleared()方法，以便清理资源。
Note:ViewModel绝不能持有任何View，生命周期或对Context有引用的类。
ViewModel的寿命和View、LifecycleOwners实例无关。 这样做也方便了您编写覆盖ViewModel的测试，因为它不用去考虑生命周期。 ViewModel对象可以包含LifecycleObservers，例如LiveData对象。 但是，ViewModel对象绝不能去观察有生命周期感知能力的Observer（如LiveData对象）。 如果ViewModel需要Context，例如获得一个系统服务，那么它可以扩展AndroidViewModel类，并在构造函数中有一个接收Application的构造函数，而Application是Context的子类。
ViewModel的生命周期
ViewModel生命长度是在获取ViewModel时传递给ViewModelProvider的对象的生命周期决定的。 ViewModel保留在内存中，直到说依赖的有生命周期的对象永久消失：在Activity的情况下，当它被FINISHED，而在Fragment的情况下，当它被DETACHED。
图1展示了一个活动在经历一个循环后的各种生命周期状态，然后结束。 该图还显示了相关活动生命周期旁边的ViewModel的生命周期。 这个特定的图表说明了一个活动的状态。 相同的基本状态适用于片段的生命周期。
图1
您通常在系统第一次调用Activity对象的onCreate()方法时初始化ViewModel。 系统可能会在Activity的整个生命周期内多次调用onCreate()，例如当设备屏幕旋转时。 ViewModel的生命周期从第一次请求ViewModel开始，直到Activity被FINISHED并销毁。
在Fragment之间共享数据
Activity中Fragment们需要相互通信是很常见的事情。 想象一下，常见的Master-Detail模式下，用户在Master Fragment的列表中选择一个项目，另一个Fragment显示所选项目的内容。 这实现起来并不太容易，因为这两个Fragment都需要定义一些接口，而它们的Activity必须将两者联系在一起。 此外，Fragment必须处理另一个Fragment尚未创建或可见的情况。
ViewModel可以解决这个常见的痛点。 Fragment可以通过一个在Activity范围内共享的ViewModel来处理彼此的通信，如以下示例代码所示：
public class SharedViewModel extends ViewModel {
private final MutableLiveData<Item> selected = new MutableLiveData<Item>();
public void select(Item item) {
selected.setValue(item);
}
public LiveData<Item> getSelected() {
return selected;
}
}
public class MasterFragment extends Fragment {
private SharedViewModel model;
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
model = ViewModelProviders.of(getActivity()).get(SharedViewModel.class);
itemSelector.setOnClickListener(item -> {
model.select(item);
});
}
}
public class DetailFragment extends Fragment {
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
SharedViewModel model = ViewModelProviders.of(getActivity()).get(SharedViewModel.class);
model.getSelected().observe(this, { item ->
// Update the UI.
});
}
}
请注意，在获取ViewModel时，两个Fragment都要使用getActivity()。这样，这两个Fragment会收到同一个SharedViewModel实例，该实例的作用域为Activity。
这样做有以下好处：
- 这个Activity不需要做任何事情，也不需要知道Fragment之间的交流。
- 除了SharedViewModel的接口之外，Fragment不需要了解彼此。 如果其中一个Fragment消失，另一个Fragment继续照常工作。
- 每个Fragment都有自己的生命周期，不受其他生命周期的影响。 一个Fragment替换成另一个Fragment，UI继续工作也没有任何问题。
用ViewModel替换Loader
像CursorLoader这样的Loader类经常被用来保持应用程序中UI数据与数据库同步。 您可以使用ViewModel和其他几个类来替换Loader。 使用ViewModel将UI控制器与数据加载操作分开，这意味着您在类之间的强引用减少了。
Loader常见的用处是观察数据库的内容。 当数据库中的值发生更改时，Loader会自动触发重新加载数据并更新UI：
图2
配合使用ViewModel、Room和LiveData来替换Loader。 ViewModel确保数据在设备配置更改后仍然存在。 当数据库发生变化时，Room会通知你的LiveData，而LiveData则用修改后的数据更新你的UI。
图3
这篇博客介绍了如何使用带有LiveData的ViewModel来替换AsyncTaskLoader。
随着你的数据变得越来越复杂，你可能会选择一个单独的类来加载数据。 ViewModel的目的是封装UI控制器的数据，以使数据在配置更改后不受影响。 有关如何在配置更改时加载，保持和管理数据的更多信息，请参阅Saving UI State。
Guide to Android App Architecture 建议构建一个存储库类来处理这些功能。
网友评论