mvp-rxjava架构实现与思考

去年android的架构有点火，因为google在github上发布了官方对于android架构的事例（github地址：https://github.com/googlesamples/android-architecture）。几个月前我刚接到一个新项目的开发任务后，在研究了todo-mvp-xxx的框架后，那优雅的contract，流畅的logic handle，简明的架包结构深深迷住了我，就在那四分之一炷香之间，我做了一个我认为是最完美的的决定，I want it！

现在项目已经上线，开发工作了告一段落，是时候写篇文章说说它的好了。First，让我来简单说说这个框架到底是什么样的。关于什么是mvp，简单来讲就是mvc的变种，将模型与视图完全分离，这在android的app开发环境中意义更大，因为传统的mvc中activity或fragment做了太多工作导致太臃肿，无论是代码的复用性还是可维护性都是挑战。官方给出的框架图如下：

由上图可以看出来，它和传统的mvp框架并没有什么不同，都是通过presenter和view互相持有，不过google在每个presenter和view之间通过contract实现调用接口规范。一个东西要称之为框架，那么前提必须是它有一套规范或者思想，也就是俗称的套路，那么问题来了，google的套路在哪呢？

一、模块化编程。记得从刚开始学编程，老师就告诉我要模块化要优雅。然而这一切在android上却貌似一直是个大问题，因为经常性的一个activity就是一个模块，那还要分啥模块。。。所以我见到的android app项目基本长这样：

no，no fashion！作为一只优雅的程序猿，拒绝粗暴简单。google给的sample长这样：

貌似也优雅不到哪去。。。不要捉急，要优雅。仔细看看，我们会发现有点模块化的思想，addedittask、statistics、taskdetail、tasks能单独分包了，基本每个模块包含四个文件：activity、fragment、presenter和contract。来看看google的说明：

The use of both activities and fragments allows for a better separation of concerns which compliments this implementation of MVP. In this version of the app, the Activity is the overall controller which creates and connects views and presenters.

简单来说就是fragment作为模块化的基本单元，activity作为创建和链接fragment和对应presenter的容器。那我们来继续引申一下，view同样可以作为模块的基本单元，可以得到两点rules：

1、fragment和view作为模块的基本组成单元。

2、上层作为下层的容器（持有者），也就是activity持有fragment，fragment持有view。

在google的设计中，presenter也是由activity初始化的，而fragment和presenter的关联也是在presenter的构造函数中完成的。这么做的优点在于降低fragment和presenter的耦合度，缺点呢就是由于fragment和presenter的初始化不同步，无法精细控制presenter的数据初始化动作。而在实际的应用场景中，fragment和view与presenter基本是一一对应的，因此得到第三点rule：

3、fragment和view负责对应的presenter的创建与链接。

最终的架包如下图：

二、流式处理

rxjava作为一款异步处理框架，与mvp实在是干柴烈火，天作之合。Observable和Subscription天然对应Model和Presenter，在model中定义数据的来源并返回Observable，在presenter中进行subscribe操作，同时，在subscribe时可以随时切换线程做视图的更新。

Talk is cheap，我们来简单看一组栗子加深下印象：

presenter model

好像没什么可讲解的，就这样吧。