MVC的层次
MVC分为：Model（数据抽象）、View（视图）、Controller（控制器）的三层架构。接下来我们分别来一一解析每一层所对应的职责分别是什么。
View层：对应的则是Android中的layout文件夹中的xml文件，在启动Activity/Fragment的时候，都会加载一个R.layout.xxx的布局文件，使得在视图中显示出我们在xml中定义好的视图。
Controller层：对应的则是Activity/Fragment。当Activity/Fragment加载了layout文件后，我们需要在Activity/Fragment中findViewById(int)去寻找到相对应的view，并对找到的view设置相应的属性以及监听器。而在设置view的属性之前，我们很有可能会先到model中请求一次数据，当数据回调回来后controller就会去更新view了。
Model层：对应的则是一些DataSource以及DataBean的相关对象，这里的DataSource指的是数据的来源。一般数据的来源有2个主要的地方，一个是sqlite，一个是webservice，而我们习惯于将这两种数据的来源封装在一个repository中，对于调用者而言只需要调用repository中的一个获取接口来获取数据，但是这个数据是从内存中还是sqlite还是webservice来，我们都不得而知，从保护了调用实现的逻辑，分解相关的实现，达到调用者的极度简单与简洁，且在单元测试中测试接口也是非常方便的。
做个比喻吧， Activity Window View
窗框(窗架) 玻璃 玻璃上的窗花
优点与缺点
优点：
逻辑清晰，Controller层和View层在一起的(在一个类里面，在一个Activity或者Fragment)，
层次分明
方便项目的测试和后期的维护
缺点：
Controller层和View耦合性太大
Activtiy类或者Fragment类过于臃肿
MVP的层次
View层:视图层，它所对应的不只是layout中的xml文件还包括了Activity/Fragment作为视图的显示。这样做是扩大了View层的职责所在，View不仅是设置ui的显示和属性并且还包括了生命周期的回调。
Presenter层:主持者层，它相当于是Controller中的业务逻辑部分，它主要是负责view和model层之间的通信，及时的响应view层的请求并主动的调用model层的数据获取，并且将获取到的数据结果返回给view层中。presenter是另外新建立一个class，并且让view从创建的时候就持有一个presenter的实例，当view发生某些请求响应或者生命周期发生变化，则会迅速的向presenter发起请求，让presenter做出响应的处理，比如：刷新数据、清除数据防止泄露等。
Model层：此处的数据抽象层model和MVC中的model层是一样的。
优点与缺点
优点：
逻辑清晰，层次分明 模块职责划分明显
View层与Model层完全解耦，方便项目的测试和后期的维护 以及版本更新迭代
缺点：
每个view有个presenter ，类多了。
个人的理解，有错可以向我提出！