ViewMode类是在充分考虑生命周期前提下设计的用来存储和管理用户界面相关的数据。ViewModel类允许数据在配置更改时依旧存活，比如如屏幕旋转。
Android框架管理UI控制器的生命周期，比如activity和fragment。框架可能会决定销毁或重新创建UI控制器，以响应完全不受控制的某些用户操作或设备事件。
如果系统销毁或重新创建UI控制器，则存储在其中的所有瞬态UI相关数据都将丢失。例如，您的应用可能会在其中一个活动中包含用户列表。当针对配置更改重新创建活动时，新活动必须重新获取用户列表。对于简单的数据，活动可以使用该onSaveInstanceState()方法保存并在onCreate()从数据包中恢复其数据，但是这种方法仅适用于可以序列化，然后反序列化的少量数据，而不适用于大量数据，如用户列表或位图。
另一个问题是UI控制器经常需要进行异步调用，这可能需要一些时间才能返回。UI控制器需要管理这些调用，并确保系统在销毁后清理它们以避免潜在的内存泄漏。这种管理需要大量的维护，并且在为配置更改而重新创建对象的情况下，由于对象可能不得不重新发出已经做出的调用，所以浪费资源。
UI控制器（如activity和fragment）主要用于显示UI数据，对用户操作做出反应，或处理操作系统通信（如权限请求）。要求UI控制器也负责从数据库或网络加载数据，从而增加了该类的膨胀。为UI控制器分配过多的责任可能会导致一个类尝试单独处理应用程序的所有工作，而不是将工作委托给其他类。通过这种方式给UI控制器分配过多的责任也使测试变得更加困难。
将视图数据所有权从UI控制器逻辑中分离出来更简单，更高效。
1.实现一个ViewModel
架构组件为负责为UI准备数据的UI控制器提供ViewModel助手类。 ViewModel对象在配置更改期间会自动保留，以便它们保存的数据立即可用于下一个活动或片段实例。
例如，如果您需要在应用程序中显示用户列表，请确保分别获取或将用户列表保留为 ViewMode而不是活动或片段，如以下机智的示例代码所示：
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.
}
}
然后，您可以按如下方式访问活动列表：
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对象的 onCleared() 方法，以便清理资源。
注意：ViewModel 决不能引用
view，Lifecycle或任何可能持有activity context引用的类。
ViewModel对象被设计的比view或 LifecycleOwners的特定实例更具活力。这个设计也意味着你可以编写测试来更容易地覆盖ViewModel，因为它不知道view和 Lifecycle对象。 ViewModel 对象可以包含LifecycleObservers，比如 LiveData对象。但是， ViewModel对象绝不能观察对生命周期敏感的可观察对象的更改（如LiveData对象）。如果 ViewModel需要 Application上下文，例如找到一个系统服务，它可以扩展AndroidViewModel 类，并有一个构造函数接收Application构造函数，因为Application类继承Context
2. ViewModel的生命周期
ViewModel的范围覆盖了获取ViewModel的时候传递给 ViewModelProvider的Lifecycle。ViewModel一直存在直到Lifecycle 永久消失为止：如果是activity，直到它完成时，如果是fragment，直到它被分离时。
图1展示了一个activity在经历一个循环直到结束的各种生命周期状态。该图还显示了与activity生命周期关联的ViewModel的生命周期。这个特定的图表说明了一个活动的状态。相同的基本状态适用于片段的生命周期。
说明活动更改状态时ViewModel的生命周期。
通常首次请求ViewModel当系统调用acticity对象的onCreate()的方法。系统可能会在整个活动的整个生命周期中多次调用onCreate()，例如当设备屏幕旋转时。ViewModel一直存在，从第一次请求ViewModel，直到activity结束和销毁。
3. 在fragment之间共享数据
一个acticity中的两个或多个片断需要相互通信是很常见的。想象一下主 - 从结构的fragment这种常见情况，其中有一个片段用户从列表中选择一个条目，另一个片段显示所选条目的具体内容。这种情况从来都不是微不足道的，因为这两个片段都需要定义一些接口描述，而所有者activity必须将两者联系在一起。此外，这两个片段必须处理其他片段尚未创建或可见的场景。
这个常见的痛点可以通过使用ViewModel对象来解决。这些fragment可以在它们activity范围内共享一个 ViewMode来处理此通信，如以下示例代码所示：
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.
});
}
}
请注意，这两个片段使用getActivity()时得到的 ViewModelProvider。因此，这两个片段都会接收到相同的SharedViewModel实例，这个实例的作用域是活动（activity）的范围。
这种方法提供了以下好处：
- 这个活动不需要做任何事情，也不需要知道这个交流。
- 除
SharedViewModel合同之外，碎片不需要彼此了解。如果其中一个片段消失，另一个片断继续照常工作。 - 每个片段都有自己的生命周期，不受其他生命周期的影响。如果一个片段替换另一个片段，则UI继续工作而没有任何问题。
4.用ViewModel替换加载器（loader）
Loader类CursorLoader经常用来保持应用程序的UI中的数据与数据库同步。 ViewModel其他几个类来替换加载器。使用ViewModel分离你的UI控制器从数据加载操作，这意味着你有更少的强类之间的引用。
在使用加载程序的一种常见方法中，应用程序可以使用CursorLoader来观察数据库的内容。当数据库中的值发生更改时，加载器会自动触发重新加载数据并更新UI：
图2.使用加载器加载数据
ViewModel与 Room和 LiveData一起使用来替换加载器。ViewModel确保在设备配置改变时数据能保存下来。
当数据库发生变化时，Room会通知LiveData，而LiveData又会使用修改后的数据更新您的用户界面。
图3.使用ViewModel加载数据
这篇博客文章介绍了如何将ViewModel 结合LiveData来替换一个 AsyncTaskLoader。
随着你的数据变得越来越复杂，你可能会选择一个单独的类来加载数据。ViewModel目的是封装UI控制器的数据，以使数据在配置更改后不受影响。有关如何通过配置更改加载，保持和管理数据的信息，请参阅 保存UI状态。
在Android应用程序架构指南建议建立一个资料库类来处理这些功能。
网友评论