不是，Model应当是业务逻辑；它是做为结果的列表？反倒是现在不仅持有了ViewModel，还会和一群Intent耦合，这明显是增加耦合。对于复杂界面只订阅一个State的话会痛苦不堪的。MVI整出个“唯一数据源”原来是为了减少模板代码
MVC：Model-View-Controller
MVP：Model-View-Presenter
MVVM：Model-View-ViewModel
MVI：Model-View-Intent
● 与MVC，MVP或MVVM一样，MVI是一种体系结构设计模式，可帮助我们更好地组织代码以创建健壮且可维护的应用程序
● 它与Flux或Redux属于同一家族，由AndréMedeiros首次引入；该首字母缩略词是由“模型”，“视图”和“意图”这两个词的紧缩形成的
为什么推荐使用MVI，MVI是基于什么提出的答：主要为了ViewModel层和View层的交互由双向转化为单向，并且规范交互数据传输
● android端由mvc到mvp再到mvvm最后到mvi，每一次的变化都让代码分层更加清晰，目前MVVM的缺点是ViewModel和view的交互还是属于双向交互，viewModel和Model的处理界限也比较模糊，所以提出MVI，MVI其实是基于MVVM， 在View和ViewModel中增加了Intent来作为中间传输，通过响应编程更新UI实现的
● 这样不仅规范View与ViewModel交互，且将交互顺序由View—>ViewModel->View 的双向交互变为View->Intent->ViewModel->State->View的环形交互，通过Intent和State来解决ViewModel与Model的界限模糊问题
● 也就是说ViewModel现在可以不关心如何被view触发，如何刷新UI，也不关心当前有多少数据模型，只用来维护Intent和state管理（再直白些就是intent就是view调用viewModel的中间层，state就是viewModel回调view的中间层，model通过intent和state去管理，看起来会更加简洁）
为何使用MVI模式● 我曾经有一个瞬间觉的个人Model定义全都是错的；通过在各类安卓开发论坛也好主题也罢的讨论和头疼的研究
● 不管如何，最终我选择使用rxjava和Model-View-Intent（MVI）的方式构建响应式的安卓应用程序，就像这种组合我之前是没有尝试过同样，我建立是十分被动的
● 固然，你也会，可是，你会比我好不少
Model 的定义定义的诚然，有不少模式将"View"和"Model"分离
● 定义的在安卓开发领域最出名的当属Model-View-Controller(MVC),Model-View_Presenter(MVP)和Model-View-ViewModel(MVVM)。你能够从名字看出什么东西么？他们都有Model；可是，我发现大多数时间，我根本没有用Model
例子：仅仅是在后台加载一个persons的列表，一个传统的MVP模式的代码是这样的:
class PersonsPresenter extends Presenter<PersonsView> {public void load(){getView().showLoading(true); // 显示一个加载进度条backend.loadPersons(new Callback(){public void onSuccess(List<Person> persons){getView().showPersons(persons); // 显示人列表}public void onError(Throwable error){getView().showError(error); // 显示错误信息}});}}可是到底什么是"Model"?后台请求是Model?不是，Model应当是业务逻辑；它是做为结果的列表？不是，它仅仅只作一件事情，就是咱们View显示所须要的东西，像加载指示器或错误信息；所以，真正的Model“长”什么样的？
若是按照我对View的理解，那么，Model类应当是这样的:
class PersonsModel {// 在真实的项目中，须要定义为私有的// 而且咱们须要经过getter和setter来访问它们final boolean loading;final List<Person> persons;final Throwable error;public(boolean loading, List<Person> persons, Throwable error){this.loading = loading;this.persons = persons;this.error = error;}}那么Presenter应该“长”这样的:多线程
class PersonsPresenter extends Presenter<PersonsView> {public void load(){getView().render( new PersonsModel(true, null, null) ); // 显示一个加载进度条backend.loadPersons(new Callback(){public void onSuccess(List<Person> persons){getView().render( new PersonsModel(false, persons, null) ); // 显示人列表}public void onError(Throwable error){getView().render( new PersonsModel(false, null, error) ); // 显示错误信息}});}}● 如今在屏幕上的View有了一个将被渲染上去的Model；这个概念其实不是什么新概念；最开始的被Trygve Reenskaug在1979年定义的MVC模式的Model的定义几乎一致：View观察Model的变化
● 不幸的是，MVC这个术语被滥用来描述太多不一样的模式，它们与最原始的MVC定义有了出入。例如，后端工程师使用MVC框架，iOS工程师有ViewController，在安卓开发中MVC的真正含义是什么？Activities是Controller?那么ClickListener意味着什么?如今MVC与最初被Reenskaug定义的MVC来说，这个术语被误解，滥用和错误使用
Model须要解决咱们在安卓开发中常常遇到的问题：● 状态问题
● 屏幕方向问题
● 在页面堆栈中导航
● 进程死亡
● 单向数据流的不变性
● 可调试和可重现的状态
● 测试
MVI详解1、Intent 是为了让 View和 ViewModel 更加解耦。这一点连自圆其说都做不到。View 依然持有 ViewModel，解耦从何谈起？反倒是现在不仅持有了 ViewModel，还会和一群 Intent 耦合，这明显是增加耦合。
2、Intent使得View 和 ViewModel的契约更加清晰。说的没错，View 向 ViewModel 发送命令的全集能通过 Intent 一览无余，但浏览ViewModel的公共方法不是有同样的效果吗？
3、MVI 强调对UI State的集中管理，只需要订阅一个 ViewState便可获取页面的所有状态，相对 MVVM 减少了不少模板代码。
对于复杂界面只订阅一个 State 的话会痛苦不堪的（详见“真唯一数据源”小节）。MVI 整出个“唯一数据源”原来是为了减少模板代码？完美避开了重点~
4、对于 State 来说添加状态只需要添加一个属性，降低了ViewModel与View层的通信成本，将业务逻辑集中在ViewModel中，View层只需要订阅状态然后刷新即可
难道 MVVM 中增加状态不是添加一个属性？难道 MVVM 中 View 层不是订阅状态即可？难道 MVVM 中业务逻辑不是集中在 ViewModel 中？
5、MVVM 的痛点之一：当页面复杂时，需要定义很多 State,并且需要定义可变与不可变两种,状态会以双倍的速度膨胀，模板代码较多且容易遗忘 这不是 MVVM 的痛点，而是使用不当造成的副作用。MVVM 中的 M 被错误的理解并使用，如果它能做到唯一可信数据源，就不存在该痛点了。另外 MVI 中数据持有者也有可变和不可变两个版本，这样做是为了确保唯一可信数据源
MVI架构次要有以下长处1、强调数据单向流动，很容易对状态变动进行跟踪和回溯，在数据一致性，可测试性，可维护性上都有肯定劣势
2、强调对UI State的集中管理，只须要订阅一个ViewState便可获取页面的所有状态，绝对 MVVM 缩小了不少模板代码
3、增加状态只须要增加一个属性，升高了ViewModel与View层的通信老本，将业务逻辑集中在ViewModel中，View层只须要订阅状态而后刷新即可
● 当然在软件开发中没有最好的架构，只有最合适的架构，各位可依据状况选用适宜我的项目的架构，实际上在我看来Google在指南中举荐应用MVI而不再是MVVM，很可能是为了对立Android与Compose的架构
● 因为在Compose中并没有双向数据绑定，只有单向数据流动，因而MVI是最适宜Compose的架构。
● 当然如果你的我的项目中没有应用DataBinding，或者也能够开始尝试一下应用MVI，不应用DataBinding的MVVM架构切换为MVI老本不高，切换起来也比较简单，在易用性，数据一致性，可测试性，可维护性等方面都有肯定劣势，后续也能够无缝切换到Compose
小结● MVI 用数据流来理解界面刷新：界面是数据流的起点（生产者）也是终点（消费者），界面发出的数据叫事件，事件会用响应式编程的方式被变换为状态，最终状态又流向界面，界面通过消费状态完成刷新；在这个流动的过程中，若保证了唯一可信数据源，就能实现单向数据流
● 所以 MVI 和 MVP, MVVM 不同，它关心的不是具体的界面状态持有者，而是整个更新界面的数据链路流动方式和方向
尾述私信 发送 底层源码 即可 免费获取 完整代码 以及 更多学习笔记 、 面试视频
技术是无止境的，你需要对自己提交的每一行代码、使用的每一个工具负责，不断挖掘其底层原理，才能使自己的技术升华到更高的层面
Android 架构师之路还很漫长，与君共勉
PS:有问题欢迎指正,可以在评论区留下你的建议和感受；
欢迎大家点赞评论，觉得内容可以的话，可以转发分享一下
,
