安卓项目架构浅谈

项目架构，从最初的单module代码级分包到如今的基于module的模块化演变；而单module内部，从mvc(不算是)到mvp再到结合google新出的带有生命周期的viewmodel、livedata等构建的mvvm演变。谈一谈自己的安卓项目架构经历。

从事安卓一开始便入得小公司，项目全靠自己搭建，最初一个app模块包含所有业务功能代码。app模块内部结构，分三大块，网络、ui、dao，分包予以区分。网络模块由asynchttpclient完成，统一单文件配置所有接口。ui层，分activity、view，其他基础包如utils、bean等。dao包括数据库创建，增删改查等。基本整体架构如此。后来人数达3-5人，每版功能变动极大，很多大模块功能同时开发。为了便于开发和管理，进行功能级别的分包，每个功能模块内部分ui、dao、网络三部分。

随着rxjava与retrofit网络框架的流行，网络模块代码逐渐向之移植。rxjava处理异步回调，着实顺手；rxbus进行页面间事件的通知也很方便。早先网络异步回调，成功与否更新页面Ui,很容易造成内存泄露，以及当页面关闭时，进行页面相关dialog显示易造成崩溃(dialog找不到依附的页面，因为已调用finish方法)等问题。内存泄露及崩溃，是通过静态类以及弱引用加以处理，写起来很不方便。尤其异步回调嵌套，更是使得代码难以阅读，写起来也费劲，通过rxjava很好的避免这一点。在页面onDestory生命周期中，取消订阅，防止内存泄露；同时基于事件流的异步回调处理，简单方便易读。

mvp(加dagger2)，渐渐的流行起来。对项目进行改造，严格来说所谓的mvp就是传统意义上的mvc，只是安卓界把model(网络数据处理、数据库数据处理等)、activity(ui显示加数据加工、逻辑控制)当做mvc，v跟c并未分层。不管什么架构，目的就是为了便于开发和维护(写的多了，会发现好的代码形式、项目结构，确实是大大大大的方便，没有前后对比没有伤害)，也不用过于较真概念。mvp，三层，每层抽象出来对外功能接口。view层，model层，presenter层，每层内部有自己的实现类。在代码构建过程中，会逼迫你先把页面功能点过一遍，把对外的api与数据结构提前定义好，层与层之间直接交互而无需关心具体内部实现。不需涉及每个环节的细节点，已经搭建出整体流程。为了解耦和，通过dagger2配置接口与实现类。代码结构一目了然，层层之间互不影响，开发过程流畅而清晰，后期修改维护也很方便，不会造成过多的代码伤害。为防止内存泄露，presenter建议定义成静态类，在初始化时持有view层引用，在view的onDestory生命周期中置引用为空。

做的时间长了，会发现公司会有做多个项目的需求。一些项目，根本就是主项目功能的摘取；还有主项目的部分功能，会由于各种原因进行推翻重做。比较糟糕的事情来了，比如经手的题库模块，好几个项目都有这个功能。如何摘取组合，成了难题。再经历过几次艰辛痛苦的提取后，着手寻找好的解决办法，然后进行了现有项目的模块化改造。新项目需要什么功能组合，可轻松配置出，不用再劳心劳肝，痛不欲生了。

模块化、组件化，一堆的概念。个人感觉，模块化，偏向业务方面的解耦；组件化，偏向功能模块的复用。大体架构，每个library可配置单独运行的工程。基础library提供基础的util等功能，通过不同library的组合依赖配置，最终生成app，如此灵活便于协同开发与管理。安卓module通过配置，可以很方便的进行library与application的转化

1.见下

if (