这些术语在 Android 领域是从未有过，网上关于 “一致性问题” 等说辞，它们都有一个共同的来源，
事实上，这些术语都是本人经由长期的深度思考、实践和交流后，为现象本质匹配的高度概括，《重学安卓》与之相对应的每一篇文章都 提供了 背景缘由、职责边界 等完整的解析过程，
但十分令人遗憾的是，本是从 “实事求是” 出发概括的术语，却频繁被人拿去 “点缀文章” 和 “挂羊头卖狗肉”，这些滥用行为，无形中扭曲和破坏了术语 “实事求是” 的形象，
所以过去两年里，我们积极地举报 “培训机构的洗稿软文”，以及在相关文章的评论区补充参考文献来源，
非常感谢小伙伴们的主动反馈。
本质概括一览
基于深度思考，我们确立下来并广泛传播的 “本质概括” 包括但不限于：
Jetpack 架构组件本质：
Lifecycle 的本质是解决 “生命周期管理” 的一致性问题
LiveData 的本质是解决 “跨域消息同步” 的一致性问题
ViewModel 的本质是解决 “状态保存恢复” 的一致性问题
DataBinding 的本质是解决 “视图实例的 null 安全” 的一致性问题
Navigation 的本质是解决 “路由初始参数恢复” 的一致性问题
…
若要说它们有什么共性的话，就是透过各种方式 实现样板逻辑的 “内聚”，从而达到规避一致性问题的目的。
文章来源
·
《就算不用 Jetpack Navigation，也请务必领略的声明式编程之美》
声明式 UI 本质：
声明式 UI 的本质是函数式编程，
函数式编程的基石是纯函数，
纯函数的特性是 只有一个入口、只有一个出口，且无副作用，
声明式 UI 正是通过对视图实例的屏蔽，来规避 “视图实例的 null 安全” 的一致性问题，
也即声明式 UI 可用于替代 DataBinding 等框架，
如果公司项目执意使用 Java，为了规避 null 安全问题，务必使用 DataBinding 等框架，
如果允许使用 kotlin，那么当下 kotlin + ViewBinding 的组合是更优解。
文章来源
架构模式本质：
MVP 的本质是基于 “依赖倒置原则” 实现组件的可替换，适合非页面开发场景的编写（具体可参见我开源的 Linkage-RecyclerView 中万用的适配器），
MVVM 的本质是基于 “数据绑定” 来解决视图实例 null 安全一致性问题，也即它是专用于页面开发的模式，
当我们剔除了 DataBinding 框架而使用 Compose 或 kotlin + ViewBinding 等方式来规避一致性问题，虽然效果是等同的，但已不能称作是 MVVM。
文章来源
LiveData 的那些事：
LiveData 的设计存在缺陷。
一方面它提供了面向 “事件” 的设计，
这使得我们萌生了通过 “决策权收紧” 的结构（也即所谓 “唯一可信源”）来确保 “消息分发可靠一致” 的目的成为可能，
另一方面它权当自己是 “状态”，而仅提供粘性的设计，
正是这种令人迷惑的设计，导致了所谓 “数据倒灌” 现象的发生。
要想弄清楚 “唯一可信源” 和 “数据倒灌”，得先正确理解和区分 “状态” 和 “事件”。
文章来源
开源项目一览
包括 腾讯音乐、字节跳动直播 在内的诸多厂商或团队，参考过或正在使用我们开源和维护的《脚手架》等项目
写在最后
本次我的分享也接近尾声了，感谢你们在百忙中花上一下午来这里聆听我的宣讲，希望在接下来的日子，我们共同成长，一起进步！！！
最后放上一个大概的Android学习方向及思路（详细的内容太多了~），提供给大家：
对于程序员来说，要学习的知识内容、技术有太多太多，这里就先放上一部分，其他的内容有机会在后面的文章向大家呈现出来，不过我自己所有的学习资料都整理成了一个文档，一直在不断学习，希望能帮助到大家，也节省大家在网上搜索资料的时间来学习，也可以分享动态给身边好友一起学习！
为什么某些人会一直比你优秀，是因为他本身就很优秀还一直在持续努力变得更优秀，而你是不是还在满足于现状内心在窃喜！希望读到这的您能点个小赞和关注下我，以后还会更新技术干货，谢谢您的支持！
Android架构师之路很漫长，一起共勉吧！
如果你觉得文章写得不错就给个赞呗？如果你觉得那里值得改进的，请给我留言，一定会认真查询，修正不足，谢谢。
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可获取！
图片转存中…(img-BE34WY2g-1715287552420)]
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可获取！
1386
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
