2020 年，我这样在项目中使用 MVVM

vm.startLoad()
}

private fun addSubscriptions() {
vm.getObservable(String::class.java).observe(this, Observer {
when(it!!.status) {
Status.SUCCESS -> { ToastUtils.showShort(it.data) }
Status.FAILED -> { ToastUtils.showShort(it.message) }
Status.LOADING -> {/* temp do nothing / }
else -> {/ temp do nothing */ }
}
})
}
}

// ViewModel 层代码
class MainViewModel(application: Application) : BaseViewModel(application) {

fun startLoad() {
getObservable(String::class.java).value = Resources.loading()
ARouter.getInstance().navigation(MainDataService::class.java)
?.loadData(object : OnGetMainDataListener{
override fun onGetData() {
getObservable(String::class.java).value = Resources.loading()
}
})
}
}

这样对数据交互格式封装之后，代码是不是简洁多了呢？至于让你的代码更加简洁，Android-VMLib 还为你提供了其它的方法，请继续阅读。

2.4 进一步简化代码，优化无处不在的 LiveData

之前在使用 ViewModel+LiveData 的时候，为了进行数据交互，每个变量我都需要定义一个 LiveData，于是代码变成了下面这个样子。甚至我在有的同学那里看到过一个 ViewModel 中定义了 10+ 个 LiveData. 这让代码变得非常得难看，

public class ApartmentProjectViewModel extends ViewModel {

final private MutableLiveData data;
final private SingleLiveEvent toast;
final private SingleLiveEvent submit;
final private SingleLiveEvent loading;

public ApartmentProjectViewModel() {
data = new MutableLiveData<>();
toast = new SingleLiveEvent<>();
submit = new SingleLiveEvent<>();
loading = new SingleLiveEvent<>();
}

// …
}

后来我的一个同事建议我考虑下如何整理一下 LiveData，于是经过不断的推广和演化，如今这个解决方案已经比较完善——即通过 HashMap 统一管理单例的 LiveData。后来为了进一步简化 ViewModel 层的代码，我将这部分工作交给了一个 Holder 来完成。于是如下解决方案就基本成型了，

public class BaseViewModel extends AndroidViewModel {

private LiveDataHolder holder = new LiveDataHolder();

// 通过要传递的数据类型获取一个 LiveData 对象
public MutableLiveData<Resources> getObservable(Class dataType) {
return holder.getLiveData(dataType, false);
}
}

这里的 Holder 实现如下，

public class LiveDataHolder {

private Map<Class, SingleLiveEvent> map = new HashMap<>();

public MutableLiveData<Resources> getLiveData(Class dataType, boolean single) {
SingleLiveEvent<Resources> liveData = map.get(dataType);
if (liveData == null) {
liveData = new SingleLiveEvent<>(single);
map.put(dataType, liveData);
}
return liveData;
}
}

原理很简单吧。使用了这套方案之后你的代码将会变得如下面这般简洁优雅，

// ViewModel 层
class EyepetizerViewModel(application: Application) : BaseViewModel(application) {

private var eyepetizerService: EyepetizerService = ARouter.getInstance().navigation(EyepetizerService::class.java)

private var nextPageUrl: String? = null

fun requestFirstPage() {
getObservable(HomeBean::class.java).value = Resources.loading()
eyepetizerService.getFirstHomePage(null, object : OnGetHomeBeansListener {
override fun onError(errorCode: String, errorMsg: String) {
getObservable(HomeBean::class.java).value = Resources.failed(errorCode, errorMsg)
}

override fun onGetHomeBean(homeBean: HomeBean) {
nextPageUrl = homeBean.nextPageUrl
getObservable(HomeBean::class.java).value = Resources.success(homeBean)
// 再请求一页
requestNextPage()
}
})
}

fun requestNextPage() {
eyepetizerService.getMoreHomePage(nextPageUrl, object : OnGetHomeBeansListener {
override fun onError(errorCode: String, errorMsg: String) {
getObservable(HomeBean::class.java).value = Resources.failed(errorCode, errorMsg)
}

override fun onGetHomeBean(homeBean: HomeBean) {
nextPageUrl = homeBean.nextPageUrl
getObservable(HomeBean::class.java).value = Resources.success(homeBean)
}
})
}
}

// View 层
class EyepetizerActivity : CommonActivity<EyepetizerViewModel, ActivityEyepetizerBinding>() {

private lateinit var adapter: HomeAdapter
private var loading : Boolean = false

override fun getLayoutResId() = R.layout.activity_eyepetizer

override fun doCreateView(savedInstanceState: Bundle?) {
addSubscriptions()
vm.requestFirstPage()
}

private fun addSubscriptions() {
vm.getObservable(HomeBean::class.java).observe(this, Observer { resources ->
loading = false
when (resources!!.status) {
Status.SUCCESS -> {
L.d(resources.data)
val list = mutableListOf()
resources.data.issueList.forEach {
it.itemList.forEach { item ->
if (item.data.cover != null
&& item.data.author != null
) list.add(item)
}
}
adapter.addData(list)
}
Status.FAILED -> {/* temp do nothing / }
Status.LOADING -> {/ temp do nothing / }
else -> {/ temp do nothing */ }
}
})
}

// …
}

这里我们通过 getObservable(HomeBean::class.java) 获取一个 ViewModel 和 View 层之间交互的 LiveData<HomeBean>，然后通过它进行数据传递。这种处理方式的好处是，你不需要在自己代码中到处定义 LiveData，将 Holder 当作一个 LiveData 池，需要数据交互的时候直接从 Holder 中获取即可。

有的同学可能会疑问，将 Class 作为从“池”中获取 LiveData 的唯一标记，会不会应用场景有限呢？Android-VMLib 已经考虑到了这个问题，下文踩坑部分会为你讲解。

2.5 共享 ViewModel，配置可以更简单

如果多个 ViewModel 在同一 Activity 的 Fragment 之间进行共享，那么该如何获取呢？

如果是不使用 Android-VMLib，你只需要在 Fragment 中通过 Activity 获取 ViewModel 即可，

ViewModelProviders.of(getActivity()).get(vmClass)

使用了 Android-VMLib 之后这个过程可以变得更加简洁——直接在 Fragment 上声明一个注解即可。比如，

@FragmentConfiguration(shareViewModel = true)
class SecondFragment : BaseFragment() {

override fun getLayoutResId(): Int = R.layout.fragment_second

override fun doCreateView(savedInstanceState: Bundle?) {
L.d(vm)
// Get and display shared value from MainFragment
tv.text = vm.shareValue
btn_post.setOnClickListener {
Bus.get().post(SimpleEvent(“MSG#00001”))
}
}
}

Android-VMLib 会读取你的 Fragment 的注解并获取 shareViewModel 字段的值，并决定使用 Activity 还是 Fragment 获取 ViewModel，以此来实现 ViewModel 的共享。是不是更加简洁了呢？

2.6 Android-VMLib 另一优势，强大的工具类支持

我看过很多框架，它们通常会将一些常用的工具类与框架打包到一起提供给用户使用。Android-VMLib 与之相反，我们将工具类作为独立项目进行支持。这样的目的是，1). 希望工具类本身可以摆脱对框架的依赖，独立应用到各个项目当中；2). 作为单独的模块，单独进行优化，使功能不断完善。

截至目前，工具类库 [Android-Utils](() 已经提供了 22 个独立的工具类，涉及从 IO、资源读取、图像处理、动画到运行时权限获取等各种功能，对于该库我会在以后的文章里进行说明。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FPAAHWyO-1650770468128)(https://user-gold-cdn.xitu.io/2020/5/23/1723f9a7ba5a6530?imageView2/0/w/1280/h/960/ignore-error/1)]

需要说明的是，该库在开发的过程中参考了很多其它的类库，当然我们也开发了自己的特色工具类，比如运行时权限获取、主题中属性获取、字符串拼接等等。

3、Jetpack MVVM 踩坑实录以及 Android-VMLib 的解决方案

3.1 反复通知，不该来的来了

这部分涉及到 ViewModel 的实现原理，如果没有了解过其原理，可参考 [《揭开 ViewModel 的生命周期控制的神秘面纱》](() 一文进行了解。

以我在该项目中的示例代码为例，MainFragment 和 SecondFragment 之间共享了 SharedViewModel，在 MainFragment 当中，我们往 LiveData 中塞了一个值。然后我们跳转到 SecondFragment，从 SecondFragment 中回来的时候再次收到了这个值的通知。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-svEcXkD9-1650770468129)(https://user-gold-cdn.xitu.io/2020/5/23/1723f9af07c379dc?imageView2/0/w/1280/h/960/ignore-error/1)]

很多时候我们只希望在调用 LiveData#setValue() 的时候通知一次数据变化。此时，我们可以通过 [SingleLiveEvent](() 解决这个问题。这个类的原理并不难，只是通过 AtomicBoolean 来管理通知，当前仅当调用 setValue() 的时候进行通知。这解决了许多从后台回来之后页面的通知问题。

在 Andoird-VMLib 当中，当你通过 getObservable() 从“池”中获取 LiveData 的时候，你可以通过带 single 参数的方法来获取这种类型的事件，

// 这里通过指定 single 为 true 来使用 SingleLiveEvent
vm.getObservable(String::class.java, FLAG_1, true).observe(this, Observer {
toast(“#1.1: " + it!!.data)
L.d(”#1.1: " + it.data)
})

在使用 SingleLiveEvent 中的问题，

1. 从“池”中获取 LiveData 的时候只会根据第一次获取时的参数决定这个 LiveData 是不是 SingleLiveEvent 类型时。也就是说，当你第一次使用 vm.getObservable(String::class.java, FLAG_1, true) 获取 LiveData 之后，再通过 vm.getObservable(String::class.java, FLAG_1) 获取到的是同一个 LiveData.

2. SingleLiveEvent 本身存在一个问题：当存在多个观察者的时候，它只能通知给其中的一个，并且你无法确定被通知的是哪一个。这和 SingleLiveEvent 的设计原理相关，因为它通过原子的 Boolean 标记通知状态，通知给一个观察者之后状态就被修改掉了。另外，注册的观察者会被放进 Map 里，然后使用迭代器遍历进行通知，因此无法确定通知的先后顺序（哈希之后的坑位先后顺序无法确定）。

3.2 LiveData 的本质和本职

LiveData 本质上等同于数据本身，本职是数据缓存。

参考 [《揭开 LiveData 的通知机制的神秘面纱》](() 一文，其实现原理就是在 LiveData 内部定义了一个 Object 类型的、名为 data 的对象，我们调用 setValue() 的时候就是为这个对象赋值。LiveData 巧妙的地方在于利用了 LifecycleOwner 的生命周期回调，在生命周期发生变化的时候通知结果给观察者。如果不熟悉 LiveData 的这些特性，编码的时候就容易出现一些问题。

以文章为例，其包含两个主要部分：标题和内容，并且两者都是 String 类型的。这就导致我们通过 getObservable(Class<T> dataType) 进行监听的时候，无法判断发生变化的是文章的内容还是文章的标题。因此，除了 getObservable(Class<T> dataType)，在 BaseViewModel 中，我们还加入了 getObservable(Class<T> dataType, int flag) 方法来获取 LiveData。你可以这样理解——指定不同的 Flag 的时候，我们会从不同的“池”中获取 LiveData，因此，得到的是不同 LiveData 对象。

public MutableLiveData<Resources> getObservable(Class dataType) {
return holder.getLiveData(dataType, false);
}

public MutableLiveData<Resources> getObservable(Class dataType, int flag) {
return holder.getLiveData(dataType, flag, false);
}

有的同学可能会想到使用之前封装的 Resource 对象的预留字段来指定发生变化的是文章的标题还是内容。我强烈建议你不要这么做！ 因为，正如我们上面说的那样，LiveData 和 Data 本身应该是一对一的。这样处理的结果是文章的标题和内容被设置到了同一个对象上面，内存之中只维护了一份缓存。其后果是，当页面出于后台的时候，假如你先更新了文章的标题，后更新了文章的内容，那么此时缓存之中只会保留文章的数据。当你的页面从后台回来的时候，标题就无法更新到 UI 上。还应该注意，假如一个数据分为前半部分和后半部分，你不能在修改后半部分的时候覆盖了前半部分修改的内容，这会导致前半部分修改结果无法更新到 UI。这不是 Android-VMLib 的错，很多时候不理解 LiveData 的本质和本职就容易陷到这个坑里去。

3.3 数据恢复问题，ViewModel 的版本差异

在 [《揭开 ViewModel 的生命周期控制的神秘面纱》](() 一文中，我分析了无法从 ViewModel 中获取缓存的结果的问题。这是因为早期的 ViewModel 是通过空的 Fragment 实现生命周期控制的。所以，当页面在后台被杀死的时候，Fragment 被销毁，从而导致再次获取到的 ViewModel 与之前的 ViewModel 不是同一对象。在后来的版本中，ViewModel 的状态恢复问题采用了另一种解决方案。下面是两个版本类库的差异（第一张是早期版本，第二张是近期的版本），
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-oQwIQn91-1650770468130)(https://user-gold-cdn.xitu.io/2020/5/23/1723f9b679bf9b3c?imageView2/0/w/1280/h/960/ignore-error/1)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OsNK7DzU-1650770468130)(https://user-gold-cdn.xitu.io/2020/5/23/1723f9b901114bc0?imageView2/0/w/1280/h/960/ignore-error/1)]
近期的版本抛弃了之前的 Fragment 的解决方案，改为了通过 savedstate 保存 ViewModel 的数据。这里再次提及这个问题是提醒你在开发的时候注意选择的库的版本以及早期版本中存在的问题以提前避坑。
总结

这篇文章中介绍了 [Android-VMLib](() 以及使用 MVVM 的过程中遇到过的一些问题。如果在使用过程中你还遇到了其它的问题可以与笔者进行交流。
(img-oQwIQn91-1650770468130)]
[外链图片转存中…(img-OsNK7DzU-1650770468130)]
近期的版本抛弃了之前的 Fragment 的解决方案，改为了通过 savedstate 保存 ViewModel 的数据。这里再次提及这个问题是提醒你在开发的时候注意选择的库的版本以及早期版本中存在的问题以提前避坑。
总结

这篇文章中介绍了 [Android-VMLib](() 以及使用 MVVM 的过程中遇到过的一些问题。如果在使用过程中你还遇到了其它的问题可以与笔者进行交流。