ViewModel 是个抽象类，作用是为 Activity/Fragment 这样的视图控制器来存储和管理相关数据。
一个 ViewModel 对象的创建会和 Activity/Fragment 的创建关联起来，并且随着 Activity/Fragment 的消亡，也随之消亡。（有一种情况比较特殊，当屏幕旋转造成 Activity/Fragment 生命周期重走，并不会引起 ViewModel 对象的重建。）
在数据操作上，ViewModel 的数据变更会通过 LiveData 或者 DataBinding 的方式通知到 Activity/Fragment 上来展现。
所以实现 MVVM 的关键就是 Lifecycle 的概念 + LiveData + ViewModel。
实现原理
老规矩，先来看看实现原理，以下代码基于当前最新的 androidx 版本 1.3.0，低版本实现上有所区别，不过核心思想差别不大。
ViewModel 对象的创建需要通过 ViewModelProvider 来实现。根据提供的构造方法，ViewModelStoreOwner 对象是必须提供的，
public ViewModelProvider(@NonNull ViewModelStoreOwner owner) {
this(owner.getViewModelStore(), owner instanceof HasDefaultViewModelProviderFactory ? ((HasDefaultViewModelProviderFactory) owner).getDefaultViewModelProviderFactory() : NewInstanceFactory.getInstance());
}
ViewModelStoreOwner 是个接口，描述的是 ViewModelStore 的持有者，系统的 ComponentActivity 就实现了这个接口。而 ViewModelStore 可以理解为 ViewModel 的仓库，用来缓存 ViewModel 的，内部实现是一个 HashMap 类型的集合，说明可以存储多个 ViewModel 对象。
所以就以 Activity 为例，Activity 相当于拥有者一个可以存储 ViewModel 的仓库，那这个仓库的 ViewModel 对象具体怎么存取呢？
回看到前面的构造方法，ViewModelProvider 还需要我们提供一个 Factory 类型的对象，结合 ComponetActivity 可以知道，它也实现了 HasDefaultViewModelProviderFactory 接口，接口方法要求返回一个 ViewModelProvider.Factory 类型对象，
public ViewModelProvider.Factory getDefaultViewModelProviderFactory() {
if (mDefaultFactory == null) {
mDefaultFactory = new SavedStateViewModelFactory(
getApplication(),
this,
getIntent() != null ? getIntent().getExtras() : null);
}
return mDefaultFactory;
}
这个 Factory 看似是个用来生产 ViewModel 的工厂定义，SavedStateViewModelFactory 是 ComponetActivity 里的具体实现类。
有了工厂类，ViewModel 仓库，接下来看下 ViewModelProvider 提供的 get 方法，
public <T extends ViewModel> T get(@NonNull Class<T> modelClass) {
String canonicalName = modelClass.getCanonicalName();
return get(DEFAULT_KEY + ":" + canonicalName, modelClass);
}
仓库里缓存需要用到 key，从这里可以知道 key 的生成和具体 ViewModel 类名有关，前面的默认 key 值是 "androidx.lifecycle.ViewModelProvider.DefaultKey"。当然这只是默认 key 的生成方式，也可以自定义。
public <T extends ViewModel> T get(@NonNull String key, @NonNull Class<T> modelClass) {
ViewModel viewModel = mViewModelStore.get(key);
if (modelClass.isInstance(viewModel)) {
if (mFactory instanceof OnRequeryFactory) {
((OnRequeryFactory) mFactory).onRequery(viewModel);
}
return (T) viewModel;
}
if (mFactory instanceof KeyedFactory) {
viewModel = ((KeyedFactory) mFactory).create(key, modelClass);
}
mViewModelStore.put(key, viewModel);
return (T) viewModel;
}
主要逻辑就是先从仓库获取指定 key 的 ViewModel 对象，如果没有会根据 mFactory 的类型进行创建，然后缓存到仓库中。如果获取到了，就返回该对象。工厂创建 ViewModel 对象无非利用的就是反射机制，具体可以看下 SavedStateViewModelFactory 的 create 方法实现。create 方法不是我们这里重点关注的，这里就略过了。
走完这一套流程，我们就能获取到指定 ViewModel 类的对象，接下去就可以结合 LiveData 进行数据和视图的控制。下面是我分析时的一张图，按我的理解画了一下各自关系，便于理解。
MVVM
再来说说 MVVM 的架构模式，它是基于 MVP 的一种改进，因为随着业务的增多，导致 p 层的膨胀臃肿，变的难以维护。所以将 P 层改为 VM 层，实现 VM 和 V 层还有 M 层的双向绑定，即 V 层的变动会使得 VM 引起 M 层的变更，M 层的变动也会使 VM 通知 V 层进行更新。不仅灵活度增加了，p 层也被拆分化简。
具体的化简是怎么实现呢？结合 Lifecycle，LiveData，ViewModel，我对 MVVM 的实现是这么理解的。V 层依然是 Activity/Fragment，M 层管理的数据来源，但实际项目中不会分的那么细致，例如会融合到 P 层上。因为 VM 层代替了原来的 P 层，因此 VM 层的实现会有多个 ViewModel 类来管理。
为什么是多个 ViewModel 类对应一个 V 层呢？我的理解是，首先 V 层对应的实现一般会持有一个 ViewModel 仓库，这个仓库可以存放多个 ViewModel 对象。其次，ViewModel 的划分并不像 P 层，更合理的划分是和数据模型相关，例如 UserViewModel 就是用来管理 User 数据的，ClassViewModel 就是用来管理 Class（课程）数据的。所以这样就会使得 V 层对应着 1 到 多个 ViewModel。
这样的好处是，1. 数据管理更清晰，2. ViewModel 可以在整个项目中复用，而不像 P 层，可能只能给这个 V 层用。缺点是，代码量又要增加了，可能 ViewModel 维护的数据模型很基础很简单，但也要为其做一些维护。
当然一个 ViewModel 里也可以维护着多个 LiveData（即维护多个数据模型），但这样的话感觉就和 MVP 的思想没什么区别了。
