《重学安卓》两周年,回顾与展望

我们于 2019 年 6 月,在小专栏开设了《重学安卓》付费专栏,

迄今为止,我们共连接了 1111 名优秀开发者,并且期间不断有小伙伴告诉我,受专栏内容的影响和启发,他们也开启了写作之路。

以 “深度思考” 为立足之本

在过去两年里,我们以 “架构组件” 为话题,不遗余力地在每篇文章中贯彻落实 基于 “第一性原理” 和 “实事求是” 精神的深度思考方式

在 “深度思考” 的帮助下,以及基于对大量样本的追踪和反思,我们独树一帜地从软件工程的视角出发抓住本质,并开源了一系列高频使用的仓库,

包括 腾讯音乐、BMW、TCL 等知名厂商的软件,都在使用我们正在维护的《UnPeek-LiveData》等仓库。

不小心当了回 “万恶之源”

不知何时起,你是否经常在 培训机构软文 或网文中看到 “一致性” 等令人迷惑的说辞?

这些术语在 Android 领域是从未有过,网上关于 “一致性问题” 等说辞,它们都有一个共同的来源,

事实上,这些术语都是本人经由长期的深度思考、实践和交流后,为现象本质匹配的高度概括,《重学安卓》与之相对应的每一篇文章都 提供了 背景缘由、职责边界 等完整的解析过程

但十分令人遗憾的是,本是从 “实事求是” 出发概括的术语,却频繁被人拿去 “点缀文章” 和 “挂羊头卖狗肉”,这些无厘头的滥用行为,无形中扭曲和破坏了术语 “实事求是” 的形象,

所以过去两年里,我们积极地举报 “培训机构的洗稿软文”,以及在相关文章的评论区补充参考文献来源,

非常感谢小伙伴们的主动反馈。

本质概括一览

基于深度思考,我们确立下来并广泛传播的 “本质概括” 包括但不限于:

Jetpack 架构组件本质:

Lifecycle 的本质是解决 “生命周期管理” 的一致性问题

LiveData 的本质是解决 “跨域消息同步” 的一致性问题

ViewModel 的本质是解决 “状态保存恢复” 的一致性问题

DataBinding 的本质是解决 “视图实例的 null 安全” 的一致性问题

Navigation 的本质是解决 “路由初始参数恢复” 的一致性问题

若要说它们有什么共性的话,就是透过各种方式 实现样板逻辑的 “内聚”,从而达到规避一致性问题的目的。

文章来源

《是让人耳目一新的 Jetpack MVVM 精讲》

《是架构组件 “一致性” 概念的全面解析》

·

《为你还原一个真实的 Jetpack Lifecycle》

《就算不用 Jetpack Navigation,也请务必领略的声明式编程之美》

《LiveData 鲜为人知的 身世背景 和 独特使命》

《有了 Jetpack ViewModel . . . 真的可以为所欲为》

《从 被误解 到 真香 的 Jetpack DataBinding》

声明式 UI 本质:

声明式 UI 的本质是函数式编程,

函数式编程的基石是纯函数,

纯函数的特性是 只有一个入口、只有一个出口,且无副作用,

声明式 UI 正是通过对视图实例的屏蔽,来规避 “视图实例的 null 安全” 的一致性问题,

也即声明式 UI 可用于替代 DataBinding 等框架,

如果公司项目执意使用 Java,为了规避 null 安全问题,务必使用 DataBinding 等框架,

如果允许使用 kotlin,那么当下 kotlin + ViewBinding 的组合是更优解

文章来源

《是 “一通百通” 的 声明式 UI 扫盲干货》

《从 被误解 到 真香 的 Jetpack DataBinding》

架构模式本质:

MVP 的本质是基于 “依赖倒置原则” 实现组件的可替换,适合非页面开发场景的编写(具体可参见我开源的 Linkage-RecyclerView 中万用的适配器),

MVVM 的本质是基于 “数据绑定” 来解决视图实例 null 安全一致性问题,也即它是专用于页面开发的模式,

当我们剔除了 DataBinding 框架而使用 Compose 或 kotlin + ViewBinding 等方式来规避一致性问题,虽然效果是等同的,但已不能称作是 MVVM。

文章来源

《如何让同事爱上架构模式、少写 bug 多注释》

《是让人提神醒脑的 MVP、MVVM 关系精讲》

LiveData 的那些事:

LiveData 的设计存在缺陷。

一方面它提供了面向 “事件” 的设计,

这使得我们萌生了通过 “决策权收紧” 的结构(也即所谓 “唯一可信源”)来确保 “消息分发可靠一致” 的目的成为可能,

另一方面它权当自己是 “状态”,而仅提供粘性的设计,

正是这种令人迷惑的设计,导致了所谓 “数据倒灌” 现象的发生。

要想弄清楚 “唯一可信源” 和 “数据倒灌”,得先正确理解和区分 “状态” 和 “事件”。

文章来源

《LiveData 唯一可信源 读写分离设计 独家解析》

《LiveData 数据倒灌 背景缘由全貌 独家解析》

开源项目一览

包括 腾讯音乐、字节跳动直播 在内的诸多厂商或团队,参考过或正在使用我们开源和维护的《脚手架》等项目,

https://github.com/KunMinX/Jetpack-MVVM-Scaffold

解决 LiveData 数据倒灌问题的 UnPeek-LiveData

https://github.com/KunMinX/UnPeek-LiveData

解决 Navigation 转场卡顿的 Smooth-Navigation

https://github.com/KunMinX/Smooth-Navigation

我和 Flywith24 合作开发维护的 Jetpack MVVM - Java to Kotlin 示例

https://github.com/Jetpack-Missionary/Jetpack-From-Java-To-Kotlin

作为依赖倒置原则 MVP 的 Linkage-RecyclerView

https://github.com/KunMinX/Linkage-RecyclerView

对未来的展望

《重学安卓》发展至今,已从单纯的写作专栏,演化为高手云集的社群,这里平均每两周一位小伙伴告知自己入职字节跳动,也有来自 HencoderPlus 的小伙伴不断加入,

关于写作,《重学安卓》一直保持初心,只写揭露本质的 “深度思考” 文章,授人以鱼且授人以渔。

比起无原则的盲目扩充,我们选择慎重选题和长期修订打磨,确保能恰到好处地覆盖到 关于某领域的 来龙去脉、各式场景、最新动态,

并且考虑到部分读者有截图收藏的需要,我们逐步为专栏文章增设 “语录卡片”,方便已订阅的读者保存到手机、随时查看、以及通过二维码直达原文重温。

最后,感谢小伙伴们一直以来的关心和支持!

独家记忆 | 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