笔者在研究 MVP 模式的时候查阅过相当多的资料，其中有两句话令我相当的深刻。一是：使用 MVP 模式虽然代码量会大大增加，但是为了降低耦合和逻辑上的简洁这个牺牲是值得的。二是：有些公司是根据代码量来统计工资的，所以使用 MVP 模式对于那些用代码量来统计工资的开发者来说，这应该是一个优点（然而，我们公司的工资和代码量时无关）。我当初就是信了你们的邪，当项目达到一定的程度的时候如果采用网上推荐的方式，重复的代码多到你无法想象好吗？每个 Presenter 都要处理大量重复的逻辑，项目中存在无数个功能相同的 Model（向服务器发起请求和发送回调数据到 Presenter）例如进度条的显示等等。不过当笔者意识到这个问题后，就通过泛型和封装优化了代码，解决了上述的问题，所以就有了前面的四篇文章。但是有一个问题是没办法通过优化代码解决的，那就是 Presenter 的管理问题。

在 MVVM 成熟之前 MVP 模式在 Android 上有被神化的趋势，笔者曾经在商业项目中从零开始大规模采用过 MVP 模式对项目进行开发。在使用 MVP 模式进行开发的时候发现项目的结构模式对开发是有一定的影响的，在这里笔者会对这一问题进行探讨。希望通过这篇 blog 能让读者了解如何使用 MVP 模式搭建一个功能完善的 MVP 模式开发框架，避免一些笔者认为比较严重的问题。

MVP 简介 MVP是模型（Model）、视图（View）、主持人（Presenter）的缩写，分别代表项目中3个不同的模块。如图所示：image View 对应于Activity、Fragment，负责界面的绘制以及与用户交互 Model 依然是业务逻辑和实体模型 Prese…