Android MVI与MVC和MVVM相比有什么区别

“较新的”模型视图意图体系结构与“较旧的”模型视图意图体系结构（如MVC和MVVM）之间是否存在差异

MVI解决了什么问题？与MVC/MVVM有什么相似之处？有什么区别

关于MVC/MVV/MVP的stackoverflow已经有了类似的问题，但到目前为止还没有一个问题能够解释MVI

---

这里有一个非常好的细分：。MVI的核心是采用MVVM（无状态UI状态）的思想，分离业务逻辑和模型，并将反应式框架置于其之上。使事物成为事件流而不是离散动作，使接收元素成为转换流的消费者而不是表示元素，并使状态成为只读的、可丢弃的事物，以非常结构化的方式显式地作用

这要求您采用功能性方法来编写应用程序，尤其是UI/视图部分。状态未被修改，新状态是根据意图和一系列用例计算的。这在这里得到了很好的解释：

---

它旨在解决现代UI应用程序日益复杂的问题，这些应用程序需要显式管理大量的客户端状态。正如大多数经验丰富的程序员所知，最复杂的故障来自于以意外方式修改的状态。这种状态操纵可能导致应用程序无法处理的“无效”状态，这实际上是一个崩溃的应用程序。MVI通过使状态转换明确并精心组织来解决这一问题，这样它们就不会进入无效状态，并且状态总是可以理解的。

根据我的经验，这些架构模式的每一个都是为了解决前一个被忽略或未被观察到的特定问题而发明的

MVC-模型视图控制器

在UI应用程序中，最初将数据呈现到屏幕或业务逻辑并将它们绑定在一起的责任并不明确。因此MVC将这些职责定义为三个组件，每个组件都有一个目的，图中描述了这三个组件之间的关系

视图-是一个UI组件，它具有所有属性，如颜色、形状和工具，用于侦听单击事件。。等等

模型-是定义业务逻辑的组件，您希望视图呈现该逻辑并相应地进行操作

控制器-是更改模型的人，因此，如果视图有一个名称（例如要保存），则视图将其传递给控制器，然后控制器使用正确的操作操纵模型

MVP-模型视图演示者

MVC的问题是，这三个组件之间存在很大的耦合，如果要更改视图调用，则需要更新控制器和模型。 从MVC图中可以清楚地看到，这三个组件之间的关系非常紧密，如果没有另一个组件，就无法替换其中一个组件。 因此，MVP通过分离模型和视图来为前面的问题提供更干净的解决方案，通过Presenter保持它们之间的交互，Presenter是每个视图和模型调用的中间人。 因此，如果要保存收藏夹电影列表，请查看listen to user（*）操作，然后调用更新模型的presenter函数，然后model告诉presenter是否成功，presenter告诉视图显示正确的消息

MVVM-模型视图视图模型

随着反应式范式的兴起，很明显，我们可以通过观察变化并在其上进行操作，在UI应用程序中提供更多独立的关注点。 例如，有一个点击视图需要调用api来获取最新的电视节目

此视图单击将在ViewModel处观察到，ViewModel与模型交互以获取数据，最后ViewModel使用其他观察者将这些数据发布到视图上

简而言之，查看观察视图模型以获取UI更新，查看模型观察视图以调用模型的正确操作。观察者模式已经证明了他在解耦逻辑中的价值，所以现在我们来看一个新的模式

---

因此，在讨论了最流行的体系结构模式之后，每个模式都试图将UI代码与业务代码分离。但是之前的模式并没有将更新UI与不同的状态绑定在一起

如果您有一个与加载相关的问题，并且同时显示了一条错误消息，那么您将理解我所说的，因此为了维护UI状态，您必须额外努力查找导致此类问题的错误代码

MVI-模型视图意图

MVI基于一个叫做有限状态机的旧思想，任何系统或组件都具有可预测的状态集，即有限状态机。 在MVI中，任何对UI的更新都是由新状态定义的，您可能会发现这是无法抗拒的，但是想象一下，每当UI发生变化时，您都有一个屏幕截图，这就是状态。您现在可以调试、测试和重现状态问题

如何实现这一点，这就是MVI在实践中的作用。 在MVI中，用户与UI的任何交互都是由一个意图定义的，意图是用户在此操作中所需要的，它可以是一部电影，刷新屏幕，甚至可以是打开屏幕，在这种情况下，意图是显示屏幕上所有所需数据的初始意图

哪一个组件得到了这些意图并根据它们采取行动，这就是您定义的。。您可以使用Presenter或ViewModel，这无关紧要，MVI更多的是一种实践，而不是使用新的中间组件

我将继续使用ViewModel，ViewModel将获得这些意图，决定调用哪个用例（模型行为）

所有用例都经过ViewModel中的summer函数，该函数决定