之前没有看过github上google关于MVP的简介，现摘抄如下：
这个分支示例叫todo-mvp，也是其他分支示例的基础，本示例旨在：
1.在没有其他框架的基础下，展示了一个基本的MVP的示例。
2.可作为本项目中其他示例的比较和参考。
注意：项目仓库的所有分支中使用以下命名约定来区分android SDK中的View类和MVP中的视图View:
对于导入的android.view.View类指的就是android SDK中的View视图控件。
从Presenter中接收执行代码的View则是MVP中的View。
下面两个文档是项目代码的基础，在浏览项目的代码前，你可以先阅读下，以便更好的理解项目中的代码：
todo-mvp示例工程使用了下面的依赖框架：
通用的android-support库：com.android.support.*命名空间中的软件包提供向后兼容性和其他功能。
Android Testing Support Library用于支持UI测试的框架，同时使用Espresso和AndroidJUnitRunner。
Mockito 用于实现单元测试的模拟框架
Guava 谷歌的一套核心库，通常用于Android应用程序。
App的设计
所有版本的Android Blueprints应用程序在简单的待办事宜类型应用程序中都包含相同的常见功能。 该应用程序由四个UI屏幕组成：
任务列表页面 - 一个便于管理任务的列表。
任务详情页面 - 用于读取或删除任务。
添加以及编辑页面 - 用于创建或编辑任务。
统计页面 - 显示与任务相关的统计信息。
在这个版本的应用程序以及基于它的其他版本中，每个页面都使用以下类和接口来实现：
定义View和Presenter之间的连接的Contract类。
创建Fragment和Presenter的Activity。
实现界面显示的Fragment。
在Contract类中的Presenter接口的具体实现类。
Presenter通常托管与特定功能相关联的业务逻辑，并且将相应的视图处理交给Android UI。而View几乎没有逻辑; 它将演示者的命令转换为UI操作，并监听用户操作，然后将其传递给Presenter。
App的实现
应用的每个版本都使用不同的方法来实现相同的功能，以展示和对比各种架构设计。 例如，该版本采用以下方法来解决常见的实现问题：
本示例使用product flavors在编译时替换模块，为手动和自动测试提供假数据。
该版本使用回调来处理异步任务。
数据存储在SQLite数据库本地，使用Room。
另请注意，在下图中，该版本的应用程序使用了Fragment，这有两个原因：
同时使用Activity和Fragment是对MVP解耦的加强。因此在这个版本的应用程序中，Activity是创建并连接View和Presenter的整体控制器。
Fragment的使用支持具有多个视图的平板电脑布局或UI屏幕。
该版本的应用程序包含许多单元测试，涵盖Presenter，存储库和数据源。 该示例还包括依赖假数据的UI测试，并通过依赖注入来提供假模块。 有关使用依赖注入来促进测试的更多信息，请参阅利用Android Studio中的product flavors进行全面测试。
App的代码维护
本示例包括类和接口（例如Presenter和Contract），与不使用这个体系结构的更传统项目相比，这些类增加了代码行数。
我的理解
1.Presenter不一定要非在Activity中初始化，也可以在Fragment中初始化
在todoMVP项目中，Presenter是在Activity中初始化并通过Presenter的构造函数传递给Fragment的，而在e家家项目中Presenter更多的是直接在Fragment中初始化（如果需要使用Fragment）或者在Activity中初始化，少了传递这一步。