浅谈我对MVP的理解

身为半路出家的android小白来说，一开始对MVP并不是很了解，只是听说很好用，会让Activity的工作分工更加明确。由于第一家公司项目并不是很大，我接手的时候看了一下项目结构，采用的是模块化分层，给我的感觉就像是树状图，这个结构给我的感觉好处就是查找某一个页面非常方便，只要顺着模块挨个挨个往下走就能找到，而我后面自己独立开发的项目的总体结构也是采用的的这种。

但是，由于项目并没有将Activity进行分工，前期还行，但是到后面功能的增加，页面的复杂，Activity就变得惨不忍睹。特别是做的一个购物车页面，请求数据的方法写了好多，有些逻辑也是非常的复杂（很多都是大佬们说的谜之缩进）基本上除了一些适配器，数据回调封装，工具类和自定义View其他的都放在了Activity里，这样维护起来非常的不方便，有时候改一个小小的效果，都需要将一个Activity反复的上下拉，看得都觉得累。我现在工作快一年了，我发现这样下去并不行，这样不仅给以后别人维护造成不便，而且这也不是一个优秀的程序员写的代码。因此我就寻找方法，当然，这种问题百度一下就有很多，而最经典的自然就是MVP模式，一个很流行的android模式，听说MVP是在MVC上改进得来的，但对于MVC都没有接触过的我来说，一开始觉得MVP很难理解，感觉结构是越来越复杂的，并没有网上说的很简洁啊。但是对反复看MVP的例子，也渐渐开始明白了MVP的好处，以下是我对MVP的一些理解。

看了很多MVP的例子，以我个人的角度看来，MVP就是对面向对象，面向接口的应用，将一个Activity的工作进行了分配。首先Activity（V）只负责界面显示，比如控件的显示，动画等等。Persenter（P）负责逻辑处理，比如请求数据，调配V和M。Model（M）负责数据处理，比如数据存储，调用。各部分的功作大概就是这样，然后就是我之前说的MVP主要就是对面向对象的应用，因为P同时拥有V和M实现的引用，可以通过对应实现中的公共方法进行操控，而V也持有P的引用，可以通过P的公共方法来启动P或者从P那里获取处理过后的数据进行显示。而一些不需要数据的结果可直接通过接口回调进行显示。总之就是将Activity的显示，逻辑，数据存储等分离出来，同时V，P，M由于不在一个Activity里，所以可以进行单独开发，也就是本来必须一个人干的活，可以分给三个人干了，大大减轻一个人时的负担。

总结：MVP的好处就是实现功能模块的解耦，使每个模块独立，减小Activity的代码量，让代码看起来更加清爽，维护更加方便。但是也有一个缺点，需要增加很多接口和类，加重整个项目结构的复杂度，因此，我觉得对于简单的界面采用普通方式就好，改动较大，页面复杂，逻辑复杂的界面MVP无疑更加合适。还有一个RxJava也是一个不错的框架，正在学习中。。。。