1、MVC
1.3优点
(1) 耦合性降低，MVC本质是分层耦合，减少代码之间的相互影响。
(2) 可扩展性好，由于耦合性低，在增加需求时，改动小，bug出现的机率小。
(3) 有利于代码的维护，MVC三层分工明确，模块职能划分明确。
1.4缺点
随着项目的增大，Activity/Fragment的代码会变得臃肿。
1.5适用场景
适合功能较少，业务逻辑简单，界面不复杂的小型项目
2、MVP
2.3优点
(1) Model与View完全分离，修改互不影响
因为所有的逻辑交互都发生在一个地方Presenter内部，减少了Model与View层之间的耦合度。
(2) Model层可以封装复用，可以极大的减少代码量。
(3) 一个Preseter可用于多个View，而不需要改变Presenter的逻辑（因为View的变化总是比Model的变化频繁）。
(4) 便于测试。把逻辑放在Presenter中，就可以脱离用户接口来测试逻辑（单元测试）
2.4缺点
随着业务逻辑的增加，一个页面可能会非常复杂，UI 的改变是非常多，造成 View 的接口会很庞大，Presenter层的代码也会越来越臃肿。
2.5适用场景
对于业务很复杂的大型APP来说，过多的Model ，View， Presenter，就会造成视觉疲劳，不利于维护和管理；对于业务很简单的小型APP来说，只需要几个类就可以解决的事情，使用MVP会多出一大堆接口，虽然代码层次清晰了，但开发成本变高了。所以MVP适合不大也不小的项目。
3、MVVM
3.3优点
(1) 低耦合。View可以独立于Model变化和修改，一个ViewModel可以绑定到不同的View上，当View变化的时候Model可以不变，当Model变化的时候View也可以不变。
(2) 可重用性。你可以把一些视图逻辑放在一个ViewModel里面，让很多view重用这段视图逻辑。
(3) 独立开发。开发人员可以专注于业务逻辑和数据的开发（ViewModel），设计人员可以专注于页面设计，生成xml代码。
(4) 可测试。界面向来是比较难测试的，而现在测试可以针对ViewModel来写。
3.4缺点
bug不好找，比如界面异常，有可能是View出错，也有可能是ViewModel的业务逻辑有问题，也有可能是Model的数据出错。对于过大的项目，数据绑定会导致内存开销大，而对于简单的项目，使用MVVM有点大材小用。
3.5适用场景
虽然MVVM兼容当下使用的 MVC/MVP 框架。但是不适用于简单的界面和太过复杂的界面。对于简单界面而言，MVVM反而使逻辑复杂化了，对于复杂界面而言，相对应的ViewModel的构建和维护成本就会变的很高。
