独家记忆 | Jetpack MVVM 高频提问和解答

很高兴见到你!

我是《Jetpack MVVM 精讲》《Jetpack MVVM 最佳实践》的作者 KunMinX,

在过去一年里,我们分别在各渠道的维护和交流中,收集到许多新上手的小伙伴在把 Jetpack MVVM 应用到自己项目中时,最频繁提及的问题,

随着 Jetpack MVVM 的普及,高频提问也越来越多地出现在 面试或重构工作中,

考虑到这些四处分散的 Q&A(提问和解答) 不便于新上手的小伙伴查阅,因而单独准备了本文,点开就能直接查看到 从数百位读者的数千次提问中 精心筛选出的高频 Q&A,

所以这样的文章,从前乃至往后就只提供这么一篇,请珍惜地享用 😉

 

目录一览

 

《重学安卓》读者群 高频 Q&A TOP 5

 

TOP 1:Jetpack MVVM 下的页面通信怎么做?

解答:通过 SharedViewModel 来完成。

追问:为什么?

解答:我们之所以选择 Application 级的 ViewModel,而不是静态变量或传统 bus 来完成 应用内页面间的消息通信(事件回调等),是考虑到:

1.该 ViewModel 被封装在视图控制器(Activity/Fragment)的基类,使得消息能够 仅限于在视图控制器之间传播,而不污染到之外的区域。

2.同时也可避免被外部的组件拿到,而造成不可预期的推送。

具体可见《最佳实践》项目中对 SharedViewModel 的使用。

 

TOP 2:LiveData “数据倒灌” 是什么情况,如何解决?

解答:“数据倒灌” 现象是我全网首创的对某类现象的概括,所以网上大概搜不到这类描述。

数据倒灌是 专指 在 页面通信(事件回调)的场景下,通过 SharedViewModel 的 LiveData 给当前页通知过一次,并返回上一页,下次再进入当前页时重复收到推送的情况。

目前《最佳实践》项目中通过 EventLiveData 解决了这类问题,具体可查看最新源码。

Event 包装器 重写底层 EventLiveData

 

TOP 3:逻辑为什么不在 ViewModel 中写?

解答:Jetpack MVVM 主要遵循 数据驱动关注点分离 这两大特性,

其中关注点分离 是通过 “最小知道原则” 来体现:

UI 逻辑在视图控制器(Activity / Fragment)中写

业务逻辑在数据层(例如 DataRepository)写

ViewModel 作为 视图控制器 和 数据层 沟通的桥梁,其自身应保持轻量,以胜任 “承上启下” 的角色(保持整体框架的 单向依赖)。

而且,就像认识其他问题一样,“逻辑该在 Activity 中写还是 ViewModel 中写”,

要搞清楚这个问题,我们 仍然需要首先搞清楚,这件事的背景是什么 ——

是在多人协作的软件工程的背景下。

👆👆👆 划重点

这意味着什么呢?意味着,一旦 你将 UI 逻辑放在 ViewModel 中写了,后续就不可控了

你的同事如果不熟悉这一套开发模式,在 “破窗效应” 的驱使下,就可能直接在 ViewModel 中取 context、取各种不该取的东西,最终内存泄漏什么的,全都来了。

综上,ViewModel 的职责边界就是帮助 Activity/Fragment 托管数据,不适合在 ViewModel 中写逻辑。

更多细节内容详见 《有了 Jetpack ViewModel . . . 真的可以为所欲为!》 中的介绍。

 

TOP 4:为什么不用 LiveDataBus?

解答:原因同上。

不使用 LiveDataBus 是因为,我们是以 在 多人协作、页面繁杂的 软件工程 为背景来谈论架构设计的。在这样的背景下,任何微不足道的隐患,都可能被无限放大。

bus 自身 缺乏唯一可信源的理念约束 以及 难以追溯事件源对象,应彻底从项目中移除,以免团队新手的误用乃至滥用。

具体缘由可参考 《LiveData 鲜为人知的 身世背景 和 独特使命》 中的介绍。

与此同时,尽可能使用 单例或全局 ViewModel 来托管 liveData,这样调试时能根据内存中的 liveData 对象找到事件源。LiveDataBus 这种通过 tag 来标记的,难以找到。

 

TOP 5:Navigation replace 方式返回时,怎么恢复视图状态?

解答:Navigation 的 FragmentNavigator,官方写法是通过 replace 来启动新 Fragment,这可能造成返回时重绘页面等问题,对此有两种办法,一种是重写 FragmentNavigator,使之通过 show hide 来启动新 Fragment,另一种是在 onCreateView 中复用上一次实例化好的 View。

具体操作和注意事项可参考 《就算不用 Jetpack Navigation,也请务必领略的声明式编程之美!》 文末的详细补充,以及我和 Flywith24《我的碎片很听话,你的 Fragment 有自己的想法》 评论区 22 楼关于 replace 方式返回时视图状态恢复的讨论。

 

Jetpack MVVM 最佳实践 issue 高频 Q&A TOP 5:

 

TOP 1:页面 onPause 的时候,不是不该收到消息吗?

解答:看到网上有不少 以讹传讹的网文 传播 “页面 onPause 时不会收到 LiveData 通知” 等不实观点,给读者们徒添困扰、耽误大量时间,特此辟谣:

事实恰恰相反,onPause 可以收到,而 onStart 不是所有场景都能收到(截至 2020.2,Activity 能,Fragment 不能) ——

只有 onResume 和 onPause 是介于 STARTED、RESUMED 状态之间,也即只有这两个生命周期节点 100% 确定能够收到 LiveData 的推送。

具体缘由详见专栏 《为你还原一个真实的 Jetpack Lifecycle》 文末 最新补充

 

TOP 2:《最佳实践》项目中的 “DataBinding 严格模式”是怎么回事?

解答:“严格模式” 是我基于对 “数据驱动” 的本质的理解,而全网首创的 软件工程安全的 “纯粹数据驱动” 的写法。换言之,只要遵循 “严格模式”,就可以确保 100% 解决视图调用的一致性问题(安全性等价于基于函数式编程思想的 Jetpack Compose),避免在多布局等背景下滋生的各种 null 安全情况的发生。

关于 “数据驱动” 的本质,可详见 《从 被误解 到 真香 的 Jetpack DataBinding!》《是 事关软件工程安全 的 数据驱动 UI 框架 上车指南》 中全网独家提供的深度解析。

 

TOP 3:为什么 MainActivityViewModel 中使用 LiveData 绑定视图状态,而其他 State-ViewModel 使用 ObservableField?

解答:ObservaleField 有防抖的特点,要记住这个特点,然后根据情况选择使用。

比如 PureMusic 中通知抽屉打开,用 ObservaleField<Boolean> 不合适,而 LiveData 合适,
因为 ObservaleField 防抖,第一次 set true,就有 true 为 value 了,第二次再 set true,就不 notify 视图刷新了(具体见 ObservaleBoolean 的 set 方法实现)

防抖可以避免重复刷新 以减少不必要的性能开销,所以看情况选择 ObservaleField 或 LiveData。

更多细节内容详见 《从 被误解 到 真香 的 Jetpack DataBinding!》 文末及评论区中的补充。

 

TOP 4:LiveData observe 回调走了多次,该如何处理?

解答:(注意此处所指的情况不同于 “数据倒灌”)

考虑到此前有多位小伙伴私下询问过 LiveData “重复回调”的问题,这里额外做个明示:

LiveData 是被设计为,支持从 ViewModel、单例等唯一可信源 完成数据的一对多分发,因而其内部的观察套路 并非 “一对一”的 观察者模式,而是 “一对多” 的 发布-订阅模式,我在 2018 年初自主设计并开源的 VIABUS 架构 也是采取这种模式,内部通过 Map 来维护订阅者。

所以正常情况下,对于 一个 LiveData 实例,在同一个页面中只该注册一次观察、请勿在 RecyclerView Adapter 的 onBindViewHolder 等处注册,避免导致重复注册多个订阅者,从而不可预期地在每次请求后 “收到多次推送”。

更多完整的提示可参见 《LiveData 鲜为人知的 身世背景 和 独特使命》 文末的最新补充。

 

TOP 5:将《最佳实践》的 Navigation 修改版引入到自己项目,结果还是走的 replace,怎么办?

解答:请移除自己项目中引入的 navigation.fragment gradle 引用,不然可能会覆盖来自 architecture module 下的那些。
并且,请确保 navigation.fragment 被移入自己项目时,和原来 architecture module 中一样,使用完整的 com.androidX 的包名路径。

 

版权声明

本文以 CC 署名-非商业性使用-禁止演绎 4.0 国际协议 发行。

Copyright © 2019-present KunMinX

本文内容均属于作者 KunMinX 原创,转载须遵守上述协议,保证原文内容的完整、注明作者及出处。

任何个人或组织,未经作者本人沟通许可,不得将文中内容洗稿和用于写书、卖课等商业活动。