独家记忆 | 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 原创,转载须遵守上述协议,保证原文内容的完整、注明作者及出处。

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

开源项目被人拿去做课程卖了 1000 多万是什么体验

嗨,大家好,我是小专栏的独立开发者 寂小桦,并不是我的开源项目 被做成网课 售卖了1000 多万,而是小专栏《重学安卓》的作者 KunMinX 为技术专栏做的配套,让读者更好无痛理解 Google 开源的 Jetpack MVVM 中每个架构组件的 存在缘由、职责边界,而 精心设计的一个又一个高频应用场景项目,被某网课拿去做成 对标阿里 P7 课程,售卖了1000多万。

在此呢,为现在良莠不齐的网课 耽误大家学习时间和精力 赚取高额学费 而感到忧心,很多小伙伴因为焦虑 而无脑购买了很多五花八门网课,但是最后都仅限于 在朋友圈转发下 表示自己买了课 而安抚了下自己的焦虑情绪。

其实努力提升自己的确没问题的,在今年这样形式下,更应该是清空自己,努力提升,但是选择课程和专栏一定要慎之又慎,不然到头来钱也花了 时间也浪费了,能力没提升。

好了,今天我文字采访下 KunMinX ,让他说下他为《重学安卓》技术专栏而做的开源项目被卖 1000 多万的体验吧。

Read More