深入了解架构组件之ViewModel，android多线程面试题

1、数据持久化

我们知道在屏幕旋转的 时候 会经历 activity 的销毁与重新创建，这里就涉及到数据保存的问题，显然重新请求或加载数据是不友好的。在 ViewModel 出现之前我们可以用 activity 的onSaveInstanceState()机制保存和恢复数据，但缺点很明显，onSaveInstanceState只适合保存少量的可以被序列化、反序列化的数据，假如我们需要保存是一个比较大的 bitmap list ，这种机制明显不合适。

由于 ViewModel 的特殊设计，可以解决此痛点。

先来看下 ViewModel 生命周期图：

由图可知，ViewModel 生命周期是贯穿整个 activity 生命周期，包括 Activity 因旋转造成的重创建，直到 Activity 真正意义上销毁后才会结束。既然如此，用来存放数据再好不过了。

2、异步回调问题

通常我们 app 需要频繁异步请求数据，比如调接口请求服务器数据。当然这些请求的回调都是相当耗时的，之前我们在 Activity 或 fragment里接收这些回调。所以不得不考虑潜在的内存泄漏情况，比如 Activity 被销毁后接口请求才返回。处理这些问题，会给我们增添好多复杂的工作。

但现在我们利用 ViewModel 处理数据回调，可以完美的解决此痛点。

3、分担 UI controller负担

从最早的 MVC 到目前流行的 MVP、MVVM，目的无非是 明确职责，分离 UI controller 负担。

UI controller 比如 Activity 、Fragment 是设计用来渲染展示数据、响应用户行为、处理系统的某些交互。如果再要求他去负责加载网络或数据库数据，会让其显得臃肿和难以管理。所以为了简洁、清爽、丝滑，我们可以分离出数据操作的职责给 ViewModel。

4、Fragments 间共享数据

（可以先看下后面的用法介绍）

比如在一个 Activity 里有多个fragment，这fragment 之间需要做某些交互。我之前的做法是接口回调，需要统一在 Activity 里管理，并且不可避免的 fragment 之间还得互相持有对方的引用。仔细想想就知道这是很翔的一件事，耦合度高不说，还需要大量的容错判断（比如对方的 fragment 是否还活着）。

那么用 ViewModel 是怎么样的呢（官网例子）：

(activity 与其内部的 fragment 可以共用一个ViewModel)

public class SharedViewModel extends ViewModel {

private final MutableLiveData selected = new MutableLiveData();

public void select(Item item) {

selected.setValue(item);

}

public LiveData getSelected() {

return selected;

}

}

public class MasterFragment extends Fragment {

private SharedViewModel model;

public void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

model = ViewM