谷歌官方推荐的MVI基本使用

近年来，谷歌的应用框架不断推陈出新，从MVC，MVP，MVVM，到如今官方推荐使用的MVI架构。作为开发者时刻关注着技术的更新迭代，毕竟还是要靠技术吃饭。今天抱着学习的态度，我们一起了解一下Android架构的演进史以及MVI到底有什么优势值得让谷歌官方推荐使用。篇幅较长，请耐心阅读。

MVC

MVC架构是最早接触的Android架构，主要有三部分组成：View ，Model 层，Control 层。

• View层主要负责UI界面的展示。
• Model层负责提供界面展示所需要的数据。
• Control 控制层用来连接View层与Model层，处理业务逻辑。

我们来看一下三者之间的关系，如下图：

在MVC架构中，Activity既充当View层又充当Control层，不仅负责UI界面的渲染还负责处理复杂的交互逻辑，导致Activity中代码十分臃肿庞大，耦合性高，维护起来非常困难。

MVP

MVP的出现很好的解决了MVC的一些难点，通过代码分层将Activity中的各项职能隔离开来，以接口回调的形式进行数据通信。

在MVP中，Persenter层负责处理复杂的业务逻辑，同时处理Model层传递过来的数据。Model层与Activity之间只能通过Persenter层进行通信，降低了Model层与Activity的代码耦合性。保证了Activity的单一职责原则。但是Persenter层持有Activity中view的引用，处理不当容易发生内存泄漏。另外随着业务的增多，需要更多的接口进行数据的回调。

MVVM

MVVM是现在使用最普遍的架构。

• Model层负责提供页面展示需要的数据。
• View层负责展示页面。
• ViewModel层负责处理数据。

通过使用Databinding将View层ViewModel之间进行数据双向绑定。View层通过观察ViewModel层的数据变化而主动进行UI刷新。而且ViewModel还可以通过Lifecycle自行管理生命周期，及时释放资源，避免发生内存泄漏。

如果只看关系图的话，MVVM与MVP没有什么区别，但实现原理上却不同，MVP通过接口回调的形式，被动的接收Persenter层传递过来的数据。MVVM是以观察者的身份，通过观察数据的变化主动刷新UI。

简单介绍完前面三种架构，那么MVI到底是什么，为什么能让谷歌官方如此推荐？下面我们通过代码一起来看一下。

MVI主要是借用了前端的思想，通过数据的单向流动将页面状态和事件分离，主要分成以下几个部分：

• Model :这里的Model是指页面的状态，如页面加载状态，View控件的显示状态等。而不是MVVM的Model。
• View : 能够接收Model层的UI status变化，同时也能通过Intent事件对页面进行显示变化
• Intent ： 将用户的操作事件包装成Intent事件，交给Model层进行数据处理。而不是activity中的Intent。

各模块之间的关系如下图:

下面我们通过实例代码来简要说明：

1. 定义网络的三种状态，doSuccess 成功，doFailure 失败，doLoading 加载中。
2. 新建一个ViewModel类。

初始状态为NetResource.doLoading 加载状态，当网络返回成功或失败时，将状态回调通知给View层，View层需要对状态进行监听。

1. View层监听网络数据状态。

根据观察到的不同网络返回状态，进行数据处理或页面展示。

1. 最后我们通过用户的操作，定义了三种意图事件。

1. 用户通过主动触发不同的意图事件，进行不同的网络数据请求。

1. 我们将用户的操作意图封装成NetWorkEvent事件，根据不同的操作进行相对应的事件处理，最后将数据通过同一个Status状态进行处理。

对比MVVM，MVI的数据是单向流动的，从意图到数据请求，最后反馈给页面处理。页面接收用户的意图事件而产生不同的数据请求。通过使用同一个状态处理不同的意图事件。形成了一个闭环的事件操作。只需要在View层监听一次，就能够处理不同的意图事件了。

相信看到这里，你对在Android 中如果使用MVI有了一定了解，然而MVI并不一定就是最好的选择，根据具体业务选择合适的架构才能有效的提高工作效率。