在上篇文章里，我们对Google官方的TODO-MVP-Loaders做了分析，今天继续探讨另外一种官方实现，基于Clean架构的MVP实现。
Clean架构，如果从分层方式来看，主要涉及了一种“洋葱式”的分层设计，这些层次包括：UI框架层、Presenter层、Domain层、Entities层。
各层之间是单向的、从外到内的依赖关系，并且越往内层，其实现越不依赖于具体的平台框架。更专业、更详细的说明，可直接阅读Uncle Bob的文章：The Clean Architecture。
这种架构的好处有：
1、当UI相关代码需要修改时，对其他层不产生影响或者影响很少；
2、业务逻辑通过UseCase或者Interactor类封装，方便扩展维护；
3、可以灵活使用不同的数据库方案，而不影响其他部分代码；
4、方便单元测试，提前暴露问题。
上述分层方式与MVP的分层架构有所不同，但两者可以结合起来，发挥各自的优点。我们来看TODO-MVP-Clean是如何实现的。
这是Google官方网站上，对应TODO-MVP-Clean实现的一幅图。
从上图可以看出，相对于基础实现，主要是增加了Domain层，包括与具体业务逻辑对应的UseCase及其派生类。
在官方介绍里面，该实现从整体上被分为了3层：
Presentation Layer，包括各种View、Presenter类；
Domain Layer，包括UseCase及其派生类；
Data Layer，主要包括实现了TasksDataSource接口的TasksRepository类。
其UML静态结构图如下。这里为了简洁，只选取了其中保存任务相关的静态结构进行分析，对于其他诸如获取任务、删除任务的结构分析也类似。
以新建任务时的保存操作为例，其UML动态序列图如下。
结合序列图，我们在参考该实现时，可以关注如下几点。
首先是业务逻辑相关调用。在Presenter中，原先基础实现里面直接调用TaskRepository对象的地方，在该实现中，已经改为通过UseCaseHandler调用，再由内部的UseCaseThreadPoolScheduler调用SaveTask这个UseCase的具体实现，最后通过TaskRepository的saveTask方法来完成整个操作。
其次关注回调处理。在SaveTask里面，保存成功后，会调用UseCaseHandler中的onSuccess回调函数，再通过UseCaseThreadPoolScheduler触发AddEditTaskPresenter中的回调。这里和具体业务逻辑相关的地方，分别在SaveTask、AddEditTaskPresenter中。
再次就是Domain层的UseCase里面模板参数的实现。还是以保存任务为例，在定义SaveTask类时，需要根据具体业务（例如保存任务数据），专门定义内部类，分别实现模板参数中UseCase.RequestValues和UseCase.ResponseValue这两个接口。
另外，UseCaseThreadPoolScheduler里面的线程池设计，用于同时有多个UseCase需要执行的场景。这里还使用了单例模式，上述Scheduler所属的UseCaseHandler对象为全局的单例对象。
