C200b24c74810fa7296f8a2b1a710e2d
重学安卓:是架构组件 “一致性” 概念的全面解析

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

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

·

注:本文以《让人耳目一新的 Jetpack MVVM 精讲》 以及

《GitHub:Jetpack MVVM Best Practice》 作为前置知识,假设小伙伴已完整查阅并吸收了上述内容。

前言

很高兴见到你!

《为你还原一个真实的 Jetpack Lifecycle》篇起,Jetpack MVVM 架构组件系列文章修订至今 已陪伴大家走过 1.5 个年头,

在与小伙伴们 实事求是的交流和互动 中,我们一起演化和完善了《脚手架》开发模式 以及《UnPeek-LiveData》《Smooth-Navigation》《Strict-DataBinding》等衍生的开源库。

这期间也时不时有小伙伴私下寒暄说,他们在公司的新项目中用上《脚手架》的开发模式。

关于 “一致性问题” 等概念的理解

当然,尽管 专栏是同一个专栏,作者是同一个作者,对知识的吸收程度却往往是天差地别。

在过去一年里,绝大多数读者都十分自觉地借助 对专栏文章的通读对配套项目的调试 来完成前置知识的铺垫 —— 功课有没有做、做的程度如何,其实稍微走点心都能从 提问者的提问 中听出来。

有不少小伙伴曾为《深度思考原则》篇给到的启发 而私下表示感谢,其中不乏有小伙伴出于共鸣而在写作平台输出了自己关于 “有效思考和学习” 的见解。(例如《把知识看做一个语义树,从根到叶地学习》篇)

与此同时,也存在极个别 “演艺圈” 人士,进群大半年 却好像穿越来的,偶尔冷不丁冒个泡做些 “迷惑行为” 然后离奇消失。

就比如对 “一致性问题” 这个概念的理解,有的人文章都没来得及看一眼,就急忙表示对这个概念很抵触、很 “上火”,认为不够形象、不够通俗易懂、不足以迎合自己的主观感觉;

也有人可以不再拘泥于概念本身,而是能从实际出发 私下和我 行云流水地交流 刚入职的互联网大厂的项目架构现状,以及他对症下药给出的解决方案。

所以这压根就不是什么 “通不通俗” 的问题,而是更为源头的 “态度” 的问题。

解铃还须系铃人

正如电影《教父》的经典台词说道 —— “那些花半秒钟就看透事物本质的人,和花一辈子都看不清事物本质的人,注定是截然不同的命运” —— “凡事凭感觉拿捏” 亦或是 “坚守实事求是”,两种态度注定是导向截然不同的结果。

正如《深度思考原则》篇中分别就 “浅度思考” 和 “深度思考” 举的 “上火” 和 “发炎” 两个例子,或许 “上火” 从主观上更容易理解、更形象、更有感觉;或许 “发炎” 听起来更抽象、更专业、更与自己的好恶不沾边,

然而概念往往并不只是概念本身,而是包含了其背后一整个思维模式 —— 有什么样的思维就可能产生什么样的概念 —— 从 “实事求是” 思维出发产生的概念,就只能通过 “实事求是” 的思维去理解

—— 实事求是思维 关注的从不是概念本身,而是基于实事求是的态度,对事件的背景和结构 确立有相对全面的理解,以便对症下药地 解决问题。所谓的概念,也不过是这个过程中出于交流方便的需要 而衍生的副产品。

(就比如我们老生常谈的 “内卷”,理解它的人 明白它只是对特定现象的称谓,对它有情绪的人则执意认为这是在 “装 X” …… 又比如我们在《深度思考原则》篇的举例 —— 当我们谈到 “发炎” 时,我们实际上是在讲 “机体在酸碱、病毒等因素的刺激下发生以防御为主的发热反应”,由此我们才得以借对 “事情的本质是发炎” 的理解,来采取 “杀毒”、“平衡酸碱” 等正确措施,而不是主观上觉得 “上火”、觉得 “又热又痛”,就去买冰棍吃。)

考虑到专栏几乎每一篇文章都是严格遵循《深度思考原则》的理念来编写,因而在原则性的问题上,很难做出迎合让步,《重学安卓》专栏文章的演化和完善,无一不是 实事求是思考交流 的结果,

所以若是真的想理解和驾驭一门技术,务必先借助《深度思考原则》自行负责把功课做好,不然也 很难构成有效交流

文章目录一览

  • 前言
  • 关于 “一致性问题” 等概念的理解
  • 解铃还须系铃人
  • 为什么对 “一致性” 的解析要单独拎出来讲
  • 到底什么是一致性、什么是一致性问题
  • 关于 “解决一致性问题” 的举一反三
    • Lifecycle 是通过 ____ 来实现 生命周期管理的一致性
    • LiveData 是通过 ____ 来实现 消息同步的一致性
    • DataBinding 是通过 ____ 来实现 视图调用的 null 安全一致性
  • 综上

为什么对 “一致性” 的解析要单独拎出来讲

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

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

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

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

因此为了正本清源、还原术语的本来面貌,我们单独出了这样一期,来举一反三地演绎和重申 “一致性” 的本义及其在 “软件工程” 背景下的重要意义。

当然,小伙伴们如在外部平台看见 “未注明链接出处” 的滥用行为,请及时向我举报,我去相关文章评论区补充参考文献,以尽可能降低日后你在职场遇见 “喜欢拿道听途说的术语来压你” 的人的概率。

到底什么是一致性、什么是一致性问题

当我们谈论 “一致性” 时,我们通常是特指 “结果的一致性”,例如 项目中存在多处雷同的代码,当设计因需求发生改变时,我们务必在 修改 A 处的同时,记得修改 B 处。而 “一致性问题” 即,我们 修改 A 处的同时,忘记了修改 B 处

这种因疏忽而导致的不可预期的问题,是十分普遍的,造成疏忽的原因也是千奇百怪的(例如 A 处是同事 A 负责的,B 处是同事 B 负责的,同事 A 事先并不知道同事 B 也 copy 了一份同样的代码,于是在后续修改时就可能疏忽),

所以本着 “求之于势、不责于人” 的态度,对于这类问题,我们不能苛责开发者务必做到 “不疏忽”,而是考虑 通过 “内聚” 等方式来在幕后 默默地把这些问题给规避

所以简单来说,“一致性问题” 即 潜在的 “结果不一致”,或者通俗地说就是 “改了 A 处,忘了 B 处”;而 “一致性的目标” 即做到 “一处修改,处处生效、处处同步一致”。—— ©KunMinX

关于 “解决一致性问题” 的举一反三

所以下面我们就结合 Jetpack MVVM 架构组件来举一反三,之前阅读过 架构组件系列文章 的小伙伴也可借此机会重温,看看自己对 “一致性” 以及 “一致性问题” 的理解,是否与原文的本义相契合。

Lifecycle 关注的是生命周期管理的一致性

Lifecycle 解决的一致性问题主要体现在哪里呢?—— 体现在生命周期管理。

top Created with Sketch.