一、MVC、MVP、MVVM三者区别及应用
1.MVC
M - model
-SQL、XML、JSON
V - View
-XML Layout，Java View(java代码动态View)
C - Controller
-Activity、Fragment
场景：比如Activity里初始化了一个Button，还要在Activity里处理Button的事件，只有涉及到SQL,XML或JSON等事件的时候才会调用，Activity里有model、Controller的引用，Activity既是View又是Controller，module里可以有也可以没有Activity的引用，如果没有则MVC模式应该是（‘-’表示单向向右，‘=’表示双向）：M-V=C ，有的话是 M=V=C，其实还有M-V-C，M=V-C 不管是哪种都是MVC模型。
优点：有了一定的分层，model层实现了较好的解耦，能够较好地修改业务。
缺点：View和Controller并没有彻底的分离开，Activity中的代码显得很臃肿。
2.MVP
MVP是在MVC的基础上产生的。唯一的差别是Model和View之间不进行通讯，都是通过Presenter完成。
它常见的有两种形式m=v=p或者m-v=p。
把主要业务逻辑放到Presenter中完成，弱化modle，当然放到modle也是可以的。
优点：减少了View层的代码量；通过Persenter完成了View和Model的通信过程；解耦效果比MVC好得多，使我们可以专心的编写每个业务代码 ；某些Persenter可以复用。
缺点：对于业务比较少的使用MVP就显得有点多此一举了，它会增加很多的代码量并且会降低程序的可读性。
3.MVVM
MVVM可以算是MVP的升级版，其中的VM是ViewModel的缩写，ViewModel可以理解成是View的数据模型和Presenter的合体，ViewModel和View之间的交互通过Data Binding完成，而Data Binding可以实现双向的交互，这就使得视图和控制层之间的耦合程度进一步降低，关注点分离更为彻底，同时减轻了Activity的压力。
优点：① 低耦合。视图（View）可以独立于Model变化和修改，一个ViewModel可以绑定到不同的"View"上，当View变化的时候Model可以不变，当Model变化的时候View也可以不变。②可重用性。你可以把一些视图逻辑放在一个ViewModel里面，让很多view重用这段视图逻辑。③ 独立开发。开发人员可以专注于业务逻辑和数据的开发（ViewModel），设计人员可以专注于页面设计。④ 可测试。界面素来是比较难于测试的，而现在测试可以针对ViewModel来写。
缺点：① 如果出现Bug 很难被调试。你看到界面异常了，有可能是你 View 的代码有 Bug，也可能是 Model 的代码有问题。数据绑定使得一个位置的 Bug 被快速传递到别的位置，要定位原始出问题的地方就变得不那么容易了。②一个大的模块中model也会很大，虽然使用方便了也很容易保证了数据的一致性，当长期持有，不释放内存就造成了花费更多的内存。
三者的异同点：(主要在于View和Model粘合方式，实现用户的交互操作以及变更通知)
同：View层是UI层的实现，提供一些交互操作。Modle提供了一些接口供我们的应用获取数据或者，当数据改变的时候发出通知，从外部调用可以实现增删改查等操作。
异：
Controller:View通过调用Controller，Controller调用Model的接口来更新数据（model处于被动模式），model不关心View的实现，View通过观察者模式来监听model的变化。
Persenter:Persenter和Controller一样，接收View的命令作用于model上 ，但不同的是Presenter可以反作用于View,当model发生变化的时会通知Persenter，然后Persenter再通知View。
ViewModel:ViewModel里的’Model’和MVVP里第一个’M’不一样，它是指处理View的属性，或者是View的一些操作，然后通过DataBinding这个技术，使得View的变化会直接影响ViewModel，而ViewModel的变化也会直接影响View。开发者止需要比较少的代码就可以实现比较复杂的交互。
分别适合的场景判断：
1.展示类的App,据大多数逻辑都在后端的，app主要就是展示和交互的使用mvvm。
2.工具类或者需要写很多业务逻辑app，使用mvp或者mvvm。
为什么要使用MVP等架构模式？
答:当项目有一定规模时，使用MVP等框架有助于我们提升代码的可读性，也有利于我们维护和修改。而一个好的软件往往都会尽量符合"低耦合，高内聚"的特点。