作为Android最常用的架构，MVC、MVP与MVVM这三个架构已经是很成熟了，即使现在还有模块化与插件化等方式的架构，MVP与MVVM依然是开发者常采纳的方案。所以无论你是想进阶成为一名高级工程师，还是跳槽大厂进行面试的时候，那么MVC/MVP/MVVM三个架构的熟练掌握与使用一定是必备条件之一。
那么接下来接给大家来分享一下MVC/MVP/MVVM之间的相互联系与优劣势分析，以及还有一些大厂常问的关于MVC/MVP/MVVM面试题。希望在大家架构学习之路上给予一些帮助。另外的文末的话我也会给大家分享一套MVC/MVP/MVVM具体学习使用手册，其中还包含MVC
MVC全名是Model--View--Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。其中Model层处理数据，业务逻辑等；View层处理界面的显示结果；Controller层起到桥梁的作用，来控制View层和Model层通信以此来达到分离视图显示和业务逻辑层。
我们往往把Android中界面部分的实现也理解为采用了MVC框架，常常把Activity理解为MVC模式中的Controller。
看似没有什么特别的地方，但是由几个需要特别View是把控制权交移给Controller，自己不执行业务逻辑。Controller执行业务逻辑并且操作Model，但不会直接操作View，可以说它是对View无知的。View和Model的同步消息是通过观察者模式进行，而同步操作是由View自己请求Model的数据然后对视图进行更新。MVC的优缺点优点：
1. 把业务逻辑全部分离到Controller中，模块化程度高。 当业务逻辑变更的时候，不需要变更View和Model，只需要Controller 换成另外一个Controller就行了（Swappable Controller）。
2. 观察者模式可以做到多视图同时更新。
缺点：Controller测试困难。因为视图同步操作是由View自己执行，而View只能在有UI的环境下运行。在没有UI环境下对Controller进行单元测试的时候， Controller业务逻辑的正确性是无法验证的：Controller更新Model的时候，无法对View的更新操作进行断言。View无法组件化。View是强依赖特定的Model的，如果需要把这个View抽出来作为一个另外一个应用程序可复用的组件就困难了。因为不同程序的的Domain Model是不一样的MVPMVP其实是MVC的一种演进版本，它更简单，将MVC中的Controller改为了Presenter，View通过接口与Presenter进行交互，降低耦合，方便进行单元测试。
View：负责绘制UI元素、与用户进行交互(Activity、View、Fragment都可以做为View层)；Model：对数据的操作、对网络等的操作，和业务相关的逻辑处理；Presenter：作为View与Model交互的中间纽带，处理与用户交互的逻辑。可以把Presenter理解为一个中间层的角色，它接受Model层的数据，并且处理之后传递给View层，还需要处理View层的用户交互等操作。关键点：
View不再负责同步的逻辑，而是由Presenter负责。Presenter中既有业务逻辑也有同步逻辑。View需要提供操作界面的接口给Presenter进行调用。（关键）对比在MVC中，Controller是不能操作View的，View也没有提供相应的接口；而在MVP当中，Presenter可以操作View，View需要提供一组对界面操作的接口给Presenter进行调用；Model仍然通过事件广播自己的变更，但由Presenter监听而不是View。
MVP（Passive View）的优缺点优点：1. 便于测试。 Presenter对View是通过接口进行，在对Presenter进行不依赖UI环境的单元测试的时候。可以通过Mock一个View对象，这个对象只需要实现了View的接口即可。然后依赖注入到Presenter中，单元测试的时候就可以完整的测试Presenter业务逻辑的正确性。
2. View可以进行组件化。 在MVP当中，View不依赖Model。这样就可以让View从特定的业务场景中脱离出来，可以说View可以做到对业务逻辑完全无知。它只需要提供一系列接口提供给上层操作。这样就可以做高度可复用的View组件。
缺点：Presenter中除了业务逻辑以外，还有大量的View->Model，Model->View的手动同步逻辑，造成Presenter比较笨重，维护起来会比较困难。MVVMMVVM模式（Model--View--ViewModel模式），和MVP模式相比，MVVM 模式用ViewModel替换了Presenter ，其他层基本上与 MVP 模式一致，ViewModel可以理解成是View的数据模型和Presenter的合体。
MVVM采用双向绑定（data-binding）：View的变动，自动反映在ViewModel，反之亦然，这种模式实际上是框架替应用开发者做了一些工作（相当于ViewModel类是由库帮我们生成的），开发者只需要较少的代码就能实现比较复杂的交互。
MVVM的调用关系和MVP一样。但是，在ViewModel当中会有一个叫Binder，或者是Data-binding engine的东西。以前全部由Presenter负责的View和Model之间数据同步操作交由给Binder处理。你只需要在View的模版语法当中，指令式地声明View上的显示的内容是和Model的哪一块数据绑定的。当ViewModel对进行Model更新的时候，Binder会自动把数据更新到View上去，当用户对View进行操作（例如表单输入），Binder也会自动把数据更新到Model上去。这种方式称为：Two-way data-binding，双向数据绑定。可以简单而不恰当地理解为一个模版引擎，但是会根据数据变更实时渲染。
关键点：
MVVM把View和Model的同步逻辑自动化了。以前Presenter负责的View和Model同步不再手动地进行操作，而是交由框架所提供的Binder进行负责。
只需要告诉Binder，View显示的数据对应的是Model哪一部分即可。
MVVM的优缺点优点：1. 提高可维护性。 解决了MVP大量的手动View和Model同步的问题，提供双向绑定机制。提高了代码的可维护性。
2. 简化测试。 因为同步逻辑是交由Binder做的，View跟着Model同时变更，所以只需要保证Model的正确性，View就正确。大大减少了对View同步更新的测试。
缺点：过于简单的图形界面不适用，或说牛刀杀鸡。对于大型的图形应用程序，视图状态较多，ViewModel的构建和维护的成本都会比较高。数据绑定的声明是指令式地写在View的模版当中的，这些内容是没办法去打断点debug的。常见面试笔试真题Android中的MVC是什么？有什么特点？参考回答：
M：Model，数据模块，提供数据；
V：View，UI模块，视图层；
C：Controller，控制模块，相当于Activity。
Controller操作Model层的数据，并且将数据返回给View层展示。Activity既要处理Controller的逻辑也要处理View的逻辑，导致Activity的代码过于臃肿。View层和Model层之间耦合性大，导致不易于维护和扩展。
用过MVP构建过项目吗？谈谈你对它的认识。参考回答：
MVP就是在MVC上增加了一个接口，因此也降低一层耦合度，这样View就不会直接访问Model。
Presenter完全将Model和View解耦，主要逻辑都集中在Presenter中。和View没有直接关联，因为它能通过View中定义好的接口进行交互。这样当View需要修改的时候，就不用去Presenter里改动。View层就只需处理跟UI有关的逻辑即可。
MVP低耦合、重用方便，而且测试也方便，但使用了接口去设计逻辑复杂的页面时也会导致代码中接口过多或庞大。
简单说一下你是如何使用MVP去构建一个项目的。参考回答：
我们可以按照MVP的各个模块去设计代码。
1）首先定义Model，创建好Model接口和回调接口，接着就是创建一个实现类，重写Model接口里的方法；2）接着就是设计View模块，负责UI展示与操作；•3）用Activity去实现这个View接口；•4）创建Presenter，互相持有对象，让View和Model能交互；•5）最后用Activity创建Presenter对象并且调用它的方法来处理业务逻辑
以上便是整个MVP构建项目的思路，并不是一定要该思路，要结合实际情况去考虑。
Model-View-ViewModel，对比MVP，就是将Presenter替换为ViewModel。ViewModel和Model/View进行了双向绑定。当View发生改变时，ViewModel会通知Model进行更新数据。而Model数据更新后，ViewModel会通知View更新显示。因为Data Binding能将数据绑定到xml中， 而且还有ViewModel和LiveData等，使得MVVM用起来更加方便。
要说MVVM就真的完美吗？也不是，因为它使得数据与视图双向绑定了，所以当出现问题的时候不好找到出错源头，是数据问题还是视图属性修改导致的，可能需要时间去寻找。所以使用的时候要注意。
模块化是什么？它与组件化又有什么区别？参考回答：
通常一个项目会采用下面的架构，如图所示：
产品层：即应用层，如果有三个项目，则该层有三个块；
通用业务层：放置公司多个项目的通用业务模块，这些模块是跟业务有关，比如文件等资源下载和上传；
基础层：基础库，比如网络请求，图片压缩等逻辑模块、通用UI模块和第三方库。
而通常新建一个app项目时是按照类型划分的（activity、fragment、view、和utils等等），或者按照业务划分，每个业务模块就是一个包，每个包再按照不同类型细分下去。
模块化是一种软件设计技术，它能将项目的功能拆分为独立、可交换的模块。每个模块都包含执行单独功能的必要内容。而组件化也是设计技术，它强调将一个软件系统拆分为独立的组件，而这些组件可以是模块也可以是web资源等。
两者目的都是重用和解耦，主要区别在于模块化侧重于重用，组件化更侧重于业务解耦。
如果要构建一个项目，该选择MVC还是MVP，亦或是MVVM？参考回答：
如果要构建的项目简单不是很复杂的时候，其实不需要使用构建模式来构建项目的，因为这样的项目不需要太大改动，只需封装好每个模块，然后要使用的时候直接调用即可。
如果要构建的项目主要是展示UI和数据，为了更友好地与用户交互，比较适合使用MVVM来构建，因为该类项目的大多数业务逻辑都集中在后端，而势必要经常对视图进行改动，所以使用MVVM能非常好地进行视图属性修改。
如果要构建的项目要处理较多业务逻辑或者是属于工具类app的，那就使用MVP比较合适，使用MVVM也是可以的。
当然，MVC也不是说就用不上，平时也可以使用MVC来构建一些学习项目来一层一层地进行封装。
总结以上，可以看到。从MVC->MVP->MVVM，就像一个打怪升级的过程。后者解决了前者遗留的问题，把前者的缺点优化成了优点。同样的Demo功能，代码从最开始的一堆文件，优化成了最后只需要20几行代码就完成。当然，以上也只是对MVX三种架构模式之间的区分和优缺点做了简单阐述，好让大家对MVX三种架构模式能有一个清晰的认识，同时也希望可以给对这些模式理解比较模糊的同学带来一些参考和思路。
另外如果想要对MVX三种架构模式进行进阶深入学习的同学，我这边整理了一份《Android架构开发手册》，也就是我在开头说的包含MVX进阶学习+大厂架构实战演化+Jetapck全套组件学习的218页的PDF学习笔记。整理不易，有需要的同学，可以点赞本文支持下，然后私信来找我获取！
Android架构开发手册目录
Android架构开发手册内容
