推荐文章
项目模块化的两种模式
目前项目模块化大体可以分为两种模式,分别是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年的携程技术沙龙移动技术专场中的技术分享。