Android app重构：mvp和mvvm



做android app已经四年多了（工作一年半多，其他在学校的玩耍 /大笑）， 在一年之前我从未想过app的架构， 直到今年年初的时候接手了一个项目，项目在我看来有些复杂（一个直播项目），而且后续可能会进行二期、三期的开发，于是我开始思考怎样来架构之，才能使之更清晰，更简洁，更易维护和拓展，便开始了漫长而纠结的架构之路。

今天是丙申年立秋，我准备把我这半年多的app架构学习所积累经验或者知识的记录下来：

传统的Android app开发可以认为是MVC：

——xml布局是view层

——activity、fragment等可以看作是controller层

——还有数据model层

这样的模式会带来一个很明显的问题，就是activity过于庞大，因为我们会把所有的业务逻辑 都写在activity中，于是就想到了mvp或者mvvm的架构模式。

mvp或者mvvm：

——xml和activity、fragment看作view层，只负责app的显示逻辑

——p和viewmodel层负责app具体的业务逻辑，只不过p需要接口和view层交互，viewmodel是通过数据绑定的方式直接更新View

——model基本一致，就是一些数据实体的封装

本文开始的说的纠结，便是mvp和mvvm的纠结， 因为现在网上大部分的android开发都已经采用了mvp的模式， 而且谷歌官方也给出了mvp的示例工程（具体可以参考google的github），经过了长期的纠结之后，我决定使用mvp和mvvm的混合模式，因为mvp会带来一个问题便是当一个页面很复杂以后mvp的view接口就会很复杂，但是mvvm有些view又是无法绑定的，比如一个dialog的显示。

我今天所要说明的正是mvp和mvvm的混合模式，我不知道这样做会带来什么养的后果，但目前来说对于我的项目来说是可行的。

我打算把项目分成model层、viewmodel层、view层、api层，helper层

view层：主要就是xml和activity、fragment、自定义的view、adpater、和view接口

viewmodel：将model转换为view能够显示的数据，它调用api层和helper层。一部分通过数据绑定去更新view，一部分通过mvp的接口模式去更新view。

model层：主要包含了本地数据绑定的数据模型和远程服务器传过来的数据模型

除了mvvm的三个层之外还有

api层：主要是用于与后端服务器的交互，其功能是请求网络数据，并将请求到的网络数据转换为具体的model类，然后通过接口返回给viewmodel，viewmodel再将其转换为view可以显示的数据。

helper层：主要是对一些复杂的业务逻辑的封装（比如整个app的用户数据管理，可能是一个单例）和第三方的一些库的调用（比如分享、登录、腾讯的IM等）