是让人耳目一新的 Jetpack MVVM 精讲啊！

前言

很高兴见到你！

最近在后台 时有收到 读者的留言，说能不能出一期 Jetpack MVVM 精讲，以及配套一份简练的案例，好 把玩把玩、感觉感觉、加深对 MVVM 的印象。

答案固然是确定的。😉

面向标准化开发已成现实

金九银十，相信有很多读者在抓紧机会面试。

Android 市场已今非昔比。在过去，迫于招人的压力，应试者只需了解四大组件、视图、网络请求，便可谋得一份满意的工做。

现现在，Jetpack 架构组件 及 标准化开发模式 的确立，意味着 Android 开发已步入成熟阶段：

许多 样板代码 再也不须要开发者手写，而是能够经过模版工具 自动生成，在取缔繁杂耗时的重复工做的同时，避免因人工操做的疏忽，而形成难以排查、不可预期的错误。

这十分符合企业的利益，于是面试官在招人的时候，也更加看重应试者对 架构组件 —— 至少是 MVVM 的理解程度。🧐

像“解耦”等 含糊其辞的说法，已经不可以被面试官所承认，稍微对 MVVM 有一点经验的面试官都会请你举例说明，好证实你确实对 MVVM 有着正确、深刻的理解，可以天然而然地写出标准化、规范化的代码，可以迅速适应 各家公司自制的 自动化模版工具。

本文的目标

本人拥有 3 年的 移动端架构 践行和设计经验，领导团队重构的中大型项目多达十数个，对 Jetpack MVVM 架构在确立规范化、标准化 开发模式 以减小不可预期的错误 所做的努力，有着深刻的理解。

于是本文的目标，就是结合前几期咱们分别 深刻浅出 介绍过的 Lifecycle、LiveData、ViewModel、DataBinding，来融汇贯通地演绎一下：

做为 应用开发骨架 的 标准化状态管理框架，究竟为 快速开发过程当中 减小不可预期的错误 作了哪些努力。

不一样于 东拼西凑、人云亦云、徒添困扰 的网文，愿意将 标准化开发模式的 深度思考知识 和 实战反思经验 无保留地分享，全网仅此一家。这样的文章能够说是 看一篇、少一篇，所以，就算不去 hold 住面试官，也请务必跟随本文的脚步，无障碍地将 Jetpack MVVM 过一遍！😉

文章目录一览

• 前言
• 面向标准化开发已成现实
• 本文的目标
• Jetpack Lifecycle
  • Lifecycle 存在前的混沌世界
  • Lifecycle 为何能解决上述这些问题？
• Jetpack LiveData
  • LiveData 存在前的混沌世界
  • LiveData 为何能解决上述这些问题？
  • LiveData 有个坑须要注意
• Jetpack ViewModel
  • ViewModel 存在前的混沌世界
  • ViewModel 为何能作到这几点？
• Jetpack DataBinding
  • DataBinding 存在前的混沌世界
  • DataBinding 就是来解决这些问题
• 综上

Jetpack Lifecycle

Lifecycle 的存在，主要是为了解决 生命周期管理 的一致性问题

Lifecycle 存在前的混沌世界

在 Lifecycle 面市前，生命周期管理 纯靠手工维持，这样就容易滋生大量的一致性问题。

例如跨页面共享的 GpsManager 组件，在每一个依赖它的 Activity 的 onResume 和 onPause 中都须要 手工 激活、解绑 和 叫停。

那么 随着 Activity 的增多，这种手工操做 埋下的一致性隐患 就会指数级增加：

一方面，凡是手工维持的，开发者容易疏忽，特别是工做交接给其余同事时，同事并不能及时注意到这些细节。

另外一方面，分散的代码不利于修改，往后除了激活、叫停，如有其余操做须要补充（例如状态监听），那么每一个 Activity 都须要额外书写一遍。

Lifecycle 为何能解决上述这些问题？

Lifecycle 经过 模板方法模式 和 观察者模式，将生命周期管理的复杂操做，所有在做为 LifecycleOwner 的基类中（例如视图控制器的基类）封装好，默默地在背后为开发者指挥若定，

开发者于是得以在视图控制器（子类）中只需一句 getLifecycle().addObserver(GpsManager.getInstance) ，优雅地完成 第三方组件在本身内部 对 LifecycleOwner 生命周期的感知。

除了解决一致性问题，这样作还 顺带地提供了其余 2 个好处：

1.规避 为监听状态 而 注入视图控制器 的作法

当须要监听状态时，以往咱们的作法是 经过方法手工注入 Activity 等参数，这埋下了内存泄漏的隐患 —— 由于团队中的新手容易因这是个 Activity，而在往后误将其依赖给组件中的其余成员。

现现在，咱们能够直接在组件内部 点到为止 地监听 LifecycleOwner 的状态，从而规避这种不恰当的使用。

2.规避 为追溯事故来源 而 注入视图控制器 的作法

当发生事故时，以往咱们若想在组件中 追溯事故来源，一样不得不从方法中直接注入 Activity 等，这一样埋下了内存泄漏的隐患。现现在组件因实现了 DefaultLifecycleObserver，而得以经过生命周期回调方法中的 LifecycleOwner 参数，在方法做用域中 便可得知事故来源，无需更多带有隐患的操做。

若是这么说还不理解的话，可具体参考我在 《为你还原一个真实的 Jetpack Lifecycle》 中提供的 GpsManager 案例，本文再也不累述。

Jetpack LiveData

LiveData 的存在，主要是为了帮助 新手老手 都能不假思索地遵循 经过惟一可信源分发状态 的标准化开发理念，从而使在快速开发过程当中 难以追溯、难以排查、不可预期 的问题所发生的几率下降到最小。

LiveData 存在前的混沌世界

在 LiveData 面市前，咱们分发状态，可能是经过 EventBus 或 Java Interface 来完成的。无论你是用于网络请求回调的状况，仍是跨页面通讯的状况。

那这形成了什么问题呢？首先，EventBus 只是纯粹的 Bus，它 缺少上述提到的 标准化开发理念 的约束，那么人们在使用这个框架时，容易因 去中心化 地滥用，而形成 诸如 毫无防备地收到 预期外的 不明来源的推送、拿到过期的数据 及 事件源追溯复杂度 为 n² 的局面。

而且，EventBus 自己缺少 Lifecycle 的加持，存在生命周期管理的一致性问题。这是 EventBus 的硬伤，也是我拒绝使用 EventBus 的最主要因素。

对上述情况不理解的，可具体参考我在 《LiveData 不为人知的 身世背景 和 独特使命》 中提供的 播放器状态全局通知 的案例

LiveData 为何能解决上述这些问题？

首先，LiveData 是在 Google 但愿确立 标准化、规范化 的开发模式 —— 这样一种背景下诞生的，于是为了达成这个艰巨的 使命，Google 十分克制地将其设计为，仅支持状态的输入和监听，从而，它不得不 在单例的配合下，承上启下地完成 状态 从 惟一可信源 到 视图控制器 的输送。

（ViewModel 姑且也算是一种单例，一种工厂模式实现的伪单例。惟一可信源是指 生命周期独立于 视图控制器的 数据组件，一般是 单例 或共享 ViewModel）

这使得任何一次状态推送，均可预期、都能方便地追溯来源，而不至于在 事件追溯复杂度为 n² 的迷宫中白费时间。（即，不管是从哪一个视图控制器发起的 对某个共享状态改变的请求，状态最终的改变 都由 做为惟一可信源的 单例或 SharedViewModel 来一对多地通知改变）

而且，这种承上启下的方式，使得单向依赖成为可能：单例无需经过 Java Interface 回调通知视图控制器，从而规避了视图控制器 被生命周期更长的单例 依赖 所埋下的内存泄漏的隐患。

LiveData 有个坑须要注意

不过，LiveData 的设计有个坑，这里我顺带提一下。

为了在视图控制器发生重建后，可以 自动灌倒 所观察的 LiveData 的最后一次数据，LiveData 被设计为粘性事件。

—— 我姑且认为这和 Jetpack Navigation 只支持 replace 方式切换 Fragment 同样，是个拓展性不佳的设计，甚至能够说是一个 bug，

由于 MVVM 是一个总体，既然 ViewModel 支持共享做用域，而且官方文档都认可了经过 共享 ViewModel 来实现跨页面通讯的需求，

那么基于 “开闭原则”，LiveData 理应提供一个与 MutableLiveData 平级的底层支持，专门用于非粘性的事件通讯的状况，不然直接在跨页面通讯中使用 MutableLiveData 必形成 事件回调的一致性问题 及 难以预期的错误。

关于非粘性 LiveData 的实现，网上存在经过 “事件包装类”（只适合 kotlin 的状况） 和 “反射干预 LastVersion” （适用于 Java 的状况）两种方式来解决：

juejin.im/post/5b2b1b…

blog.csdn.net/geyuecang/a…

不管是使用哪种实现，我都建议 遵循传统 LiveData 所遵循的开发理念，经过惟一可信源分发状态，来方便事件源头的追溯。对于 “去中心化” 的 Bus 方式，我拒绝在项目中这样使用。

（具体我会在将来开源的最佳实践项目中 展现 UnPeekLiveData 的使用）

Jetpack ViewModel

ViewModel 的存在，主要是为了解决 状态管理 和 状态共享 的问题。

ViewModel 存在前的混沌世界

ViewModel 的本职工做是 状态托管 和 状态管理的分治，也即当视图控制器重建时，

对于轻量的状态，能够经过视图控制器基类的 saveInstanceState 机制，以序列化的方式完成存储和恢复。

对于重量级的状态，例如经过网络请求获得的 List，能够经过生命周期长于视图控制器的 ViewModel 持有，从而得以直接从 ViewModel 恢复，而不是以效率较低的序列化方式。

在 Jetpack ViewModel 面市以前，MVP 的 Presenter 和 MVVM - Clean 的 ViewModel 都不具有状态管理分治的能力。

Presenter 和 Clean ViewModel 的生命周期都与视图控制器同生共死，于是它们顶可能是为 DataBinding 提供状态的托管，而没法实现状态的分治。

到了 Jetpack 这一版，ViewModel 以精妙的设计，达成了状态管理，以及可共享的做用域。

ViewModel 为何能作到这几点？

其实这版主要是基于 工厂模式，使得 ViewModel 被 LifecycleOwner 所持有、经过 ViewModelProvider 来引用，

因此 它既相似于单例： —— 当被做为 LifecycleOwner 的 Activity 持有时，可以脱离 Activity 旗下 Fragment 的生命周期，从而实现做用域共享，

实际上又不是单例： —— 生命周期跟随 做为 LifecycleOwner 的视图控制器，当 Owner（Activity 或 Fragment）被销毁时，它也被 clear。

此外，出于对视图控制器重建的考虑，Google 在视图控制器基类中经过 retain 机制对 ViewModel 进行了保留。

所以，对于 做用域共享 和 视图重建 的状况，状态因无缺地被保留，而得以被视图控制器在恢复时直接使用。

再者，因为存在 共享做用域的考虑，因此 ViewModel 自己也承担了跨页面通讯（例如事件回调）的职责。前面在介绍 LiveData 时，对于 LiveData 在事件通讯时粘性设计的问题已经介绍过了，这里再也不累述。

Jetpack DataBinding

DataBinding 的存在，主要是为了解决 视图 的一致性问题。

DataBinding 存在前的混沌世界

在 DataBinding 面市前，咱们若要改变视图的状态，首先就要引用该视图，例如 textView.setText()，

这形成什么问题呢？

当页面存在横、竖布局，且两种布局的控件存在差别，例如横屏存在 textView 控件，而竖屏没有，那么咱们就不得不在视图控制器中为 textView 作判空处理，这就形成了一致性问题 —— 容易疏忽而忘记判空，毕竟页面多达数十个、每一个页面的控件也无数。

那怎么办呢？

DataBinding 就是来解决这些问题

经过在布局中与可观察的数据发生绑定，那么当该数据被 set 新的内容时，控件也将获得通知和刷新。

换言之，在使用 DataBinding 后，惟一的改变是，你无需手工调用视图来 set 新状态，你只需 set 数据自己。

于是，DataBinding 并不是许多人不假思索认为的，将 UI 逻辑搬到 XML 中写 从而难以调试 —— 事实根本不是这样的：

DataBinding 只负责绑定数据、负责做为 UI 逻辑末端的状态的改变（也即它是一个不可再分的原子操做，原本就不须要调试），本来在视图控制器中 UI 逻辑怎么写，如今仍是怎么写，只不过再也不须要 textView.setText(xxx)，而是直接 xxx.set()。

因此在 DataBinding 的帮助下，好处总共有多少个呢？

1.规避了视图状态的 一致性问题 —— 无需手工判空。

2.规避了视图状态的 一致性问题，乃至无需视图调用，从而彻底不用编写 findViewById。

3.就算要调用视图，也不用 findViewById，而是直接经过 binding 来引用。

4.先前的 UI 逻辑基本不用改动，改的只是做为末端的状态改变的方式。

……

此外，DataBinding 有个大杀器就是，能为控件提供自定义属性的 BindingAdapter，它不只能够解决 圆角 Drawable 复用的问题（你懂得），还能够实现 imageView 直接绑定 url 等需求，总之，没有它办不到的，只有你想不到的，DataBinding 的好处等着你挖掘。😉

关于 DataBinding 的注意事项，以及屡试不爽的排坑技巧，可具体参考 《从 被反对 到 真香 的 Jetpack DataBinding！》，这里不作累述。

综上

Lifecycle 的存在，主要是为了解决 生命周期管理 的一致性问题。

LiveData 的存在，主要是为了帮助 新手老手 都能不假思索地 遵循 经过惟一可信源分发状态 的标准化开发理念，从而在快速开发过程当中 规避一系列 难以追溯、难以排查、不可预期 的问题。

ViewModel 的存在，主要是为了解决 状态管理 和 状态共享 的问题。

DataBinding 的存在，主要是为了解决 视图 的一致性问题。

它们的存在 大都是为了解决一致性的问题、将容易出错的操做在后台封装好，方便使用者快速、稳定、不产生预期外错误地编码。

这样说，你理解了吗？😉

结语：Jetpack MVVM 最佳实践的案例，计划于 2019 年 10 月底 在 GitHub 发布。届时我会以各类形式留下访问方式，敬请期待！