（八）ViewModel

概念

• ViewModel类旨在以生命周期意识的方式存储和管理UI相关数据。

实际使用

• ViewModel类允许数据在配置更改（例如屏幕旋转）后继续存在。

背景

• Android框架管理UI控制器的生命周期，例如Activities 和Fragments。
• 框架可以决定销毁或重新创建UI控制器以响应完全不受您控制的某些用户动作或设备事件。

我们的应用目前存在的问题

• 如果系统销毁或重新创建UI控制器，则存储在其中的任何瞬态UI相关数据都将丢失。
  例如，您的应用可能会在其中一项活动中包含用户列表。 为配置更改重新创建活动时，新活动必须重新获取用户列表。 对于简单数据，活动可以使用onSaveInstanceState（）方法并从onCreate（）中的包中恢复其数据，但此方法仅适用于可以序列化然后反序列化的少量数据，而不适用于潜在的大量数据 像用户列表或位图。
• 另一个问题是UI控制器经常需要进行可能需要一些时间才能返回的异步调用（内存泄露）。
  UI控制器需要管理这些调用并确保系统在销毁后清理它们以避免潜在的内存泄漏。 此管理需要大量维护，并且在为配置更改重新创建对象的情况下，由于对象可能必须重新发出已经进行的调用，因此浪费资源。
• UI控制器更加膨胀，UI控制器分配过多的责任也会使测试变得更加困难。
  诸如Activities和Fragments之类的UI控制器主要用于显示UI数据，对用户操作作出反应或处理操作系统通信，例如许可请求。 要求UI控制器也负责从数据库或网络加载数据，这会给类更加膨胀。 为UI控制器分配过多的责任可能导致单个类尝试自己处理应用程序的所有工作，而不是将工作委托给其他类。 以这种方式为UI控制器分配过多的责任也会使测试变得更加困难。

总结

将视图数据与UI控制器逻辑分离起来更容易，更有效。

一、实现ViewModel

Architecture Components为UI控制器提供ViewModel辅助类，该控制器负责为UI准备数据。

ViewModel优点

• ViewModel对象在配置更改期间自动保留，以便它们保存的数据可立即用于下一个活动或片段。
  例如，如果您需要在应用程序中显示用户列表，请确保分配责任以获取并将用户列表保留为ViewModel，而不是活动或片段，如以下示例代码所示：

public class MyViewModel extends ViewModel {
    private MutableLiveData<List<User>> users;
    public LiveData<List<User>> getUsers() {
        if (users == null) {
            users = new MutableLiveData<List<User>>();
            loadUsers();
        }
        return users;
    }

    private void loadUsers() {
        // Do an asynchronous 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
        });
    }
}

如果重新创建活动，它将接收由第一个活动创建的相同MyViewModel实例。 当所有者活动完成时，框架调用ViewModel对象的onCleared（）方法，以便它可以清理资源。

警告：ViewModel绝不能引用视图，生命周期或任何可能包含对活动上下文的引用的类。

ViewModel对象旨在活过视图或LifecycleOwners的特定实例。 此设计还意味着您可以编写测试以更轻松地覆盖ViewModel，因为它不了解视图和Lifecycle对象。 ViewModel对象可以包含LifecycleObservers，例如LiveData对象。 但是，ViewModel对象绝不能观察到生命周期感知的可观察对象（例如LiveData对象）的更改。 如果ViewModel需要Application上下文，例如查找系统服务，它可以扩展AndroidViewModel类并具有在构造函数中接收Application的构造函数，因为Application类扩展了Context。

二、ViewModel的生命周期

获取ViewModel时，ViewModel对象的范围限定为传递给ViewModelProvider的生命周期。
ViewModel保留在内存中，直到生命周期范围永久消失：在活动的情况下，当它完成时，在片段的情况下，当它被分离时。
图1显示了活动经历轮换然后结束时的各种生命周期状态。 该图还显示了关联活动生命周期旁边的ViewModel的生命周期。 此特定图表说明了活动的状态。 相同的基本状态适用于片段的生命周期。

viewmodel-lifecycle.png

调用时机

您通常在系统第一次调用活动对象的onCreate（）方法时请求ViewModel。 系统可以在活动的整个生命周期中多次调用onCreate（），例如在旋转设备屏幕时。 ViewModel从您第一次请求ViewModel到活动完成并销毁之时就存在。

三、在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.
        });
    }
}

请注意，两个片段在获取ViewModelProvider时都使用getActivity（）。 因此，两个片段都接收相同的SharedViewModel实例，该实例的范围限定为活动。
这种方法具有以下优点：

• Activity不需要做任何事情，也不需要了解这种沟通。
• 除了SharedViewModel契约之外，Fragment不需要彼此了解。 如果其中一个碎片消失，另一个碎片继续照常工作。
• 每个Fragment都有自己的生命周期，不受另一个Fragment的生命周期的影响。 如果一个Fragment替换另一个Fragment，则UI继续工作而没有任何问题。

四、用ViewModel替换加载器

像CursorLoader这样的加载器类经常用于使应用程序UI中的数据与数据库保持同步。 您可以使用ViewModel和其他一些类来替换加载器。
使用ViewModel将UI控制器与数据加载操作分开，这意味着类之间的强引用较少。
在使用加载器的一种常见方法中，应用程序可能使用CursorLoader来观察数据库的内容。 当数据库中的值发生更改时，加载程序会自动触发重新加载数据并更新UI：

图2.使用加载器加载数据

ViewModel与Room和LiveData一起使用以替换加载器。 ViewModel可确保数据在设备配置更改后仍然存在。 当数据库发生变化时，会通知您的LiveData，然后LiveData会使用修改后的数据更新您的UI。

图3.使用ViewModel加载数据