好了终于要点讲自己的东西了，有点小激动。下面这些仅表示个人观点，非一定之规，各位看官按需取用，有说的不对的，敬请谅解。关于命名规范可以参考我的另一篇文章“Android 编码规范”。老规矩先上图：
MVPBestPractice 思维导图
在参考了 kenjuwagatsuma 的 MVP Architecture in Android Development 和 Saúl Molinero 的 A useful stack on android #1, architecture 之后，我决定采用如下的分层方案来构建这个演示Demo，如下：
分层架构方案
总体架构可以被分成四个部分 ：
Presentation：负责展示图形界面，并填充数据，该层囊括了 View 和 Presenter （上图所示的Model我理解为 ViewModel -- 为 View 提供数据的 Model，或称之为 VO -- View Object）。
Domain：负责实现app的业务逻辑，该层中由普通的Java对象组成，一般包括 UserCases 和 Business Logic。
Data：负责提供数据，这里采用了 Repository 模式，Repository 是仓库管理员，Domain 需要什么东西只需告诉仓库管理员，由仓库管理员把东西拿给它，并不需要知道东西实际放在哪。Android 开发中常见的数据来源有，RestAPI、SQLite数据库、本地缓存等。
Library：负责提供各种工具和管理第三方库，现在的开发一般离不开第三方库（当然可以自己实现，但是不要重复造轮子不是吗？），这里建议在统一的地方管理（那就是建一个单独的 module），尽量保证和 Presentation 层分开。
AndroidStudio 中构建项目
5.1. 关于包结构划分
一个项目是否好扩展，灵活性是否够高，包结构的划分方式占了很大比重。很多项目里面喜欢采用按照特性分包（就是Activity、Service等都分别放到一个包下），在模块较少、页面不多的时候这没有任何问题；但是对于模块较多，团队合作开发的项目中，这样做会很不方便。所以，我的建议是按照模块划分包结构。其实这里主要是针对 Presentation 层了，这个演示 Demo 我打算分为四个模块：登录，首页，查询天气和我的（这里仅仅是为了演示需要，具体如何划分模块还得根据具体的项目，具体情况具体分析了）。划分好包之后如下图所示：
包结构划分
5.2. 关于res拆分
功能越来越多，项目越做越大，导致资源文件越来越多，虽然通过命名可以对其有效归类（如：通过添加模块名前缀），但文件多了终究不方便。得益于 Gradle，我们也可以对 res 目录进行拆分，先来看看拆分后的效果：
按模块拆分 res 目录
注意：resource 目录的命名纯粹是个人的命名偏好，该目录的作用是用来存放那些不需要分模块放置的资源。
res 目录的拆分步骤如下：
1) 首先打开 module 的 build.gradle 文件
res 拆分 Step1
2) 定位到 defaultConfig {} 与 buildTypes {} 之间
res 拆分 Step2.png
3) 在第二步定位处编辑输入 sourceSets {} 内容，具体内容如下：
sourceSets {
main {
manifest.srcFile 'src/main/AndroidManifest.xml'
java.srcDirs = ['src/main/java','.apt_generated']
aidl.srcDirs = ['src/main/aidl','.apt_generated']
assets.srcDirs = ['src/main/assets']
res.srcDirs =
[
'src/main/res/home',
'src/main/res/login',
'src/main/res/mine',
'src/main/res/weather',
'src/main/res/resource',
'src/main/res/'
]
}
}
4) 在 res 目录下按照 sourceSets 中的配置建立相应的文件夹，将原来 res 下的所有文件（夹）都移动到 resource 目录下，并在各模块中建立 layout 等文件夹，并移入相应资源，最后 Sync Project 即可。
5.3. 怎么写 Model
这里的 Model 其实贯穿了我们项目中的三个层，Presentation、Domain 和 Data。暂且称之为 Model 吧，这也我将提供 Repository 功能的层称之为 Data Layer 的缘故（有些称这一层为 Model Layer）。
首先，谈谈我对于 Model 是怎么理解的。应用都离不开数据，而这些数据来源有很多，如网络、SQLite、文件等等。一个应用对于数据的操作无非就是：获取数据、编辑（修改）数据、提交数据、展示数据这么几类。从分层的思想和 JavaEE 开发中积累的经验来看，我觉得 Model 中的类需要分类。从功能上来划分，可以分出这么几类：
VO（View Object）：视图对象，用于展示层，它的作用是把某个指定页面（或组件）的所有数据封装起来。
DTO（Data Transfer Object）：数据传输对象，这个概念来源于 JavaEE 的设计模式，原来的目的是为了 EJB 的分布式应用提供粗粒度的数据实体，以减少分布式调用的次数，从而提高分布式调用的性能和降低网络负载，但在这里，我泛指用于展示层与服务层之间的数据传输对象。
DO（Domain Object）：领域对象，就是从现实世界中抽象出来的有形或无形的业务实体。
PO（Persistent Object）：持久化对象，它跟持久层（通常是关系型数据库）的数据结构形成一一对应的映射关系，如果持久层是关系型数据库，那么，数据表中的每个字段（或若干个）就对应 PO 的一个（或若干个）属性。
注意：关于vo、dto、do、po可以参考这篇文章-“领域驱动设计系列文章——浅析VO、DTO、DO、PO的概念、区别和用处”
当然这些不一定都存在，这里只是列举一下，可以有这么多分类，当然列举的也不全。
其次，要搞清楚 Domain 层和 Data 层分别是用来做什么的，然后才知道哪些 Model 该往 Data 层中写，哪些该往 Domain 层中写。
Data 层负责提供数据。
Data 层不会知道任何关于 Domain 和 Presentation 的数据。它可以用来实现和数据源（数据库，REST API或者其他源）的连接或者接口。这个层面同时也实现了整个app所需要的实体类。
Domain 层相对于 Presentation 层完全独立，它会实现应用的业务逻辑，并提供 Usercases。
Presentation 从 Domain 层获取到的数据，我的理解就是 VO 了，VO 应该可以直接使用。
注意：这里说的直接使用是指不需要经过各种转换，各种判断了，如 Activity 中某个控件的显示隐藏是根据 VO 中的 visibility 字段来决定，那么这个最好将 visibility 作为 int 型，而且，取值为VISIBLE/INVISIBLE/GONE，或者至少是 boolean 型的。
注意：这里所谓的业务逻辑可能会于 Presenter 的功能概念上有点混淆。打个比方，假如 usecase 接收到的是一个 json 串，里面包含电影的列表，那么把这个 json 串转换成 json 以及包装成一个 ArrayList，这个应当是由 usecase 来完成。而假如 ArrayList 的 size 为0，即列表为空，需要显示缺省图，这个判断和控制应当是由 Presenter 完成的。（上述观点参考自：Saúl Molinero）
最后，就是关于 Data 层，采用的 Repository 模式，建议抽象出接口来，Domain 层需要感知数据是从哪里取出来的。
5.4. 怎么写 View
先区分一下Android View、View、界面的区别
Android View： 指的是继承自android.view.View的Android组件。
View：接口和实现类，接口部分用于由 Presenter 向 View 实现类通信，可以在 Android 组件中实现它。一般最好直接使用 Activity，Fragment 或自定义 View。
界面：界面是面向用户的概念。比如要在手机上进行界面间切换时，我们在代码中可以通过多种方式实现，如 Activity 到 Activity 或一个 Activity 内部的 Fragment/View 进行切换。所以这个概念基于用户的视觉，包括了所有 View 中能看到的东西。
那么该怎么写 View 呢？
在 MVP 中 View 是很薄的一层，里面不应该有业务逻辑，所以一般只提供一些 getter 和 setter 方法，供 Presenter 操作。关于 View，我有如下建议：
简单的页面中直接使用 Activity/Fragment 作为 View 的实现类，然后抽取相应的接口
在一些有 Tab 的页面中，可以使用 Activity + Fragment ( + ViewPager) 的方式来实现，至于 ViewPager，视具体情况而定，当然也可以直接 Activity + ViewPager 或者其他的组合方式
在一些包含很多控件的复杂页面中，那么建议将界面拆分，抽取自定义 View，也就是一个 Activity/Fragment 包含多个 View（实现多个 View 接口）
5.5. 怎么写 Presenter
Presenter 是 Android MVP 实现中争论的焦点，上篇中介绍了多种“MVP 框架”，其实都是围绕着Presenter应该怎么写。有一篇专门介绍如何设计 Presenter 的文章（Modeling my presentation layer），个人感觉写得不错，这里借鉴了里面不少的观点，感兴趣的童鞋可以去看看。下面进入正题。
为什么写 Presenter 会这么纠结，我认为主要有以下几个问题：
我们将 Activity/Fragment 视为 View，那么 View 层的编写是简单了，但是这有一个问题，当手机的状态发生改变时（比如旋转手机）我们应该如何处理Presenter对象，那也就是说 Presenter 也存在生命周期，并且还要“手动维护”（别急，这是引起来的，下面会细说）
Presenter 中应该没有 Android Framework 的代码，也就是不需要导 Framework 中的包，那么问题来了，页面跳转，显示对话框这些情况在 Presenter 中该如何完成
上面说 View 的时候提到复杂的页面建议通过抽取自定义 View 的方式，将页面拆分，那么这个时候要怎么建立对应的 Presenter 呢
View 接口是可以有多个实现的，那我们的 Presenter 该怎么写呢
好，现在我将针对上面这些问题一一给出建议。
5.5.1. 关于 Presenter 生命周期的问题
先看图（更详细讲解可以看看这篇文章Presenter surviving orientation changes with Loaders）
Presenter生命周期
如上图所示，方案1和方案2都不够优雅（这也是很多“MVP 框架”采用的实现方案），而且并不完善，只适用于一些场景。而方案3，让人耳目一新，看了之后不禁想说 Loader 就是为 Presenter 准备的啊。这里我们抓住几个关键点就好了：
Loader 是 Android 框架中提供的
Loader 在手机状态改变时是不会被销毁的
Loader 的生命周期是是由系统控制的，会在Activity/Fragment不再被使用后由系统回收
Loader 与 Activity/Fragment 的生命周期绑定，所以事件会自己分发
每一个 Activity/Fragment 持有自己的 Loader 对象的引用
具体怎么用，在 Antonio Gutierrez 的文章已经阐述的很明白，我就不再赘述了
好吧，我有一点要补充，上面说的方案1和方案2不是说就没有用了，还是视具体情况而定，如果没有那么多复杂的场景，那么用更简单的方案也未尝不可。能解决问题就好，不要拘泥于这些条条框框...（话说，咱这不是为了追求完美吗，哈哈）
5.5.2. 关于页面跳转和显示Dialog
首先说说页面跳转，前一阵子忙着重构公司的项目，发现项目中很多地方使用 startActivity() 和使用 Intent 的 putExtra() 显得很乱；更重要的是从 Intent 中取数据的时候需要格外小心——类型要对应，key 要写对，不然轻则取不到数据，重则 Crash。还有一点，就是当前 Activity/Fragment 必须要知道目标 Activity 的类名，这里耦合的很严重，有没有。当时就在想这是不是应该封装一下啊，或者有更好的解决方案。于是，先在网上搜了一下，知乎上有类似的提问，有人建议写一个 Activity Router（Activity 路由表）。嗯，正好和我的思路类似，那就开干。
我的思路很简单，在 util 包中定义一个 NavigationManager 类，在该类中按照模块使用注释先分好区块（为什么要分区块，去看看我的 “Android 编码规范”）。然后为每个模块中的 Activity 该如何跳转，定义一个静态方法。
如果不需要传递数据的，那就很简单了，只要传入调用者的 Context，直接 new 出 Intent，调用该 Context 的 startActivity() 方法即可。代码如下：
导航管理类-跳转系统页面
导航管理类-跳转不需要传递数据的页面
如果需要传递数据呢？刚才说了，使用 Bundle 或者 putExtra() 这种方式很不优雅，而且容易出错（那好，你个给优雅的来看看，哈哈）。确实，我没想到比较优雅的方案，在这里我提供一个粗糙的方案，仅供大家参考一下，如有你有更好的，那麻烦也和我分享下。
我的方案是这样的，使用序列化对象来传递数据（建议使用 Parcelable，不要偷懒去用 Serializable，这个你懂的）。为需要传递数据的 Activity 新建一个实现了 Parcelable 接口的类，将要传递的字段都定义在该类中。其他页面需要跳转到该 Activity，那么就需要提供这个对象。在目标 Activity 中获取到该对象后，那就方便了，不需要去找对应的 key 来取数据了，反正只要对象中有的，你就能直接使用。
注意：这里我建议将序列化对象中的所有成员变量都定义为 public 的，一来，可以减少代码量，主要是为了减少方法数（虽说现在对于方法数超 64K 有比较成熟的 dex 分包方案，但是尽量不超不是更好）；二来，通过对象的 public 属性直接读写比使用 getter/setter 速度要快（听说的，没有验证过）。
注意：这里建议在全局常量类（没有，那就定义一个，下面会介绍）中定义一个唯一的 INTENT_EXTRA_KEY，往 Bundle 中存和取得时候都用它，也不用去为命名 key 费神（命名从来不简单，不是吗），取的时候也不用思考是用什么 key 存的，简单又可以避免犯错。
具体如下图所示：
导航管理类-跳转需要传递数据的页面
导航管理类-传递数据
导航管理类-获取传递的数据
导航管理类代码如下：
//==========逻辑方法==========
public static T getParcelableExtra(Activity activity) {
Parcelable parcelable = activity.getIntent().getParcelableExtra(NavigateManager.PARCELABLE_EXTRA_KEY);
activity = null;
return (T)parcelable;
}
private static void overlay(Context context, Class INFO && !TextUtils.isEmpty(msg)) {
tag = checkTag(tag);
// Log.i(tag, msg);
com.orhanobut.logger.Logger.t(tag).xml(msg);
}
}
public static void wtf(String msg) {
if(LOGLEVEL > INFO && !TextUtils.isEmpty(msg)) {
// Log.i(tag, msg);
com.orhanobut.logger.Logger.wtf(msg);
}
}
public static void json(String msg) {
if(LOGLEVEL > INFO && !TextUtils.isEmpty(msg)) {
// Log.i(tag, msg);
com.orhanobut.logger.Logger.json(msg);
}
}
public static void xml(String msg) {
if(LOGLEVEL > INFO && !TextUtils.isEmpty(msg)) {
// Log.i(tag, msg);
com.orhanobut.logger.Logger.xml(msg);
}
}
private static String checkTag(String tag) {
if (TextUtils.isEmpty(tag)) {
tag = mTag;
}
return tag;
}
这里是最简单的一些替换，如果是替换网络框架，图片加载框架之类的，可能要多费点心思去封装一下，这里可以参考“门面模式”。（在这里就不展开来讲如何对第三库进行二次封装了，以后有时间专门写个帖子）
5.7.3. 建立单独的 Module 管理所有的第三库
原因前面已经说过了，而且操作也很简单。网上有不少拆分 Gradle 文件的方法，讲的都很不错。那我们就先从最简单的做起，赶快行动起来，把项目中用到的第三方库都集中到 Library Module 中来吧。
5.8. MVP vs MVVM
关于 MVP 和 MVVM 我只想说一句，它们并不是相斥的。具体它们是怎么不相斥的，markzhai 的这篇文章“MVPVM in Action, 谁告诉你MVP和MVVM是互斥的”说得很详细。
5.9. Code
抱歉，要食言了，AndroidStudio 出了点问题，代码还没写完，代码估计要这周末才能同步到 GitHub 上了，目前只上传了一个空框架。
5.10. 小结
历时三天的 MVP 总结，总算要告一段落了。前期断断续续地花了将近一周左右零散的时间去调研 MVP，直到正式开始码字的时候才发现准备的还不够。看了很多文章，有观点一致的，也有观点很不一致的。最关键的是，自己对于 MVP 还没有比较深刻的认知，所以在各种观点中取舍花了很长时间。
这算得上是我第一次真正意义上的写技术性的文章，说来惭愧，工作这么长时间了，现在才开始动笔。
总体来说，写得并不尽如人意，套一句老话——革命尚未成功，同志仍需努力。这算是一次尝试，希望以后会越写越顺畅。在这里给各位坚持看到此处的看官们问好了，祝大家一同进步。（欢迎大家围观我的GitHub，周末更新，会渐渐提交更多有用的代码的）
6. 进阶与不足
鉴于本人能力有限，还有很多想写的和该写的内容没有写出来，很多地方表达的也不是很清晰。下面说一说我觉得还有哪些不足和下一步要进阶的方向。
说好的“show me the code”，代码呢？（再次抱歉了）
上篇当中关于各种 Presenter 方案只是做了简单的罗列，并没有仔细分析各个方案的优点和不足
没有形成自己的框架（呵呵，好高骛远了，但是梦想还是要有的...）
没有单元测试（项目代码都还没有呢，提倡 TDD 不是，呵呵）
很多细节没有介绍清楚（如关于Model、Domain、Entity 等概念不是很清晰）
很多引用的观点没有指明出处（如有侵权，马上删除）
......
最后想说一句，没有完美的架构，没有完美的框架，赶紧编码吧！
7. 附录
附上我的思维导图：
MVPBestPractice.mmap
MVP总结.mmap
Presenter生命周期.mmap
怎么写Presenter.mmap
参考：
https://segmentfault.com/a/1190000003871577
http://www.open-open.com/lib/view/open1450008180500.html
http://www.myexception.cn/android/2004698.html
http://gold.xitu.io/entry/56cbf38771cfe40054eb3a34
http://kb.cnblogs.com/page/531834/
http://blog.zhaiyifan.cn/2016/03/16/android-new-project-from-0-p3/
http://www.open-open.com/lib/view/open1446377609317.html
http://my.oschina.net/mengshuai/blog/541314?fromerr=3J2TdbiW
http://gold.xitu.io/entry/56fcf1f75bbb50004d872e74
https://github.com/googlesamples/android-architecture/tree/todo-mvp-loaders/todoapp
http://blog.zhaiyifan.cn/2016/03/16/android-new-project-from-0-p3/
http://android.jobbole.com/82375/
http://blog.csdn.net/weizhiai12/article/details/47904135
http://android.jobbole.com/82051/
http://android.jobbole.com/81153/
http://blog.chengdazhi.com/index.php/115
http://blog.chengdazhi.com/index.php/131
http://www.codeceo.com/article/android-mvp-practice.html
http://www.wtoutiao.com/p/h01nn2.html
http://blog.jobbole.com/71209/
http://www.cnblogs.com/tianzhijiexian/p/4393722.html
https://github.com/xitu/gold-miner/blob/master/TODO/things-i-wish-i-knew-before-i-wrote-my-first-android-app.md
http://gold.xitu.io/entry/56cd79c12e958a69f944984c
http://blog.yongfengzhang.com/cn/blog/write-code-that-is-easy-to-delete-not-easy-to/
http://kb.cnblogs.com/page/533808/