一、背景

项目需求的频繁迭代，新的产品功能在不断添加和延伸，随之带来的是，项目技术复杂度的提升。

近几年来，Android模块化、组件化相关技术得到极速发展，将项目整体进行分层，不同的层次之间依据实际的技术功能或业务支撑或业务模块去划分具体的组件或模块，是组件化或模块化一致的行动方向。

复杂的产品功能，往往也带来组件化或模块后具有多个组件或模块。对于相对稳定，或具有复用能力的模块，可以直接形成独立的模块，并通过独立Git库或项目模块形式进行管理，像引入外部库一样，以独立aar形式引入。但项目主工程自身，最终还是具有相对复杂的模块目录。在实际使用中，这往往可能带来视图上的不便。此时，我们可以通过Module目录分组来解决。

二、Module目录结构分组

2.1 模块目录分组划分

我们可以直观一点，感受下项目主工程Module视图展示，下图是一个对应示例。

主工程模块划分相对容易理解，主要包括了三个方面：
1，基于业务视角下的业务模块划分。如新闻模块，视频模块，运营广告模块，登录注册模块等；
2，面向特定变体或构建配置下的基础性功能模块。Eguan模块，Dev模块等；
3，模块壳工程。如各个业务模块对应的壳工程，以方便开发过程中针对单个模块实现安装调试等。

示例中只是一个相对简单的主工程目录结构，在实际复杂些的项目中，主工程模块将更加繁杂。这些模块之间，从本身的职责定位上来看，是应该具有不同的层次划分的，对应的，最好应该有不同的Module分组。否则整个主工程结构看上去，很是有凌乱感。

本示例中，对于上述的“面向特定变体或构建配置下的基础性功能模块”和“模块壳工程”，其实与项目实际面向用户的主体构建时，关系并不大。我们可以将其放置到对应的Module分组中。

于是，我们可以对应创建两个分组，对应的其实就是两Directory，分别叫Extends和Module_App，分别用来放置上述的两种职责定义下的模块。

最终，主工程模块目录视图为：

Extends和Module_App展开后的视图显示为：

顿时倍感清晰，有木有？

但此时，项目是不能直接构建成功的。

2.2 修正模块引用配置

Module目录结构已经发生了变化，对应需要此Module的配置，也是需要去修正的。以工程settings.gradle文件为例，初始，对应配置如下：

include ':App', ':News', ':Videos', ':Message', ':Comments', ':Pictures', ':Personal', ':Base', ':LoginReg', ':ActAd', ':Main'

include ':Dev', ':Eguan'

include ':Main_App', ':News_App', ':ActAd_App', ':Message_App', ':Comments_App', ':LoginReg_App', ':Personal_App', ':Pictures_App', ':Videos_App'

复制代码

每个模块名称前面有个:，表示的是相对于当前主工程的根目录。现在部分模块的目录路径变化了，对应修正如下：

include ':App', ':News', ':Videos', ':Message', ':Comments', ':Pictures', ':Personal', ':Base', ':LoginReg', ':ActAd', ':Main'

include ':Extends:Dev', ':Extends:Eguan'

include ':Module_App:Main_App', ':Module_App:News_App', ':Module_App:ActAd_App', ':Module_App:Message_App', ':Module_App:Comments_App', ':Module_App:LoginReg_App', ':Module_App:Personal_App', ':Module_App:Pictures_App', ':Module_App:Videos_App'

复制代码

同样的，如果其他模块对Module路径变化了的模块有依赖，对应也需要修正。如Main模块依赖Dev模块，初始配置如下：

devImplementation project(':Dev')

复制代码

现在，需要修正如下：

devImplementation project(':Extends:Dev')

复制代码

全部修正完成，我们重新构建项目，发现项目.idea目录下的modules.xml配置文件已自动更新了。

同时，Extens和Module_App目录自身，也自动生成了对应的.iml文件。

同时，具体模块下，iml模块配置也自动进行了修正。

此时，构建成功。

PS：如果实际项目在更改成Module分组，并修改完配置后，仍然构建有不成功，可以尝试如下步骤：
1，gradlew清除缓存：

./gradlew clean

复制代码

2，AS清除缓存：

File >> Invalidate Caches / Restart >> Invalidate And Restart

复制代码

3，删除主工程根目录下的缓存文件：

直接删除.idea目录，重启AS，会自动重新生成

复制代码

三、结语

复杂的项目中，往往具有复杂的模块划分。依据不同的模块职责，将其归纳到不同的Module分组中，使得平时项目开发时，有更好的清晰的视图结构，可以将注意力更多的专注于项目真正模块主体的开发。

模块目录结构的改变，实际上只是相对于项目根目录的路径发生了变化。对应的，我们只需要修正对应的引入到此模块的配置即可(往往都是对应的.gralde文件)，其他都没有任何变化。

在实际项目开发中，依据实际情况，适当通过Module分组方式，可以获得更加清晰的项目视图结构。

end~