【 提问须知 】 #71
Comments
本质概括一览过去两年，基于深度思考，以及基于对大量样本的追踪和反思，我们确立下来并广泛传播的 “本质概括” 包括但不限于： Jetpack 架构组件本质：Lifecycle 的本质是解决 “生命周期管理” 的一致性问题 LiveData 的本质是解决 “跨域消息同步” 的一致性问题 ViewModel 的本质是解决 “状态保存恢复” 的一致性问题 DataBinding 的本质是解决 “视图实例的 null 安全” 的一致性问题 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 的设计存在缺陷。 一方面它提供了面向 “事件” 的设计， 这使得我们萌生了通过 “决策权收紧” 的结构（也即所谓 “唯一可信源”）来确保 “消息分发可靠一致” 的目的成为可能， 另一方面它权当自己是 “状态”，而仅提供粘性的设计， 正是这种令人迷惑的设计，导致了所谓 “数据倒灌” 现象的发生。 要想弄清楚 “唯一可信源” 和 “数据倒灌”，得先正确理解和区分 “状态” 和 “事件”。
开源项目一览包括 腾讯音乐、字节跳动直播 在内的诸多厂商或团队，参考过或正在使用我们开源和维护的《脚手架》等项目， 解决 LiveData 数据倒灌问题的 UnPeek-LiveData 解决 Navigation 转场卡顿的 Smooth-Navigation 我和 Flywith24 合作开发维护的 Jetpack MVVM - Java to Kotlin 示例
作为依赖倒置原则 MVP 的 Linkage-RecyclerView |
如有 bug，请另外 new 一个 issue⚠️ ⚠️ ⚠️
本项目开 issue 规范：
务必注明观点所对应的场景，并附上完整可复现的代码，
不然缺乏一致的前提依据来有效交流！
任何缺乏实证依据和因果逻辑的泛泛而谈，都可能对其他使用者造成困扰。
在发表个人见解前，请先确保自己认真阅读过源码。这是对自己、对作者、对其他读者最起码的尊重。
The text was updated successfully, but these errors were encountered: