Android官方MVP架构分析

App架构在Android开发者中一直是讨论比较多的一个话题，目前讨论较多的有MVP、MVVM、Clean这三种。google官方对于架构的态度一直是非常开放的，让开发者自主选择组织和架构app的方式，期望能留给开发者更多的灵活性。

        由于没有一套权威的架构实现，现在很多App项目中在架构方面都有或多或少的问题。第一种常见问题是没有架构，需求中的一个页面对应项目中的一个activity或一个fragment，所有的界面响应代码、业务逻辑代码、数据请求代码等等都集中在其中。第二种常见的问题是架构实现的不断变化，不断在各种架构间摇摆，一直找不到一个适合自己的架构。

什么是MVP？

        MVP是Model, View和Presenter的简称。是非常有名的MVC模式的演化版。MVP模式把显示逻辑和从业务逻辑层中分离出来，理想状况下，MVP模式中，在替换不同的视图(View)的情况下，可以实现完全相同的业务逻辑。

        Presenter代替了MVC中Controller，它比Controller担当更多的任务，也更加复杂。Presenter处理事件，执行相应的逻辑，这些逻辑映射到Model的Command以操作Model。那些处理UI如何工作的代码基本上都位于Presenter。Presenter如同一个乐队的指挥家，表现和协调整个Application，它负责创建和协调其它对象。

        MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间的通信是通过Presenter (MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会从直接Model中读取数据而不是通过Controller。

为什么使用MVP模式

        因为在Android中，Activity严重耦合了界面和数据获取层。这样不仅导致了Activity的类越来越庞大，而且，如果修改数据获取层，可能也导致整个View都要重写。也非常不利于模块和自动化测试。

       MVP使View独立于数据，把大量的逻辑从Activity中提取出来。把应用分层，每层都可以独立测试和变动。

    下面通过MVP结构图来看一下MVP中各个层次之间的关系。 

 

 

　在MVP架构中将这三层分别抽象到各自的接口当中。通过接口将层次之间进行隔离，而Presenter对View和Model的相互依赖也是依赖于各自的接口。这点符合了接口隔离原则，也正是面向接口编程。在Presenter层中包含了一个View接口，并且依赖于Model接口，从而将Model层与View层联系在一起。而对于View层会持有一个Presenter成员变量并且只保留对Presenter接口的调用，具体业务逻辑全部交由Presenter接口实现类中处理。

· 

官方MVP架构分析

项目介绍

 

 

 

 

　对于MVP架构有了一些的了解，而在前端时间Google给出了一些App开发架构的实现。 
　　项目地址为：https://github.com/googlesamples/android-architecture. 
　　在这里进入README看一下这次Google给出那些Android开发架构的实现。

　　对于上面五个开发架构的实现表示到目前为止是已经完成的项目，而下面两个则表示正在进行的中的项目。现在首先来介绍一下首推猕猴域名网这几个架构。

· todo-mvp: 基础的MVP架构。

· todo-mvp-loaders:基于MVP架构的实现，在获取数据的部分采用了loaders架构。

· todo-mvp-databinding: 基于MVP架构的实现，采用了数据绑定组件。

· todo-mvp-clean: 基于MVP架构的clean架构的实现。

· todo-mvp-dagger2: 基于MVP架构，采用了依赖注入dagger2。

· dev-todo-mvp-contentproviders: 基于mvp-loaders架构，使用了ContenPproviders。

· 

dev-todo-mvp-rxjava: 基于MVP架构，对于程序的并发处理和数据层（MVP中的Model）的抽象。

· 

　　从上述的介绍中可以看出，对于官方给出所有的架构的实现最终都是基于MVP架构。所以在这里就对上面的基础的MVP架构todo-mvp进行分析。

· 

项目结构的分析

　　对于这个项目，它实现的是一个备忘录的功能。对于工作中未完成的任务添加到待办任务列表中。我们能够在列表中可以对已完成的任务做出标记，能够进入任务详细页面修改任务内容，也能够对已完成的任务和未完成的任务数量做出统计。 
　　首先在这里来看一下todo-mvp整体的项目结构 

 

 

 

 

   从上图中可以看出，项目整体包含了一个app src目录，四个测试目录。在src目录下面对代码的组织方式是按照功能进行划分。在这个项目中包含了四个功能，它们分别是：任务的添加编辑(addedittask),任务完成情况的统计(statistics),任务的详情(taskdetail),任务列表的显示(tasks)。对于data包它是项目中的数据源，执行数据库的读写，网络的请求操作都存放在该包内，也是MVP架构中的Model层。而util包下面则是存放一些项目中使用到的工具类。在最外层存放了两接口BasePresenter和BaseView。它们是Presenter层接口和View层接口的基类，项目中所有的Presenter接口和View层接口都继承自这两个接口。 

　　现在进入功能模块内看下在模块内部对类是如何划分的。在每个功能模块下面将类分作xxActivity,xxFragment,xxPresenter,xxContract。也正是这些类构成了项目中的Presenter层与View层。下面就来分析在这个项目中是如何实现MVP架构。

MVP架构的实现

　　在这里只从宏观上关注MVP架构的实现,对于代码的内部细节在就不在具体分析。那么就以任务的添加和编辑这个功能来看一下Android官方是如何实现MVP架构。

总结

　　通过MVP架构的使用可以看出对于各个层次之间的职责更加单一清晰，同时也很大程度上降低了代码的耦合度。对于官方MVP架构示例，google也明确表明对于他们所给出的这些架构示例只是作为参考，而不是一个标准。所以对于基础的MVP架构有更大的扩展空间。例如综合google给出的示例。我们可以通过在MVP架构的基础上使用dagger2，rxJava等来构建一个Clean架构。也是一个很好的选择。