翻译官方文档ViewModel

官方文档链接：https://developer.android.google.cn/topic/libraries/architecture/viewmodel.html

1.前言

LiveData虽然解决了数据变化的及时反馈，但由于是在组件中创建LiveData对象的，所以当组件生命周期结束，此对象便会释放，这将导致哪些问题呢?下面来讲一讲。

2.使用案例

ViewModel类被设计用来存储和管理界面相关的数据，所以屏幕旋转等配置更改前的数据可以被保存。像Activity和Fragment等应用组件由安卓系统管理它们的生命周期，基于一些用户行为或用户完全无法控制的设备事件来决定销毁或重建它们。

既然上述对象由操作系统销毁或重建，它们持有的任何数据都有可能丢失。例如，在Activity中显示用户数据的列表，当界面由于配置更改重建时，新的Activity需要重新获取这些数据。对于简单的数据，Activity能通过onSaveInstanceState()方法存储，再从onCreate()方法的Bundle参数中恢复数据，但是这种方法只适用于像界面状态这样的少量数据，不适用于像用户列表这样的大量数据。

另一个问题，这些UI Controller（Activity、Fragment等）经常需要进行一些异步调用，可能会消耗一些时间来返回结果。这就导致必须管理这些调用，当UI Controller销毁时清理它们，以避免潜在的内存泄漏。这需要大量的维护，并且在配置更改导致重建对象的情况下，会再次发出相同的调用，这是浪费资源的。

还有个重要情况，这些UI Controller已经需要响应用户操作和处理操作系统的通信。若还需手动处理自己的资源，会导致类膨胀；即，一个类试图自己处理整个应用的工作，而不是委派给其它类。这也导致测试更加困难。

将视图数据的持有从UI Controller的逻辑中分离出来会使结构更加简单和高效。Lifecycles提供了ViewModel类，用来协助UI Controller，负责给界面准备数据。当配置改变时，它会自动持有数据，这样能立刻提供有效的数据给新的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 async operation to fetch users
    }
}

Activity可以通过如下方法访问列表：

public class MyActivity extends AppCompatActivity {
    public void onCreate(Bundle savedInstanceState) {
        MyViewModel model = ViewModelProviders.of(this).get(MyViewModel.class);
        model.getUsers().observe(this, users -> {
            // update UI
        });
    }
}

如果MyActivity被重建了，它将会接收到之前MyActivity创建的MyViewModel实例。当持有的Activity正常结束时，系统调用ViewModel的onCleared()方法来释放资源。

因为ViewModel的生命周期比对应的Activity和Fragment实例要长，所以它不应该引用一个View或任何一个可能持有Activity上下文引用的类。如果ViewModel需要Application的上下文（例如，去找到系统服务），它可以继承AndroidViewModel类，并在构造函数中接收Application（因为Application类继承自Context类）。

3.在Fragment间共享数据

一个Activity中的两个或多个Fragment需要相互通讯是种常见现象。但这种场景却不简单，所有的Fragment需要定义一些描述接口，并且所属的Activity必须与它们绑定。此外，所有的Fragment都必须面对一种场景，那就是其它的Fragment还没有创建或不可见。

上面的痛点可以使用ViewModel对象来解决。假设通过Fragment实现master-detail场景，即用户在一个Fragment的列表中选择某一项，在另一个Fragment中展示选择项的内容。这些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 LifecycleFragment {
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        SharedViewModel model = ViewModelProviders.of(getActivity()).get(SharedViewModel.class);
        model.getSelected().observe(this, { item ->
           // update UI
        });
    }
}

所有的Fragment在获取ViewModelProvider对象时，使用getActivity()方法。这意味着它们将会接收到相同的SharedViewModel实例，即作用域为Activity。

这样做的好处有：

Activity不需要做任何事情，或者知道关于此次通信的任何事情。
除了SharedViewModel类，Fragment不需要知道彼此相关的细节。如果其中一个Fragment消失了，其它的仍保持正常工作。
每个Fragment都有自己的生命周期，不会受到其它的生命周期的影响。实际上，界面中一个Fragment替换另一个，对界面工作不会有任何影响。

4.ViewModel的生命周期

ViewModel对象的作用域取决于，通过ViewModelProvider获取ViewModel对象时，传入的Lifecycle的生命周期范围。它将一直呆在内存中直到Lifecycle的生命周期永久地结束了—如果是Activity，当它finished；如果是Fragment，当它detached。

Lifecycle.png

5.ViewModel与SavedInstanceState区别

当配置更改后，ViewModel提供了一种方便的途径恢复数据，但它不支持持久化。若应用被操作系统killed，将丢失数据。这时，可以使用系统早就提供的另一套机制，具体可以看这篇文章。

例如，用户将应用放到后台，几小时后再切换回前台，进程那时将被killed，并且安卓系统将从保存的状态中恢复Activity。此过程中，开发者基本不需要做任何事情，因为所有的系统组件（View，Activity，Fragment）使用saved instance state机制保存它们的状态。可以在onSaveInstanceState()回调方法中，给参数Bundle添加自定义数据。

通过onSaveInstanceState()方法存储的数据将保持在系统进程内存中，但安卓系统只允许存储很少的数据，所以这不是保存应用实际数据的好地方。对于不能通过UI组件轻松地展示出来的东西需谨慎使用。

例如，如果有一个展示某国家信息的用户界面，不应该将Country对象放入saved instance state，应该将countryId放入存储的状态（除非已经被View或Fragment的arguments存储）。实际对象应该保存在数据库，并让ViewModel能通过保存的countryId检索到。

6.总结

到此，AAC最常用的功能基本介绍完了。至于Room Persistence Library和Paging Library，前者有大量可替代的库，而后者不太稳定，所以有时间再详细介绍。由于现在AAC还没有出稳定版，大家可以多关注官网发布的更新进度，有问题也可以在这里反馈。