前言
简述Android一些架构模式
1、MVC
2、MVP
3、MVVM
MVC
这是一个很早就使用的架构模式
MVC：Model(模型) View(视图) Controller(控制器) 主要就是分层，让他们职测分开
在android中 Model比作你写的XXXBean，View相当于xml界面，Controller相当于Activity/Fragment
描述：在View上做了一个点击操作，Controller会去请求网络返回数据，再通过Model（Bean）赋值到View上。
当然在android上 xml是在Activity中使用的，所以像是 Controller/View 与 Model 相互交流
优缺点：
有一定的分层，Controller和View并没有彻底解耦
Activity负担过重，需要兼顾网络请求、逻辑处理和View交互，和后台开发不一样，早期的Web主要由服务器返回显示界面，浏览器只负责渲染，但现在前端技术由js、vue等等代替，而后端只负责业务逻辑 和 返回数据，V和C已经分离。但在Android上，View分离不了，所以一旦业务增加、复用等问题的出现就会发现MVC代码会“糊”在一起，就算分包开发也会比较麻烦，再加上Git多人开发来回的push、pull，emmmm。。。。并不是说MVC不好，只能说MVC用在Android上可能不太合适。
MVP
这个应该是绝大部分分app使用的架构模式
MVP：Model(模型) View(视图) Presenter(节目主持人？！)
网上人家的图，从图上看Presenter负责处理View和Model，主持人没毛病
Model：负责存储、操作数据
View：相当于Activity/Fragment,显示数据
Presenter：从Model拿数据，管理一些状态，决定要显示什么
描述：在View上做一个操作，Presenter告诉Model，让他请求返回数据,Presenter在与View交互显示
优缺点：降低了耦合度，实现了Model和View真正分离，Presenter相当于中间人处理Model和View
和MVC很像，但层次清晰，Presenter用接口实现，可以更好的单元测试
Presenter可以复用，代码灵活
但Presenter任务比较重了，会出现很多接口和实现类，除了会生成一些文件，还是很适合用于安卓开发，易上手，成本低。
MVVM
MVVM：M:Model,V:View,VM:ViewModel
Model：还是负责存储、操作数据
View：还是相当于Activity/xml
ViewModel：这里的Model 和上面的Model不是一回事，这里的Model是View的 Model，通俗的说就是把xml变成了可直接操作的对象
描述：View只做UI的工作，不涉及其他业务、数据等，ViewModel只做业务相关工作。
MVVM是一种架构模式，在安卓中DataBinding是实现这种模式的框架。
优缺点：解耦更加彻底、在MVP中，在P层需要持有V层的y引用，才能刷新View，在MVVM中，有了双向绑定一方改变会通知另一方，使得ViewModel基本不用去关心View了，也不会出现MVP中，很多接口。
缺点：由于双向绑定，数据出问题会非常难定位，也不利于重用，一个View对应一个ViewModel，在安卓上最常见的就是重用View了，所以对于不同的模块，就不能直接重用了。从测试上来说，对于界面就比较难测了，基本只能对ViewModel测试了。成本相对较高，开发人员需要会使用DataBinding。
总结
综合来看，基本上不会使用MVC来开发安卓了（抬杠：也不是不可以），基本上也是在MVP和MVVM之间选择，各有各的好，也各有各的捞，合适才是最好的。私以为，如果项目中都是MVP或者是MVVM，也没有必要全部改为另一个，统一就好。
