模块化的目的：
- 保证项目的可维护性。
- 加快编译速度，提升开发效率。
- 有一定的复用性，新项目可复用模块，节省开发资源。
android项目目前已经成熟了很多，官方也在寻找合适的模块化方式，不过就目前的状况来看，并没有一个统一的模块化构建方案，本篇为大家提供一个模块化思路，本项目也构建在该思路下。
首先我们看google推荐的模块化方案，传送门
1_sample_dep_graph.png
我们可以看到google对模块化的构建是比较通用的，并没有考虑每个项目的复杂情况，毕竟每个项目都不一样，这一点google提供的思路也是建立在大多数项目的可行性上。我们也将在此基础之上进行一定的拓展来设计。
首先我们来分析google的设计
- 顶层为app及auto块，这里google考虑了多平台的差异化，不过下层并没有考虑差异化，不过我们的项目大多构建在单一平台，不考虑多平台的情况，因此我们顶层只需要设计app块即可。
- feature块：也就是我们的功能模块。
- data块：也就是我们通常理解的数据模块，包含模型以及数据获取。
-
core块：我们可以理解为基础功能模块。
进阶：模块间通讯
2_mediator.png
google提供的思路为借助app模块进行两个模块间的通讯能力，这里我们可以使用router的形式来处理，后续的模块化搭建过程中，我会构建一个简单的router功能帮助大家理解，当然，正式项目中我们可以使用arouter或者vmrouter来帮助构建router功能。
大致理解了google的模块化设计后，我们可以在自己项目的情况内构建属于自己的模块化，这里我给出大概思路，并且本篇的框架搭建中也是基于该思路来创建。
如图：
新建 BMP 图像.png
基于google的思路，我们创建出如下项目结构。 - app:壳模块，通常我们不放置什么代码，仅用于桥接其他模块。
- data:数据模块，用来存放模型及数据来源。
- core:基础功能模块，与业务毫无关系。
- feature_common:用来存放与项目业务相关的组件及工具封装，类似core但是与业务有关。这里主要是考虑到一些场景下，可能某个组件（如db）会与项目业务有一定的关联性，如room的封装方式也不支持单一模块无model封装，因此，与业务相关的基础模块是有必要的，这里要考虑到实际情况中，某些特殊场景并没有办法区分模块，并且模块化构建时也无法引用其他模块的view封装。此处也考虑到一些项目资源并没有合适的地方存放，因此构建。
- feature:业务模块，通常就是我们访问的每个页面或相关的功能。
依赖关系：懒得画图，这里就用语言描述一下：app->feature->feature_common->data->core
- app：模块为顶层模块，可依赖其他模块。
- feature:业务模块，互相不可直接依赖，但是可依赖任意下层模块。
- feature_common:可依赖下层模块，必要时可以依赖feature_common同级模块，这里主要考虑到room及paging的使用方式，paging必须依赖room。
- data:模型及数据来源块，不可直接引用上层模块，不过考虑到room使用的特殊性，后续我会详细说明room使用方式。
- core:可依赖下层模块，必要时可依赖core同级模块,这里主要考虑我们的通用工具类，如stringutil这种需要被core_network使用。通常core模块为单一模块，尽量不引用功能外的其他块。
至此，我们项目的大概结构就出来了，后续会有一些扩展，请持续关注。
项目地址
