非常抱歉，用了这么一个高端大气上档次的标题，实际上我只是简单地分享一下我作为一个业余开发者摸索出来的一点点东西

我搞安卓开发也有段时日了，最开始的时候无非看看书，写写Demo，就这样，随着知识的积累，慢慢的也能写一些简单的东西，比如说以前写的一个用来解压压缩文件到指定目录的加载器，还有有简单功能的文件管理器等等，刚开始代码量不多，直接把代码写在Activity里，但是到后期项目越来越大，Activity的类也越来越臃肿，代码随便就上千行，有时候找个方法要用搜索功能，而且一大堆方法堆在一起，维护代码就变得困难

然后我初次接触了MVP模式，MVP即是Model-View-Presenter的缩写，说到MVP就不得不说说传统的MVC（Model-View-Controller）模式

MVC，M即是Model，是一些实现逻辑，比如说下载文件的相关实现代码。V即是View，实际上是xml布局文件。C，Controller，对应Activity。

MVC咋一看好像没什么不对的，甚至还觉得有点不错。但是思考一下，对于Controller层，既承担了控制View的职责，又负责与Model交互，搞得它有点像Model又像View，而View层实际上几乎啥事都没干，只是布局下控件而已，对于控件的控制，比如说setText，setVisible之类的都由Controller来控制，这就容易造成上文说的，Activity体积很大的问题，还有代码的可维护性差等等

在这种情况下，MVP应运而生，思考一下，MVC主要的矛盾在于View层和Controller层的分工，那么我们把他们的职责重新确定一下，让Activity所在的类划分到View层，将一些专门控制UI的代码放在里面，把原来Controller的代码抽离出来，作为Presenter，也就是MVP里的P，并且让View不要直接与Model层交互，而且通过Presenter与Model交互，这样，让Presenter充当View与Model的桥梁，可以很好地解耦合，使代码的可维护性变高

关于MVC MVP的更详细的介绍可以自己搜索一些详细介绍的文件来学习，这里不再深入讲了，毕竟我自己也学艺不精，怕误导别人

MVP到底如何，因人而异，至少目前网络上大家还是比较推崇的。但是MVP也有一些，就我自己在实践的时候遇到的，Presenter层太厚的问题，当Activity与Fragment多起来后，Presenter就有好几个，还有就是类的数量变多，但是总体来看还是利大于弊吧

继MVP之后，又开始掀起了MVVM的潮流，据说MVVM是官方支持（提倡）的模式，这里就不再说了。其实设计模式更重要的还是思想，它本身的优缺点不能决定一个设计模式的好坏，用的人才能决定，更重要的还是自己的理解，然后再运用到项目里。

如果觉得对MVP不怎么感冒的话，或许可以自己在项目开发中摸索出一套自己的设计模式？毕竟知识总是从实践中得来的嘛。

文中的图片来源于网络。

讲的有些语无伦次，大家多多包涵，看来在下的修为还是远远不够..

为什么你吧没有人影