接上篇，BaseViewModel类通过泛型 与 BaseViewEvent类关联起来，貌似不错。实际开发中，限制实在太多了。乃至简单页面也要如此繁琐。因此去掉泛型限制。改成子类重写 getEvent 的方式赋值。
如图，BaseViewModel 没有其他作用，仅仅是与BaseViewEvent 关联而已。
这么做的思路是为了方便 xml 的控件可以通过 viewModel.viewEvent:xxxx 调用相关事件。
BaseViewEvent 基本上没有改动。只要是新增的控件事件，都需往这里添加空的方法。子类重写即可使用。
BaseVMActivity 的主要作用是，将根据 xml 自动生成的 Binding 类与BaseViewModel类，BaseViewEvent类 进行关联。
需要注意的是图2，通过泛型与反射做了Binding 类与BaseViewModel类，BaseViewEvent关联操作。省去子类的各种重复代码。
到这里，还是很虚是吧。一般情况，一个父类基本上就完成了大部分工作。而这里更多都是基本的整理。上不了台面。主要的想法是不太想整在一起，将 底层mvvm 跟业务扯上关系。
接下来就是更上层的封装，而项目的开发也是基于这一层。
BaseAppViewModel ：继承于 BaseViewModel
对于 ViewModel 的理解见仁见智。
截图可以看出，这里将网络请求也集成进来。原因是，后续子类就可以直接调用网络请求方法。更加简单便捷。如下图：（异步实现依然是 Kotlin 的协程。）
除此之外，ViewModel 尽可能的关心数据。对此，第一个问题来了。怎么处理 loading 对话框以及 toast。
这里定义
var loadingStyle = MutableLiveData<LoadingStyleData>()
var toast = MutableLiveData<String>()
分别对 loading， toast 进行观察。当数据变化时，便更新UI（弹出/消失 loading，toast）
BaseAppActivity ：继承于 BaseVMActivity
这里需要注意的是：
图1中，需要设置主题。不然，会奔溃。
图2中，就是观察 BaseAppViewModel 里的 loadingStyle 与 toast， 从而实现显示，消失loading, toast。
图3中，由于应用里，几乎都是统一的标题。采用 include 方式引入统一 xml 布局。由于非强制，这里做了判空。当然，也可以重写该方法绑定其他 xml 布局。
这里还需注意 initVMObserve 方法，但子类activity 需要关注 专属LiveData 时可重写该方法。如下图：
有了 BaseAppViewModel， BaseAppActivity ，基本就可以开展业务开发了。
本篇暂时就到这里哈。
