Ee1602fd38a905db74b02c9b644d9235
重学安卓:是 持续增量更新 的 背景缘由甜点

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

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

前言

很高兴见到你!

在过去的 10 个月里,我们通过《视图控制器》系列文章,确知了 Activity / Fragment 各自的 背景由来、设计依据、职责边界,以及它们在具体使用中 所涉及的高频场景,如 页面加载、页面重建、页面跳转、页面通信 等。

紧接着,通过《标准化开发模式》系列文章,我们确知了在 以多人协作为背景 的软件工程下,基于可视化内容开发的场景中 所面临的诸多 容易造成不可预期错误一致性问题,如 页面元素涉及 生命周期管理 的一致性问题;页面重建涉及的 状态恢复;数据请求 和 页面通信 涉及的 事件源一致性问题;视图控件刷新时涉及的 视图调用的一致性问题 等。

再然后,在《视图系统》系列文章中,我们第一次冲出安卓、冲出技术的舒适圈,跨界追根溯源地找寻软件开发的终极答案、站在源码设计师的角度 来设计和重新认识视图系统,并最终以架构师的身份确知了 “数据驱动” UI 框架的本质 及其在软件工程背景下 不可替代的意义。

那么在经过长达 10 个月的演练后,我相信在座的各位 对如何深刻理解和掌握一门技术,已然做到心中有数、如囊中取物。😉

文章目录一览

软件开发只是作为末端的实现

所以今天分享的这一篇,这个 “可能是唯一 持续增量更新 的饭后甜点”,主要有以下三个考虑:

1.注意力要花在刀刃上

但凡有心的小伙伴都会感觉到,不同于互联网上的多数技术专栏,《重学安卓》专栏始终秉持着 宁缺毋滥 且体系化、精进化 的模式经营 —— 从不疯狂扩充文章,反而小心翼翼地控制数量、不断打磨和翻新旧文章 —— 做这么一件看似费力不讨好的事。🤔

为什么呢?

曾有位小伙伴在评论区的留言揭示了真相 —— 互联网上的信息实在太多了,与此同时,我们却对自己 真正需要的东西 知之甚少,乃至于害怕投入注意力去付出,因为看不见付出与收益之间的直接联系。

是的,在面向公众写作之初,便清醒地认识到这一点,如果不能 完全站在目标读者的角度 去提供内容服务,那么不仅不能让读者感觉良好,反而徒添困扰、选择困难。😵

这就好比米其林餐厅的法餐,深夜里当你看到这张图时,你是不是有种 “看起来很小巧紧致、但吃不饱” 的感觉呢?

图片来自网络

图片来自网络

那就对了,正因为它是那么紧致的一小口、而且口味看起来又很好,所以你会放心大胆地一口吃下去,因为这样的注意力付出 对你来说 实在是太容易了、一点也不亏,甚至意犹未尽。

在这个基础上,要是必不可少的每样都能来一点,那么今天这趟就来得太值了、回忆满满。😊

与之相对的是快餐。

快餐的习惯是,一上来就给你满满的一盘,比如青椒炒肉,你要的肉,它给的很少很少(背景缘由 绝口不提),倒是青椒很多很多(通篇贴源码)。看起来好大一盘、看起来完全不会感觉吃不饱,但也提不起食欲、下不了口。

2.总有比刀刃更刀刃的刀刃

尽管目前我们已品尝过《重学安卓》 3 个系列的 “法餐”,而且尽管这 3 个系列已是精挑细选、克制 克制 再克制的结果,我仍然不能保证,没有比它更为紧致和好味的餐点。

我们的生命总长度是有限的,所以 总有些食物是比其他食物更紧致、更好味、更值得优先为我们所体验,但我们甚至连 它们是谁、叫什么、在人生中本该有的地位 都一无所知。

《滑动冲突的快乐你不懂》 一文中,我们冲出技术的舒适圈,去到更为贴近本源的 产品设计的领域 找到了关于某些 普适现象 的答案,其中谈到的 我自己悟出的产品设计原则 —— “用户体验的目标之一 是维持操作的连贯性”,已通过了时间的考验 —— 至今仍有用户不吝吹爆 “《最佳实践》 项目可能是他们用过的 ‘最流畅’ 的软件”。

—— 用户知道 MVVM 和 MVP 甚至 MVC 的区别吗?知道 Jetpack MVVM 在 快速、稳定、减少不可预期错误地开发中 起到的不可替代的作用吗?

很显然,用户不知道也不关心。但一个懂得 “连贯性” 原则的、基于 MVC 开发的软件,和一个基于关注点分离的 Jetpack MVVM、 但对产品设计毫无概念的软件,在用户眼里,哪个看起来 “更健壮、更有技术” 呢?

3.饭后甜点不能当主食吃

《深度思考》 篇,我们确立了一条超级普适的认知原则,可以说,《重学安卓》专栏的每篇文章都是 不遗余力地 在贯彻这条核心原则:

任何技术都绝非凭空存在,一项技术的存在,必有其存在缘由 —— 为了在特定场景下 解决某个或某些问题。

换言之,认识技术,必从认识背景做起 —— 当我们确知了某项技术在特定场景下的不可替代,便是抓住了该技术的本质

因此,当网上还有人在质疑 “LiveData 本来就不是这么用的”、攀比 “SharedViewModel 和 LiveDataBus 哪家强”、吐槽 “DataBinding 不好用” 时,睿智的你 根本不会想要参与 这些无谓的争议,因为一切都是背景说了算 —— 脱离了对潜在问题的确知,任何凭主观喜好、凭感觉的说法都是 画地为牢、瞎扯淡。

能 get 到的背景有多少,对技术的把握就能有多到位,就这么简单。

关于这点,需要我展开一下吗?

要?… 不要?… 要?… 不要?

好嘛,那就只简单地 举一个例子好了,

比如,将 LiveData 用于页面通信(发送事件)的场景,存在 “数据倒灌” 的现象,网上立马有人跳出来质疑,说 LiveData 本来就不该这么用。

然而事实上,关于 页面通信的场景,我们能拼凑出的背景主要有哪几块呢?主要包括:

  • 事件的观察者是页面,但页面可能非激活状态、甚至处于被销毁状态,那么此时在消息回调中接触页面成员 将有生命周期安全的隐患。
  • 事件的观察者必须是页面,对页面的消息推送,不能让其他地方 能够监听和收到 不可预期的推送。
  • 事件的发送者必须来自唯一可信源,最好是在断点调试时,能方便地直接从内存中找到对象、从而追溯到事件源。

是的,面临的背景,至少就有这 3 块,毫不谦虚地说,LiveData + ViewModel 的组合,是目前为止(2020.4)唯一能 超低成本地胜任 上述 3 个问题的解决方案。因而问题也就进一步转化为解决 LiveData 的粘性问题,让它在 页面通信的场景下能符合预期地发生推送。

上述主要想要揭示的是,认识背景 的重要性和优先级。

top Created with Sketch.