直接看README.md和源码(todo-mvp分支)。根据tasks界面的功能画了一张类图，并根据模块进行划分。
image
MVP.png
Model层。所有对外方法都写在TasksDataSource接口中。TasksRepository, TasksRemoteDataSource, TasksLocalDataSource实现了接口，并且只保持一个对象。TasksRemoteDataSource对象负责服务端数据请求，'TasksLocalDataSource'对象负责本地数据管理，TasksDataSource对象负责调度内存缓存，本地请求，网络请求的优先级，处理请求策略。它是包外唯一可以被访问到的对象。
Presenter层。连接了Model层和View层。TasksPresenter对象持有一个View对象和TasksRepository的实例，它负责处理界面与数据交互的逻辑。在这一层中有一个TasksContract类帮助大家理解，它包含了两个接口类------TasksContract.View 和TasksContract.Presenter。TasksContract.View接口由具体的View类来实现，它包括了数据请求过程中的回调方法；TasksContract.Presenter接口由TasksPresenter类来实现，它负责View交互过程中的数据操作逻辑。
View层。TasksFragment对象持有一个TasksPresenter对象。它只负责界面相关的逻辑，所有与数据相关的逻辑都交给TasksPresenter对象去实现。
TasksActivity是整个页面的入口，它负责创建TasksFragment对象(View)和TasksPresenter对象(Presenter)，并把他们联系在一起。它实时上充当一个控制者的角色。
![逻辑架构][2]
总结：
- 整个架构分层清晰易于维护，避免了把逻辑放在
Activity/Fragment中，代码臃肿的问题。 - 界面与逻辑分开，可以分层开发，单元测试方便。
- 没有引入太多的类，对代码体积影响小。 ----------------------------分割线---------------------------- 继续读todo-mvp-clean代码。对Domain部分画了简单的类图。
image
mvp-clean-domain
Domain部分主要作用是：
- 添加了异步请求，防止在UI线程进行耗时操作
- 添加了一个线程池，减少资源消耗
- 使用了UseCase避免重复代码，减轻Presenter类代码量
整个框架没有引入第三方代码库，增加的代码量不算多。如果只做简单的网络请求，已经基本够用了。
现在整个架构是这样子的了。 [图片上传失败...(image-fe84e6-1547557986911)] [2]:https://github.com/googlesamples/android-architecture/wiki/images/mvp.png [3]:https://github.com/googlesamples/android-architecture/wiki/images/mvp-clean.png
喜欢的话请帮忙转发一下能让更多有需要的人看到吧，有些技术上的问题大家可以多探讨一下。
image
image
网友评论