MVP架构在Android平台上的实现分析
2017-04-19 17:40
288 查看
MVP也即Model-View-Presenter，是在MVC基础上优化衍生出来的一种软件架构模式，它将MVC中的Controller层进行了优化而生成了Presenter（可理解为主持者或表示者）。
这里Presenter层和MVC的Controller一样，负责核心逻辑，但不同的是，Presenter通过接口协议进行数据传递、功能调用，并阻断了View和Model的直接联系，从而使View和Model更加专注于自身业务逻辑，更好地实现了高内聚、低耦合，同时也方便单元测试。
用下图来说明二者之间的对比，可能更直观些。
在Android平台上，由于Activity/Fragment的生命周期比较复杂以及配置可能发生变化等因素，我们在具体实现时，可以采用多种不同的方案。
本文对Android平台上常见的MVP架构模式，从实现方案的角度尝试做些分析，也欢迎一起深入探讨。
1、Google官方实现
这里使用的例子为TOTO-MVP，属于MVP架构的一个基础实现，主要功能是记录、查看待处理任务，管理待办事宜。
其项目工程结构和包，是按照功能来划分的，包括新建/编辑、任务统计、详情查看等模块，如图。
各个子模块的实现比较类似，以新建/编辑任务模块为例，其UML静态结构如下。
其中AddEditTaskActivity完成Presenter的实例化，并将实现了View接口的AddEditTaskFragment对象作为一个参数传递到构造函数中，再通过setPresenter调用，把AddEditTaskPresenter传递给AddEditTaskFragment，建立View和Presenter之间的双向关联。而TasksDataSource接口及TasksRepository类则对应Model，负责完成任务的获取、保存和刷新等处理。
这里获取任务数据的回调处理，是通过Presenter实现TasksDataSource.GetTaskCallback接口来完成的，在onTaskLoaded 和onDataNotAvailable回调中根据数据获取情况更新UI显示。
除了上面提到的基础调用逻辑之外，我们还需要关注该实现中，在Fragment不同的生命周期以及Activity配置发生变化时，对应Presenter的处理方式。
生命周期的处理，又分为两部分。一是在onActivityCreated完成“新建”按钮的属性和点击事件设置，二是在onResume中调用Presenter的start方法，以获取待编辑的任务数据。
配置变化的处理，则是通过AddEditTaskPresenter构造函数中的一个变量来实现的，该变量在任务数据获取完成之后加以复位。Activity中，对应的变量在配置变化时会被保存下来，当再次创建Activity时，该变量被传递给AddEditTaskPresenter，这样避免了由于配置变化带来的数据丢失。
实际上，针对配置变化的问题，Google官方的TODO-MVP-Loders实现给出了另外一种解决方案。该实现利用Loader机制来处理数据访问，对于任务数据的访问管理提供了更强大的功能，包括异步加载数据、监听数据变化以及自动重连等。
与之类似的官方实现还有TODO-MVP-Clean，该实现主要是增加了一个Domain层，可以理解为业务逻辑层，负责处理Presenter发起的业务逻辑相关的操作。个人认为这种实现是对MVP中的Model做了扩展，将业务逻辑与数据访问进一步解耦。
这里Presenter层和MVC的Controller一样，负责核心逻辑，但不同的是，Presenter通过接口协议进行数据传递、功能调用，并阻断了View和Model的直接联系，从而使View和Model更加专注于自身业务逻辑，更好地实现了高内聚、低耦合，同时也方便单元测试。
用下图来说明二者之间的对比，可能更直观些。
在Android平台上，由于Activity/Fragment的生命周期比较复杂以及配置可能发生变化等因素，我们在具体实现时，可以采用多种不同的方案。
本文对Android平台上常见的MVP架构模式，从实现方案的角度尝试做些分析，也欢迎一起深入探讨。
1、Google官方实现
这里使用的例子为TOTO-MVP，属于MVP架构的一个基础实现，主要功能是记录、查看待处理任务，管理待办事宜。
其项目工程结构和包，是按照功能来划分的，包括新建/编辑、任务统计、详情查看等模块，如图。
各个子模块的实现比较类似，以新建/编辑任务模块为例，其UML静态结构如下。
其中AddEditTaskActivity完成Presenter的实例化，并将实现了View接口的AddEditTaskFragment对象作为一个参数传递到构造函数中，再通过setPresenter调用，把AddEditTaskPresenter传递给AddEditTaskFragment，建立View和Presenter之间的双向关联。而TasksDataSource接口及TasksRepository类则对应Model，负责完成任务的获取、保存和刷新等处理。
这里获取任务数据的回调处理，是通过Presenter实现TasksDataSource.GetTaskCallback接口来完成的，在onTaskLoaded 和onDataNotAvailable回调中根据数据获取情况更新UI显示。
除了上面提到的基础调用逻辑之外，我们还需要关注该实现中，在Fragment不同的生命周期以及Activity配置发生变化时，对应Presenter的处理方式。
生命周期的处理，又分为两部分。一是在onActivityCreated完成“新建”按钮的属性和点击事件设置，二是在onResume中调用Presenter的start方法，以获取待编辑的任务数据。
配置变化的处理，则是通过AddEditTaskPresenter构造函数中的一个变量来实现的，该变量在任务数据获取完成之后加以复位。Activity中，对应的变量在配置变化时会被保存下来，当再次创建Activity时，该变量被传递给AddEditTaskPresenter，这样避免了由于配置变化带来的数据丢失。
实际上，针对配置变化的问题，Google官方的TODO-MVP-Loders实现给出了另外一种解决方案。该实现利用Loader机制来处理数据访问，对于任务数据的访问管理提供了更强大的功能，包括异步加载数据、监听数据变化以及自动重连等。
与之类似的官方实现还有TODO-MVP-Clean，该实现主要是增加了一个Domain层，可以理解为业务逻辑层，负责处理Presenter发起的业务逻辑相关的操作。个人认为这种实现是对MVP中的Model做了扩展，将业务逻辑与数据访问进一步解耦。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- MVP架构在Android平台上的实现分析（三）
- MVP架构在Android平台上的实现分析（二）
- MVP架构在Android平台上的实现分析（一）
- Android应用架构之MVP实现
- 转载：Android Display架构分析--侧重高通平台
- Android MVP架构分析
- Android RIL架构分析——（1）本地库实现[c/cpp部分]
- 转载：Android Display架构分析--侧重高通平台
- Android平台架构分析
- ANDROID应用架构之MVP实现
- Android应用架构之MVP实现
- 基于Android Architecture Blueprints的MVP案例分析与实现
- 一个App架构例子分析--UI层使用MVP模式；各层之间使用Otto实现通信
- 转载：Android Display架构分析--侧重高通平台
- MVP架构-Android官方MVP项目和响应式MVP-RxJava项目架构分析对比解读
- Android官方MVP架构分析
- MVP架构-Android官方MVP项目和响应式MVP-RxJava项目架构分析对比解读
- Android Tegra平台back camera 驱动实现三 Android中的camera架构及工作原理
- ANDROID窗口管理服务实现机制和架构分析
- MVP架构实现Android手机记步功能