Android架构之MVP
讲解Android开发架构MVC、MVP，不定期更新。
具体看例子，写的很好了，包括RxJava，Data-Bindling的，建议自己动手实践一下。
相信大家已经看过很多很多讲解MVC、MVP、MVVM的文章了，为了文章的完整性，还是讲一讲概念与区别。
MVC与MVP
MVC 全称是 Model-View-Controller。
Model：模型，处理数据和业务逻辑
View：视图，用户能够直接感知到的，进行交互的界面。
Controller：作为View与Model沟通的桥梁，起到承接的作用。
在Android上，View表现为各种layout的xml文件；Controller多表现为Activity；Model就是各种和业务数据相关的模块，包括local database、repository、remote server等等。
采用这种结构，Model和View存在耦合，Model上的变化可以直接反应给View，降低了Controller的控制作用，想一想，在你的View中写没写过一些callback，当Model获得数据想返回给View时就调用这个callback。
并且Activity通常变得比较臃肿，几千行的Activity大家应该都有遇到过，有感触的同学在扩展功能、修改功能的时候想必遭受过非人折磨。这就造成了模块的重用、重构、测试、debug都会变的异常困难。
MVP与MVC的不用之处在于Controller变成了Presenter。
View仍旧是视图，在MVP中可以用Activity、Fragment、或者View及View的子类去展示。Google提供的sample中使用的是Fragment，有两个原因，其一，Fragment只负责提供View视图，而Activity只负责创建和连接Fragment与Presenter，一会往下看Sample的结构图你就会知道了，再也不会有上前行代码的Activity了 ：）。其二，平板类的设备或者有多个View的应用使用Fragment会有很多优势，不需要频繁创建Activity，只需要创建Fragment并替换就OK了。当然，根据你各Model的需要，没必要说一定用Fragment。
再往下，Model没有变化，而Presenter和Controller的作用类似，但在MVP中将Model和View完全隔离，将Model获取的数据提供给View，并且执行一些后台任务。回想一下，你在Activity中有没有执行过后台任务？这些后台任务在Activity要结束时可能还没有执行完，Activity的内存并没有及时回收，造成内存泄露，并且有时在屏幕翻转的情况下会引起更严重的后果。这些交给Presenter去解决。
当你想修改某一些功能或者扩展功能的时候直接修改接口，再修改Presenter就可以了，逻辑清晰，维护起来也很容易。避免将很多代码全部写到Activity和Fragment里面，这样逻辑不清晰，维护困难，几千行的Activity你想想看。
我自己动手写了个例子，还没有完善，暂时不上传了。
参考
浙公网安备 33010602011771号