深知大多数程序员,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上鸿蒙开发知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
在后续的应用领域发展过程中,存在共性问题,便引入了这些设计,并结合自身特点进行了拓展。
接下来我们聊一聊理念,不比武功。
图片出自电影一代宗师
MVI的理念
MVI
脱胎于 Model View Intent
- Intent:驱动model发生改变的意图,以UI中的事件最为常见;
- Model:业务模型,包含数据和逻辑,是对应
客观实体
的程序建模
; - View:表现层的视图,以UI方式呈现Model的状态(以及事件),接受用户输入,转换为UI事件
官方的这幅图很好的呈现了三者之间的驱动关系:
这张图非常简单,它摒弃了驱动方式的细节,只体现了角色与驱动关系。
注意,只要设计中满足 角色和驱动关系
符合上图,就是MVI架构设计,并不限制 驱动方式的实现细节
经典的MVI驱动细节要比上图复杂很多,下文再聊。
从软件设计的原则出发:职责分离并封装
的目的是 解耦
、 可独立变化
、复用
。
显然,区别于 MVVM
、 MVP
、 MVC
,角色上的差别在于 ViewModel、Presenter、Controller、Intent四者,而它们又是View和Model之间的纽带。除此之外,V和M亦稍有不同。
MVC、MVP
MVC、MVP 中,C和P的职责体现为 控制、调度
。
MVP中 V
和 M
完全解耦可独立变化,MVC中 M
直接操作 V
耦合高,在web应用中,C
需要直接操作DOM。
MVVM
MVVM中,提倡 数据驱动
, 数据源
被剥离到 VM
中,在 双向绑定框架
的加持下,View层的输入反映为数据的变化,数据的变化驱动视图内容。
显然,VM的职责限于维护数据状态,如有必要,驱动View层消费数据状态, 不必再关注如何操作视图。
一般来说,双向绑定框架已经引入观察者模式实现,可响应式驱动,VM一般没有必要关心 响应式驱动和下游观察者生命周期问题
简单思考之后会发现MVVM的问题,它的侧重点在于 利用双向绑定让开发者专注于数据状态的维护,从操作视图更新中得以解放
,它难以解决 无天然状态
问题,例如:按钮点击这类事件。
MVI
在MVI中,结合业务背景将UI事件等内容转换为 Intent
,驱动Model层业务,Model层的业务结果反映为 视图状态
+ 事件
。
因此View层和Model层之间已经解耦,并可以吸收MVVM中的优点采用如下设计:
- 将双向绑定退化为单向绑定,View层消费UI状态流和事件流,这也意味着UI状态的职责精简,它不再承载View层的用户输入等事件
- 将UI状态独立,Model层仅产生
UI状态的局部变化
和事件
下图为经典的MVI原理示意图:
在上文中,我们已经讨论了各个角色的职责,下面逐步展开讨论角色具备的特性和细节知识。
在此之前,还请谨记:合适的才是最好的
没有绝对的最好的设计,只有最合适的设计。
再好的架构,都需要遵循其理念并结合项目因地制宜地进行调整,以获得最佳使用效果。所以请读者诸君务必在阅读时,结合自身项目的情况仔细思考以下问题:
- 引入新框架所解决的痛点、衍生的问题、是否需要进行框架调整?
- 框架中的角色功能,为什么出现,又有怎样的局限?
单向数据流动
MVI拥抱了结构复杂,但能够灵活应对业务编码时的各种情况,按部就班即可。
从MVI原理图中,可以清晰的看到 “数据” 的流动方向。 起始于 Intent
,经过分类和选择性消费后产生 Result
,对应的reducer函数计算后,得到最新的 State
(以及裂变出必要的 Event
,图中未体现) ,驱动视图。
注意:
单向
是指 单一方向- 此处的
数据
是广义的、宽泛的。 - 仅描述数据流的 变化方向 ,与数据流的数量无关,但一般 形成有效工作 均需要两条数据流(上行数据流和下行数据流)
即驱动数据流变化的方向是唯一的,在英文中的术语为:Unidirectional Data Flow
简称 UDF
。
MVC、MVP中的痛点
前文我们提到,在MVC和MVP中,着眼于 控制、调度 ,并不强调 数据流
的概念。
View和Model间之间的交互,一般有两种编码风格:双向的API调用、单向的API调用+回调:
注意:以下两图并未体现Controller和Presenter细节,仅表意,从View层出发的API调用和回到View层的UI更新
双向API调用如上图。
单向API调用+回调更新UI如上图。
显而易见,这两种方式无法继续抽象,需根据实际业务进行命令式编码。当UI复杂时,难以写出清晰、易读的代码,维护难度激增。
MVVM解决UI更新代码混乱问题
前文我们已经提到:MVVM中通过绑定框架,将UI事件转化为数据变化,驱动业务;业务结果表现为数据变化,驱动UI更新。
显而易见,维护朴素的数据要比直接维护复杂的UI要简单。
但问题也同时产生,data1的变化有两个可能的原因:
- Model层业务结果使其变化,并期望它驱动UI更新
- View层发生事件,反馈数据变化,并期望它驱动Model层逻辑
因此,框架需要考虑标识数据变化来源、或者其他手段消除方向性所带来的问题。
并且MVVM难以灵活决定的 “何时调用Model层逻辑”,即大多数业务中,都需要结合多个属性的变化形成组合条件来驱动Model层逻辑。
本篇并不重点讨论MVVM,故不再展开MVVM解决循环更新的方案,以及衍生的问题。
尽管如此,MVVM中的数据绑定依旧解决了View层更新繁杂的问题。
用Intent灵活决定何时调用Model
既然数据驱动UI有极大的益处,且View层事件驱动ViewModel的数据变化有很多弊端 (需要建立很高的复杂度) ,那自然需要 趋利避害
仅保留数据驱动UI的部分,并增加Intent用以驱动Model层业务
在于 MVC/MVP
以及 MVVM
对比后不难得出结论:
- MVC/MVP中,View层通过调用C/P层API的方式最终调用到Model层业务,方式质朴、无难度。但业务量规模增大后接口方法数也会增多,导致C/P层尾大不掉,难以重用。
- MVVM中,VM层总是需要利用
技巧
进行模型概念转换,以满足业务响应满足实际需求,需要很深厚的设计经验才能写出非常优秀的代码,这并不友好。
作者按:我个人认为一个友好的设计,不应当剑走偏锋,而应当大巧不工,能够以力破法,达成 “使用者只需要吃透理论就可以解决各类问题” 的目标。
而MVI在架构角色中设计了Intent的角色:
- 它包含了业务调用的意图和数据
- 从设计上可满足
调用
与实现
的分离 - 架构模型中以Intent流的形式出现,下游对其的
筛选
、转换
、消费
等行为可遵循FP范式
(即函数式编程范式、Functional Programming Patterns) ,逻辑的复用粒度为方法级,复用度更高更灵活 - 解决了MVVM中的方向性问题、MVC/MVP 中的灵活度问题等
单一可信数据源
我猜测读者诸君都曾听过这个词,将 单一可信数据源
拆解一下:
- 单一
- 可信
- 数据源
在MVI背景下,数据源
指的是视图对应的数据实体,它代表视图的内容状态。
可信指从数据源中获取的数据是 最新的
、完整的
、可靠的
,否则是不可信的,我们没有理由在编码中使用不可信的数据源。
单一是指这样的数据源仅一个。
在经典设计中,其内涵如下图:
- 按照视图的 所有的 内容状态,定义一个不可变的
ViewState
- 按照业务初始化 ViewState 实例
- Model业务生成驱动 ViewState变化的Result
- 计算出新状态,Reduce(Pre-ViewState,Result) -> New-ViewState
- 更新数据源
- View层消费ViewState
借助于数据绑定框架,可以很方便地解决视图更新的问题。
想象一下,此时页面UI非常复杂……
如果僵化的信奉这样的 单一
,情况会如何呢?
- 复杂(大量属性)的ViewState
- 复杂的UI更新计算,e.g. 100个属性变了2个,依然需要计算98个属性未变或者全量强制更新
在 APP-A和APP-B中,我分别使用了 DataBinding和Compose,但均无法避免该问题。
何为单一
从机器执行程序的原理上看,我们无法实现 多个内容一致的数据源 在 任意时刻 满足 最新的
、可靠的
。
将视图视为一个整体,规定它只拥有 一个 可信的数据源。在此基础上看局部的视图,它们也顺其自然地仅拥有一个可信的数据源。
反过来看,当任意的局部视图仅具有一个可信数据源时,整体视图也仅有一个逻辑上的可信数据源。
据此,我们可以对 经典MVI实现
进行一定程度的改造,将ViewState进行局部分解,使得UI绑定部分的业务逻辑更 清晰、干净。
请注意,复杂度不会凭空消失,我们为了让 “UI绑定的业务逻辑更清晰、干净”、“更新UI的计算量更少”,将复杂度转移到了ViewState的拆分。拆分后,将具有 多个视图部件的单一可信数据源,注意,为了不引起额外的麻烦、并且便于维护扩展,建议遵守以下条件:
- 基于业务需求,组合数据源形成新数据源
- 不在数据源的逻辑范围之外进行数据源组合操作
举个虚拟的例子:用户需要实名认证 且 关注博主 ,才在界面上显示某功能按钮。下面使用代码分别演示。
考虑到RxJava的广泛度依旧高于Kotlin-Coroutine+flow,数据流的实现采用RxJava
注意,考虑到读者可能会编写demo做UDF局部的验证,下文中的代码以示例目的为主,兼顾编写场景冒烟的方便性,流的类型不一定是构建完整UDF的最佳选择。
经典实现
在经典MVI实现中,需要先定义ViewState
data class ViewState(
/unique id of current login user/
val userId: Int,
/true if the current login user has complete real-name verified/
val realNameVerified: Boolean,
/true if the current login user has followed the author/
val hasFollowAuthor: Boolean
) {
}
并定义ViewModel,创建ViewState流,忽略掉其初始化和其他部分
class VM {
val viewState = BehaviorSubject.create()
//ignore
}
并定义View层,忽略掉其他部分,简单起见暂时不使用数据绑定框架
class View {
private val vm = VM()
lateinit var imgRealNameVerified: ImageView
lateinit var cbHasFollowAuthor: CheckBox
lateinit var someButton: Button
fun onCreate() {
//ignore view initialize
vm.viewState.subscribe {
render(it)
}
}
private fun render(state: ViewState) {
imgRealNameVerified.isVisible = state.realNameVerified
cbHasFollowAuthor.isChecked = state.hasFollowAuthor
someButton.isVisible = state.realNameVerified && state.hasFollowAuthor
//ignore other
}
}
在JS中,JSON并不能附加逻辑,基本等价于Java中的POJO,故在数据源外部处理简单逻辑的情况较为常见。而在Java、Kotlin中可以进行适当的优化,适当封装,使得代码更加干净便于维护:
data class ViewState(
//ignore
) {
fun isSomeFuncEnabled():Boolean = realNameVerified && hasFollowAuthor
}
class View {
//ignore
private fun render(state: ViewState) {
//…
someButton.isVisible = state.isSomeFuncEnabled()
}
}
拆分实现
依旧先定义逻辑上完整的ViewState:
class ComposedViewState(
/unique id of current login user/
val userId: Int,
) {
/**
- real-name-verified observable subject,feed true if the current login user has complete real-name verified
- */
val realNameVerified = BehaviorSubject.create()
/**
- follow-author observable subject, feed true if the current login user has followed the author
- */
val hasFollowAuthor = BehaviorSubject.create()
val someFuncEnabled = BehaviorSubject.combineLatest(realNameVerified, hasFollowAuthor) { a, b -> a && b }
}
定义ViewModel,子模块数据流均已定义,故而无需再定义全ViewState的流
class VM(val userId: Int) {
val viewState = ComposedViewState(userId)
//ignore
}
编写View层的UI绑定,同样简单起见,不使用数据绑定框架
class View {
private val vm = VM(1)
lateinit var imgRealNameVerified: ImageView
lateinit var cbHasFollowAuthor: CheckBox
lateinit var someButton: Button
fun onCreate() {
//ignore view initialize
bindViewStateWithUI()
}
private fun bindViewStateWithUI() {
vm.viewState.realNameVerified.subscribe {
renderSection1(it)
}
vm.viewState.hasFollowAuthor.subscribe {
renderSection2(it)
}
vm.viewState.someFuncEnabled.subscribe {
renderSection3(it)
}
//…
}
private fun renderSection1(foo:Boolean) {
imgRealNameVerified.isVisible = foo
}
private fun renderSection2(foo:Boolean) {
cbHasFollowAuthor.isChecked = foo
}
private fun renderSection3(foo:Boolean) {
someButton.isVisible = foo
}
}
例子较为简单,在实际项目中,如果遇到复杂页面,则可以分块进行处理。
注意:实际情况中,并没有必要将每一个子数据源拆分到一个View级别的控件,那样过于啰嗦,例子因非常简单而无法丰满起来。 e.g. 针对每一块视图区,例如作者区域,定义子ViewState类,创建其数据流即可。
作者按:务必评估,在一次Model业务产生的Result中,会引起数据流下游的更新次数。 为避免产生不可预期的问题,可通过类似以下方式,使下游响应次数表现和经典实现的情况一致。
额外定义PartialChange流或者功能等价的流,它用于标识 reduce
计算的开始和结束,可以将此期间的数据流的变化延迟到最后发送终态
更加推荐定义功能上等价的流
class ComposedViewState(
/unique id of current login user/
val userId: Int,
) {
internal val changes = BehaviorSubject.create()
//ignore
val someFuncEnabled =
BehaviorSubject.combineLatest(realNameVerified, hasFollowAuthor) { a, b -> a && b }.sync(PartialChange.Tag, changes)
}
inline fun <reified T, S> Observable.sync(tag: S, sync: BehaviorSubject): Observable {
return BehaviorSubject.combineLatest(this, sync) { source, syncItem ->
if (syncItem == tag) {
syncItem
} else {
source
}
}.filter { it is T }.cast(T::class.java)
}
修改PartialChange,为reduce函数添加边界:
PartialChange是Model产生的Result的表现物,封装了ViewState的reduce函数逻辑,即如何从 Pre-ViewState 生成 新 ViewState
sealed class PartialChange {
open fun reduce(state: ComposedViewState) {
}
/**
- 同步标记,从头开始到真实PartialChange之间,流的状态生效
- */
object Tag : PartialChange()
object None : PartialChange()
class Foo(val a: Boolean, val b: Boolean) : PartialChange() {
override fun reduce(state: ComposedViewState) {
state.changes.onNext(Tag)
state.realNameVerified.onNext(a)
state.hasFollowAuthor.onNext(b)
state.changes.onNext(this)
}
}
}
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
Foo(val a: Boolean, val b: Boolean) : PartialChange() {
override fun reduce(state: ComposedViewState) {
state.changes.onNext(Tag)
state.realNameVerified.onNext(a)
state.hasFollowAuthor.onNext(b)
state.changes.onNext(this)
}
}
}
[外链图片转存中…(img-z24XC37Y-1715507523212)]
[外链图片转存中…(img-Ct1UOclG-1715507523213)]
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!