859bf0dd76e76e4f0581004499064030
重学安卓:是让人耳目一新的 Jetpack MVVM 精讲啊!

温馨提示:如果这是第一次接触《重学安卓》,可借助 这份在 GitBook 上维护的 “导读” 来快速了解《重学安卓》专栏、获取它的目录、试读内容,以及了解它的最新动态 和 发展状况。

截至目前,专栏已对 体系化文章 做了 810 余次修订,数十位群友告诉我 受专栏的启发 他们也开启了写作之路。群里不定期会有小伙伴讨论适配问题、分享原创的开源库 和 提供内推机会,订阅后可随时进群交流。

前言

很高兴见到你!

最近在后台 时有收到 读者的留言,说能不能出一期 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 有个坑需要注意
    • Note 2020.07.09 加餐
  • 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 被设计为粘性事件

—— 我姑且认为这是个拓展性不佳的设计,甚至可以说是一个 bug,

因为 Jetpack MVVM 是一个整体,既然 ViewModel 支持共享作用域,并且官方文档都承认了通过 共享 ViewModel 来实现跨页面通信的需求

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

关于非粘性 LiveData 的实现,网上存在通过 “事件包装类”(只适合 kotlin 的情况) 和 “反射干预 LastVersion” (适用于 Java 的情况)两种方式来解决:

《在 SnackBar 和其他事件中使用 LiveData》(SingleLiveEvent 案例)

《LiveDataBus实现原理#用法详解#LiveData扩展》(反射案例)

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

Note 2020.07.09 加餐:

top Created with Sketch.