Android Gradle 多模块架构治理

摘要：多模块可以缩小代码边界、改善并行开发和构建缓存，但拆分本身不会自动带来更好的架构。本文从模块职责、依赖方向和构建配置介绍治理方法。

一、明确拆分目标

模块化可能为了隔离业务、复用基础能力、限制依赖或缩短局部构建时间。目标不同，模块边界也不同。先记录当前痛点和构建耗时，再决定按业务域、平台能力或层次拆分。

不要只按包名机械拆模块。一个模块应有清楚的责任、稳定的公开接口和合理的变更频率。过细拆分会增加构建配置和依赖管理成本。

二、设置依赖方向

应用模块可以依赖功能模块，功能模块依赖领域接口和基础能力。基础模块不应反向依赖具体功能。若两个功能相互引用，应重新审视边界，或抽取双方认可的契约。

公共模块要谨慎扩张。一个不断加入任意工具的公共模块会成为新的耦合中心。共享能力应按职责划分，并说明其公开接口。

三、区分模块类型

没有 Android 资源或组件的领域逻辑可以使用纯 Kotlin 模块，便于快速测试。包含界面、清单或资源的功能则需要 Android 插件。模块类型应反映实际内容，不要为统一而让业务逻辑依赖不需要的平台能力。

四、管理构建约定

集中依赖版本和编译约定能减少重复配置。抽取约定插件应建立在重复真实存在的基础上；过早抽象会让构建失败需要跨多个文件排查。

构建脚本应尽量声明式，避免配置阶段进行文件扫描、网络请求或复杂代码生成。大型任务要准确声明输入输出，才能正确使用构建缓存。

五、控制 API 和资源暴露

默认隐藏模块内部实现，只有下游确实需要编译的类型才作为公开 API。减少不必要的传递依赖可以降低改动影响范围。

资源也是模块接口的一部分。明确主题、字符串、图像资源的归属，避免多个功能重复定义同名全局资源。

六、逐步迁移与测量

先选边界稳定、依赖较少的功能，抽出接口后移动实现，再检查资源、清单和测试归属。每一步保持可编译状态，观察增量构建和完整构建变化。

构建性能应通过任务和配置耗时报告判断。模块数量不是变快的充分条件，过深的依赖链也可能带来额外开销。

七、持续维护

在代码评审中检查依赖方向和新增公共 API。可以使用架构约束防止功能模块互相依赖。定期删除无人使用的模块和抽象，避免结构只增不减。

八、总结

有效模块化建立在清楚边界和可验证的依赖方向上。明确拆分目标，逐步迁移，并用构建测量验证收益，模块结构才能真正服务于开发效率。