响应式编程

响应式编程是相对于命令式编程来说的。

命令式编程就是“叫你做一件事情，做完之后，就没有然后了”，比如：

val a = 1
val b = 2
var c = a + b // 3
a = 2
b = 2

当 c = a + b 执行完毕之后，c 的值就定格在 3，之后不管 a 和 b 的值如何变化，c 的值都不会受影响。可见命令式编程是 “一次性赋值”。

而响应式编程是 “持续地赋值”，将上面的例子做响应式的改造：

val flowA = MutableStateFlow(1)
val flowB = MutableStateFlow(2)
val flowC = flowA.combine(flowB) { a, b -> a + b }
coroutineScope.launch {
    flowC.collect {
        Log.v("ttaylor","c=$it")
    }
}
coroutineScope.launch {
    delay(2000)
    flowA.emit(2)
    flowB.emit(2)
}
// 打印结果如下
// c=3
// c=4

构建了两个流A，B，并指定初始值分别为1和2。使用 combine 将AB合流为C，用于求和。当订阅 flowC 时，第一个和值在流上生成。当流AB持续变化值之后，流C的值也会随之而变。

响应式编程是一种面向数据流和变化传播的声明式编程范式 “数据流”和“变化传播”是相互解释的：有数据流动，就意味着变化会从上游传播到下游。变化从上游传播到下游，就形成了数据流。

“声明式”意思是定义流上数据变换的逻辑并不是立刻执行，只有当数据流流动起来之后才会执行。

单向数据流

用户界面是持续变化的，那是不是可以用数据流来理解界面持续的变化？

界面变化是数据流的末端，界面消费上游产生的数据，并随上游数据的变化进行刷新。

若用数据流来理解界面刷新，就必须抽象出两个“数据”。

第一个数据是从界面发出的事件（意图），即 MVI 中 I（Intent）。在 MVP 和 MVVM 中，界面发出的事件是通过一个 Presenter/ViewModel 的函数调用实现的，这是命令式的。为了实现响应式编程，需把这个函数调用转换成一个数据，即Intent。

第二个数据是返回给界面的状态，即 MVI 中的 M（Model），它通常被称为状态State，从字面就可以感觉到界面状态是会时刻发生变化的。

从界面发出的数据叫Intent，而界面接收的数据叫State，这样整个界面的刷新流程就形成一条Unidirectional Data Flow（UDF），即单向数据流：

当然还可以把数据流过网络，数据库的线路也画出来，这样就会形成更大的圆环，但数据流的方向还是单向的。

（上图不是单向数据流的完全形态，后续文章会结合项目实战代码继续深入分析，欢迎持续关注~）

当然也可以把 ViewModel 换成 Presenter，单向数据流依然成立。图中 ViewModel 这个位置可以是任何其他东西，只要它满足下面三个要求：接收界面事件、存储界面状态、并以响应式编程的方式将事件转换为状态并推送给界面。

“单向数据流”是“唯一数据源”的必然结果，即触发界面刷新的只有唯一数据源。因为如果有多个数据源的话就会变成下面的状态：

此图就像 demo 中第一个版本的代码一样，更新视图状态的代码散落在 Activity 的各个地方，难以维护，容易出bug。

单向数据流为啥一定要 Intent？若没有 Intent，则界面的意图是通过散落在各处的方法调用表达的，如下图所示：

当用数据类 Intent 来表达界面意图之后，不同类型的意图就好像被集线器约束进了一条数据管道中。

这样做有什么好处？

View 和 ViewModel 之间的契约变得更加清晰：

class FeedsActivity : AppCompatActivity() {
    private val refreshLayout: RefreshLayout
    // 界面的意图流
    private val intents by lazy {
        merge(
            // 初始化 Feeds
            flowOf(FeedsIntent.InitIntent(1, 5))
            // 加载更多 Feeds 
            loadMoreFeedsFlow()
        )
    }
    // 将下拉刷新回调改造成流
    private fun loadMoreFeedsFlow(): Flow<FeedsIntent> = callbackFlow {
        refreshLayout.setOnRefreshListener {
            trySend(FeedsIntent.MorePageIntent)
        }
        awaitClose()
    }
}

上述代码摘自如何把业务代码越写越复杂？（二）| Flow 替换 LiveData 重构数据链路，更加 MVI。

该界面包含两个意图，初始化 Feeds 流和加载更多，它俩被组织成 FeedsIntent，并且保存在一个流 intents 中。然后只需要收集这个流，就能实现将意图发射给 ViewModel。（更多代码细节可以点击上面的链接）

对界面发出的所有事件，有了统一控制的能力。

对界面事件统一的控制能力，可以让解决方案变得简单，比如点击防抖。

通常对于单个控件的点击防抖可以这样做：

val FAST_CLICK_THRSHOLD = 300
fun View.onDebounceClickListener( block: (T) -> Unit ) {
    // 如果不是快速点击，则响应点击逻辑
    setOnClickListener { if (!it.isFastClick) block() }
}
// 判断是否快速点击
fun View.isFastClick(): Boolean {
    val currentTime = SystemClock.elapsedRealtime()
    if (currentTime - this.triggerTime >= FAST_CLICK_THRSHOLD) {
        this.triggerTime = currentTime
        return false
    } else {
        return true
    }
}
// 记录上次点击时间
private var View.triggerTime: Long
    get() = getTag(R.id.click_trigger) as? Long ?: 0L
    set(value) = setTag(R.id.click_trigger, value)

但如果是多个控件的点击防抖，用这个思路就很变扭了，比如下面这个场景：

https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9ac2fbc750c649f4903a0a70e6a2e389~tplv-k3u1fbpfcp-zoom-in-crop-mark:1512:0:0:0.awebp?

当视频播放完毕后，会展示视频图片，标题，重播按钮。此时滚动推荐流，播放器会折叠成粉色的色带，点击色带视频会重头开始播放。点击色带后快速点击下面推荐流视频，会跳转到另一个播放页，返回时，前一个视频处于播放完的状态，但屏幕一片漆黑。

这是多控件点击防抖的场景，若把该界面发生的所有点击事件都抽象成 Intent，所有的 Intent 处于同一个数据流中，那做不同控件的点击防抖就很轻松。

MVP - MVVM -【MVI】

特意给 MVI 套上了一个括号，因为我觉得它和前面两者不在一个层面。

它们的命名规则就非常地不一样。

它们中的 V 是没有争议的，代表着 View，即界面展示。

MVP 中的 P 是界面状态持有者，全名都给你想好了，叫 Presenter

同样地，MVVM 中的 VM 也是界面状态持有者，不仅全名帮你想好了（ViewModel），代码都帮你写好了（androidx.lifecycle.ViewModel）。

Android 最新的架构图中，把界面展示+界面状态归为UI层：

所以 MVP 和 MVVM 在定义中强行指定了“界面状态持有者”这个实例。当然它们不仅仅是状态持有者，它们还负责生产界面状态，即业务逻辑生产界面状态。

但它们中的 M 的定义就非常让人摸不着头脑了。

M 通常被解释为“获取数据的能力”，也就是说它不仅代表着数据，还包括了获取数据的方式：

图中的紫色部分都是 M。

但 M 明明是 Model，模型（名词）。Trygve Reenskaug，MVC 概念的发明者，在 1979 年就对 MVC 中的 M 下过这样的结论：

The View observes the Model for changes

看来我们一直用不太正确的方式使用着 M，就像“真唯一数据源”那一小节举得反例一样。因为在 MVP，MVVM 是使用中，始终没有一个真正的 M，所以才导致了混沌。

MVI 中的 M 和 V 也是同样的意思，即模型和视图。M 和 V 在三个架构中的语义是一模一样的。

但奇怪的是，MVI 中并没有强调界面状态持有者这个角色，反倒是增加了一个 Intent。这就和前两者的命名规则不太一样了。

这就容易产生迷雾了，我一开始以为下面的做法就是 MVI 全部的奥义：只要将界面状态持有者的若干个函数调用合并成一个发送 Intent 的函数，通过不同的 Intent 参数进行区分事件。

现在我明白了：Intent 就是在提示你，将原先命令式的函数调用转换成一个事件数据，用响应式编程的方式进行事件到状态的变换，并且还得保证界面状态有唯一可信数据源，这样界面的刷新就形成了一条单向数据流。

所以只要满足“响应式编程”、“单向数据流”、“唯一可信数据源”这三个原则的都可以称之为 MVI。不管使用的是 ViewModel 还是 Presenter。MVI 关心的不是具体的界面状态持有者，而是整个更新界面数据链路的流动方式和方向。

使用 MVP 模式产生 MVI 的效果的例子可以点击 A Model-View-Presenter / Model-View-Intent library for modern Android apps (github.com)

上述 demo 的演绎了如何进行“唯一可信数据源”的改造，但还未进行响应式编程的改造，所以并未形成单向数据流，限于篇幅原因，会在我是怎么把业务代码越写越复杂的（二）| Flow 替换 LiveData 重构数据链路，让代码更加 MVI中详解介绍。

迷雾

至此，网上对 MVI 的“迷雾”就不攻自破了，但我还是想攻一下~：

Intent 是为了让 View 和 ViewModel 更加解耦。

这一点连自圆其说都做不到。View 依然持有 ViewModel，解耦从何谈起？反倒是现在不仅持有了 ViewModel，还会和一群 Intent 耦合，这明显是增加耦合。

MVI 强调对 UI State 的集中管理，只需要订阅一个 ViewState 便可获取页面的所有状态，相对 MVVM 减少了不少模板代码。

对于复杂界面只订阅一个 State 的话会痛苦不堪的（详见“真唯一数据源”小节）。MVI 整出个“唯一数据源”原来是为了减少模板代码？完美避开了重点~

对于 State 来说添加状态只需要添加一个属性，降低了ViewModel与View层的通信成本，将业务逻辑集中在ViewModel中，View层只需要订阅状态然后刷新即可

难道 MVVM 中增加状态不是添加一个属性？难道 MVVM 中 View 层不是订阅状态即可？难道 MVVM 中业务逻辑不是集中在 ViewModel 中？

MVVM 的痛点之一：当页面复杂时，需要定义很多 State,并且需要定义可变与不可变两种,状态会以双倍的速度膨胀，模板代码较多且容易遗忘

这不是 MVVM 的痛点，而是使用不当造成的副作用。MVVM 中的 M 被错误的理解并使用，如果它能做到唯一可信数据源，就不存在该痛点了。另外 MVI 中数据持有者也有可变和不可变两个版本，这样做是为了确保唯一可信数据源。

使用场景

如果 View 向 ViewModel 发送的是一次性命令，比如进入静态页面拉取数据，有没有必要将一次性命令包装成 Intent？看你喜欢了。其实静态页面不会发生持续的变化，直接一个 viewModel.fetch() 就完事了。

只有当 View 会持续地向 ViewModel 发起命令时，Intent 就有了用武之地。

比如用户在直播间疯狂点击送礼按钮，当然可以在 View 层做点击事件防抖，这样直接在 View 对 UI 事件限流有局限性。比如：若产品希望在前 10 次快速点击时提示“你有点猛，请慢一点~”。超过 10 次还在狂点，就将用户的送礼个数缓存起来，屏幕不停刷新连送次数，但送礼的请求会打包，每 10 次点击调一次接口。

若直接在 UI 层做限流破坏了源数据，就无法在 ViewModel 层拿到完整的点击事件流。按照 MVI 的套路，应该将点击事件封装成 ClickIntent，然后无差别地推向 ViewModel 用于接受该事件的一个管道，该管道通常外面套了一层流 Flow，可以使用各种限流操作符轻松的实现这个效果。

关于 Flow 的应用可以点击Kotlin 异步 | Flow 限流的应用场景及原理