之前工作用了很久MVP架构了，虽然很好的解决了M层与V层的耦合关系，但巨多的接口，难以复用、难以单测的问题一直萦绕心头，久久不能平复~~~，于是我将目光转向了MVVM。
MVVM与MVP相比最大的区别就是用ViewModel（后文简称VM）代替了原来的P层，这里的VM就是ViewModel。一句话概括它的特点---对数据状态的持有和维护。换言之，它将原来P层关于数据的逻辑运算与处理统一放到了VM中，而剩余的V层的操作建议使用Databinding，从而形成最为简洁高效的MVVM架构。说到这呢，推荐一篇旧文DataBinding，再学不会你砍我（系兄弟就砍偶系列?）。
回到VM的特点---对数据状态的持有和维护。为什么需要做这些呢？事实上就是为了解决下面两个开发中常见的问题。
- Activity配置更改重建时(比如屏幕旋转)保留数据
- UI组件(Activity与Fragment、Fragment与Fragment)间实现数据共享。
对于第一条不用VM的情况下只能通过onSaveInstanceState保存数据，当activity重建后再通过onCreate或onRestoreInstanceState方法的bundle中取出，但如果数据量较大，数据的序列化和反序列化将产生一定的性能开销。
对于第二条如果不用VM，各个UI组件都要持有共享数据的引用，这会带来两个麻烦，第一，如果新增了共享数据，各个UI组件需要再次声明并初始化新增的共享数据；第二，某个UI组件对共享数据修改，无法直接通知其他UI组件，需手动实现观察者模式。而VM结合LiveData就可以很轻松的实现这一点。
LiveData作为数据变化的驱动器，VM借助它可以写出十分简洁的MVVM代码。
接下来我们来看一下VM到底是如何实现上述需求的，而事实上核心可以转化为下面两个问题。
问题
- VM是如何解决Activity与Fragment、Fragment之间数据共享的问题？
- VM是如何在Activity发生旋转时保留数据的？不是也走onDestroy了吗？
ViewModel是什么？
回答上面问题之前我们要先了解一下VM到底是个啥。
public abstract class ViewModel {
protected void onCleared() {
}
}
就是个抽象类甚至连抽象方法都没有，简单的令人发指。onCleared方法提供了释放VM中资源的一个机会，在Activity/Fragment的onDestroy生命周期中被调用。类库内部提供了一个实现类AndroidViewModel。
public class AndroidViewModel extends ViewModel {
private Application mApplication;
public AndroidViewModel(@NonNull Application application) {
mApplication = application;
}
public <T extends Application> T getApplication() {
return (T) mApplication;
}
}
AndroidViewModel内持有Application的引用，所以通常可以做一些全生命周期的工作。为什么不能持有一个Activity呢？这与ViewModel的生命周期有关，我们稍后解释。
创建ViewModel
接下来看看VM的创建，通常我们是这样创建一个VM的。
val viewModel = ViewModelProviders.of(this).get(AndroidViewModel::class.java)
这里的this可以是FragmentActivity或Fragment，他们都是support-v4包中控件，为的是向下兼容。
我们以FragmentActivity为例看看of方法做了什么。
### 1.1 ViewModelProviders
public static ViewModelProvider of(@NonNull FragmentActivity activity) {
return of(activity, null);
}
public static ViewModelProvider of(@NonNull FragmentActivity activity,
@Nullable Factory factory) {
Application application = checkApplication(activity);
if (factory == null) {
factory = ViewModelProvider.AndroidViewModelFactory.getInstance(application);
}
//这里用的工厂模式，vm的创建交由工厂完成，默认使用AndroidViewModelFactory
return new ViewModelProvider(ViewModelStores.of(activity), factory);
}
这两个方法的返回值都是ViewModelProvider，ViewModelProviders是操作ViewModelProvider的工具类，内部都是获取ViewModelProvider的静态方法，而真正的VM的业务在ViewModelProvider中。
同理ViewModelStores和ViewModelStore的关系亦是如此。既然要保留VM的数据，必然要有个存储单元。ViewModelStore就是这个存储单元，因为一个Activity中可能有多个VM，所以需要一个Map来维护关系表，key为VM的名字，value为VM对象，简单的令人发指。
public class ViewModelStore {
private final HashMap<String, ViewModel> mMap = new HashMap<>();
final void put(String key, ViewModel viewModel) {
ViewModel oldViewModel = mMap.put(key, viewModel);
if (oldViewModel != null) {
oldViewModel.onCleared();
}
}
final ViewModel get(String key) {
return mMap.get(key);
}
public final void clear() {
for (ViewModel vm : mMap.values()) {
vm.onCleared();
}
mMap.clear();
}
}
ViewModelStores仅负责提供工具方法创建ViewModelStore。
### 1.2
public class ViewModelStores {
private ViewModelStores() {
}
public static ViewModelStore of(@NonNull FragmentActivity activity) {
if (activity instanceof ViewModelStoreOwner) {
return ((ViewModelStoreOwner) activity).getViewModelStore();
}
return holderFragmentFor(activity).getViewModelStore();
}
...
}
ViewModelStoreOwner又是什么鬼？它是抽象了一个获取ViewModelStore的接口。常见的实现类有Fragment/FragmentActivity，这也不难理解，因为要想在配置改变时保留数据，首先得要将数据存储起来。
public interface ViewModelStoreOwner {
ViewModelStore getViewModelStore();
}
感觉这时需要一张类图了，不然你是不是想砍死我？
事实上目前提到的这几个类已经几乎涵盖了viewmodel库中所有的类。
我们回到1.1中创建ViewModelProvider的代码。
return new ViewModelProvider(ViewModelStores.of(activity), factory);
我们将activity中的VM存储单元和VM的创建工厂(AndroidViewModelFactory)传入得到一个ViewModelProvider对象，最终通过其get方法得到VM。
public <T extends ViewModel> T get(@NonNull Class<T> modelClass) {
String canonicalName = modelClass.getCanonicalName();
if (canonicalName == null) {
throw new IllegalArgumentException("Local and anonymous classes can not be ViewModels");
}
return get(DEFAULT_KEY + ":" + canonicalName, modelClass);
}
以Default_Key作为前缀加上VM的完整类名为key，获取VM对象。
public <T extends ViewModel> T get(@NonNull String key, @NonNull Class<T> modelClass) {
ViewModel viewModel = mViewModelStore.get(key);
//先看ViewModelStore中是否存在，如果存了就直接返回
if (modelClass.isInstance(viewModel)) {
return (T) viewModel;
}
...
//如果不存在，创建一个新的VM并存入ViewModelStore
viewModel = mFactory.create(modelClass);
mViewModelStore.put(key, viewModel);
return (T) viewModel;
}
默认情况下mFactory为AndroidViewModelFactory，来看下它是如何创建VM的。
public static class AndroidViewModelFactory extends ViewModelProvider.NewInstanceFactory {
...
public <T extends ViewModel> T create(@NonNull Class<T> modelClass) {
if (AndroidViewModel.class.isAssignableFrom(modelClass)) {
try {
//通过反射创建AndroidViewModel对象
return modelClass.getConstructor(Application.class).newInstance(mApplication);
} catch (NoSuchMethodException e) {
...
}
}
return super.create(modelClass);
}
}
至此VM的创建我们就讲完了，可以总结一下：
- ViewModelStore是存储VM的数据单元，存储结构为Map，Fragment/FragmentActivity持有其引用。
- ViewModelProvider通过get方法创建一个VM，创建之前会先检查ViewModelStore中是否存在，若不存在则通过反射创建一个VM。
UI组件间数据共享
讲到这我们回过头来看看开篇提的第一个问题：Activity与Fragment，Fragment之间是如何共享数据的。
数据要实现共享最简单的方式就是大家都读取一份数据源。
我们来看看数据源ViewModelStore具体是在哪里创建的。
上面讲的代码片段1.2可知，有两条路径创建。
public static ViewModelStore of(@NonNull FragmentActivity activity) {
if (activity instanceof ViewModelStoreOwner) { ①
return ((ViewModelStoreOwner) activity).getViewModelStore();
}
return holderFragmentFor(activity).getViewModelStore();②
}
①如果FragmentActivity是ViewModelStoreOwner类型通过activity的getViewModelStore方法创建。
②否则通过一个HolderFragment来创建。
先来看①
### FragmentActivity
private ViewModelStore mViewModelStore;
public ViewModelStore getViewModelStore() {
...
if (mViewModelStore == null) {
mViewModelStore = new ViewModelStore();
}
return mViewModelStore;
}
简单的令人发ck，既然是成员变量那每次调用必定返回同一个VM，只要保证调用ViewModelProviders.of(activity).get(AndroidViewModel::class.java)传递的activity是同一个对象。
再来看②，整体思路是添加一个不可见的HolderFragment到当前Activity中，再将数据源记录在这个fragment中。
### HolderFragment extends Fragment implements ViewModelStoreOwner
private ViewModelStore mViewModelStore = new ViewModelStore();
public static HolderFragment holderFragmentFor(FragmentActivity activity) {
return sHolderFragmentManager.holderFragmentFor(activity);
}
HolderFragment holderFragmentFor(FragmentActivity activity) {
FragmentManager fm = activity.getSupportFragmentManager();
//先查一下当前有没有这个HolderFragment
HolderFragment holder = findHolderFragment(fm);
if (holder != null) {
return holder;
}
...
//没有就创建一个
holder = createHolderFragment(fm);
...
return holder;
}
private static HolderFragment createHolderFragment(FragmentManager fragmentManager) {
//创建一个HolderFragment、打上tag，再添加到当前界面。
HolderFragment holder = new HolderFragment();
fragmentManager.beginTransaction().add(holder, HOLDER_TAG).commitAllowingStateLoss();
return holder;
}
之所以不可见，是因为这个HolderFragment并未复写onCreateView。这么做的原因是早期的版本想利用Fragment的setRetainInstance()API接口，来实现当Activity因配置发生改变时保留这个不可见的Fragment，生命周期只走onDetach和onAttach。既然没有被重建，那么它持有的数据自然就会被保留，其他主动退出的情况走到onDestroy会清空数据。
### HolderFragment
public HolderFragment() {
setRetainInstance(true);
}
//被销毁时清除数据源
public void onDestroy() {
super.onDestroy();
mViewModelStore.clear();
}
那么在实际使用中会走哪条路径呢？我们反观源码FragmentActivity是实现了ViewModelStoreOwner接口的，那此处代码不是肯定走①吗？②是不是走错片场了？此时我感觉我的智商受到了侮辱。
原来在appcompat-v7版本在27.1.0之前FragmentActivity并没有实现ViewModelStoreOwner接口，也就是统一用HolderFragment实现。google大大可能是觉得这个HolderFragment有点太骚操作了就让后续版本的FragmentActivity直接支持了VM存储。因为添加的HolderFragment也是有维护成本的，且上层可以通过FragmentManager获取到它，然后对它进行其他骚操作，想想都刺激。。。
上面我们分析了创建VM时传入FragmentActivity的情况，那传入Fragment的情况呢？实际上跟FragmentActivity几乎一样，在Fragment中也有一个mViewModelStore成员变量，注意这里哦，非常关键。也就是说如果我们通过下面的代码创建的是两个VM，是不能共享数据的。
### MainActivity
override fun onCreate(savedInstanceState: Bundle?) {
//传递activity
val vm = ViewModelProviders.of(this).get(AndroidViewModel::class.java)
}
### TestFragment
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
//传递fragment
val vm = ViewModelProviders.of(this).get(AndroidViewModel::class.java)
}
正确的写法应该是二者在of方法中传入相同的对象
### TestFragment.onCreate(savedInstanceState: Bundle?)
//通过getActivity方法取得Fragment所在的Activity
val vm = activity?.run {
//run函数 这里的this指代activity
ViewModelProviders.of(this)[AndroidViewModel::class.java]
}
Fragment之间同理，如果Fragment间同层级，可以统一通过Activity或共同的parentFragment(如果有)获取VM；如果有嵌套关系，可以使用parentFragment对象获取VM。
Activity配置发生变化时数据保持
其实在上面的内容中已经讲了HolderFragment是如何保留数据的，就是利用Fragment的setRetainInstance()API接口完成的。
google为了优化这点在新版本里直接让FragmentActivity支持了数据的保持，官方的配图很好的阐释了VM在Activity因配置变化销毁重建时的生命周期。
下面我们来分析一下是如何做到的，先看onDestroy的销毁逻辑。
### FragmentActivity
protected void onDestroy() {
super.onDestroy();
...
if (mViewModelStore != null && !mRetaining) {
mViewModelStore.clear();
}
...
}
mRetaining为true时将会保留VM数据，那它何时为true呢？
### FragmentActivity
public final Object onRetainNonConfigurationInstance() {
if (mStopped) {
//方法内部会将mRetaining设置为true
doReallyStop(true);
}
...
NonConfigurationInstances nci = new NonConfigurationInstances();
nci.custom = custom;
//保存VM数据
nci.viewModelStore = mViewModelStore;
nci.fragments = fragments;
return nci;//数据返回会被记录
}
onRetainNonConfigurationInstance方法被retainNonConfigurationInstances方法调用，而它会被ActivityThread中performDestroyActivity方法调用，它执行在onDestroy生命周期之前。
### ActivityThread
performDestroyActivity(...boolean getNonConfigInstance,...) {
...
if (getNonConfigInstance) {
//如果配置发生改变记录下来
r.lastNonConfigurationInstances
= r.activity.retainNonConfigurationInstances();
}
}
这样VM数据就被封装到了NonConfigurationInstances一个对象中了。
那何时被还原呢？答案是Activity的attach时。
### Activity
final void attach(Context context, ... NonConfigurationInstances lastNonConfigurationInstances,...) {
...
mLastNonConfigurationInstances = lastNonConfigurationInstances;
...
}
VM数据源mViewModelStore在onCreate时被重新赋值。
### FragmentActivity
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
//还原数据
NonConfigurationInstances nc =
(NonConfigurationInstances) getLastNonConfigurationInstance();
if (nc != null) {
mViewModelStore = nc.viewModelStore;
}
...
}
最后我们整理一下整体流程图。
从上面的流程可以看出VM在Activity因配置变化导致重建时会被保留，从生命周期的角度来说，ViewModel的生命周期可能会长于Activity的生命周期。
这说明我们在使用ViewModel时一定要注意，不能让其引用Activity或View，否则可能导致内存泄漏。
好了，整个ViewModel的分析就结束了，希望你在了解其工作原理的同时对MVVM模式也有一些新的认识。独立的看ViewModel没有什么实际意义，更像是数据容器，结合LiveData使用更容易理解，后续章节会继续分享LiveData的内容。
