推荐文章
项目模块化的两种模式
目前项目模块化大体可以分为两种模式，分别是submodule和multi-project。根据字面意思，我们就可以很容易理解这两种模式，下面就让我们来具体了解一下这两种模式！
submodule模式
submodule图例
如上图所示，项目中只有一个project工程，在project中构建多个module组件，每个module都有自己的git仓库，非常直观，这也是我们最常见的模块化架构。
- 优点
- 架构直观，可以让加入开发的新成员比较快速的理解项目的构建
- 团队协作灵活，在项目开发阶段（特别是起始不稳定的阶段），有更多的module依赖选择，例如直接依赖project，或者通过aar/jar依赖，或者是maven依赖，可以更加快速的进行开发调试
- 缺点
- 整个project的git分支会很复杂
- 团队协作的时候，大家都是在同一个app模块中做测试自己开发的模块，比较容易产生冲突
- 因为所有的module都在一个project中，每个人都可以修改他人负责的module，不是很安全
multi-project模式
multi-project图例
如上图所示，这种模式是将每个功能模块都拆分成一个单独的功能project，每个功能project都至少包含自己测试使用的app模块和功能模块这两个module。此外，还有一个专门的project用来作为app壳工程，组合所有的功能模块。这样每个project都有自己的单独的git仓库和单独的测试使用的app模块。
- 优点
- 每个project有自己单独的git仓库，减少项目的git复杂度
- 每个project有自己的app模块用于测试，避免影响他人
- 开发成员只需要负责自己的project，不需要关注其他的功能模块，更加专注
- 开发成员只能关注自己负责的功能模块，无法修改到其他人负责的功能模块，更加安全
- 更加解耦
- 缺点
- 对于新加入的开发成员不是很友好，不能直观的了解项目的构建
- 需要在项目开发前达成一些规范协议，否则在协作时容易产生冲突，比如资源文件的命名，如果在两个module中出现命名一样的资源文件，则会报错
- 因为每个功能都是单独的project，所以开发调式时，只能使用aar/jar或者maven来依赖需要的module，不如submodule模式灵活，在项目初期不稳定时的开发成本要高于submodule模式
- 会增大项目的体积
建议
以上两种模式笔者均在项目中实践过，各有优势，不分高下，下面是笔者的几个小建议。
- 在个人开发或者小团队开发时，没有必要使用multi-project模式，成本太高
- 开发小项目时，submodule模式足以，如果项目后期变的越来越大，可以在转multi-project模式
- 在项目前期不稳定时，如果要使用multi-project模式架构，对于基础组件与公共组件部分尽可能的要考虑完善，否则每次更改都需要重新发布aar/jar或者上传到maven仓库中，成本较高（毕竟Android Studio的运行速度有时确实不尽人意）
感谢
以上观点内容主要源于《饿了么》资深Android开发工程师张涛在2018年的携程技术沙龙移动技术专场中的技术分享。
