Gradle Java模块缓存是否已废弃？如今模块能否提升增量构建速度？

所谓「模块缓存」是否是已废弃的旧功能 #

首先明确：Gradle官方从未推出过独立的「模块缓存」功能，早年大家普遍以为的「仅修改A模块就只重构建A」的模块缓存效果，本质是对Gradle通用任务级缓存机制的具象化误解。
Gradle从早期版本到现在，增量构建、构建缓存的核心判断粒度始终是任务（Task），逻辑是校验每个任务的输入、输出是否发生变化，和模块没有直接绑定关系。之前用户感知到的「模块级缓存」效果，只是因为单个模块的修改通常只会影响模块内部的任务输入，其他无依赖模块的所有任务输入无变化，就会命中UP-TO-DATE检查直接跳过，看起来像是整个模块被缓存了而已，官方文档自然不会单独列出不存在的「模块缓存」相关说明。

当前使用多模块依然可以大幅缩短增量构建耗时 #

多模块拆分对增量构建效率的提升是长期有效的，核心原因如下：

• 模块拆分可以天然隔离变更的影响范围：单个模块的代码修改，只会触发自身任务、以及依赖该模块的上游模块的相关任务执行，完全不会波及无依赖关系的其他模块，跳过的任务量随模块拆分粒度细化会大幅增加
• 结合Gradle现有优化机制收益更高：当前Gradle的增量编译、构建缓存、配置缓存等特性，都能在多模块架构下最大化发挥作用，比如仅修改模块A的内部实现未改动公共API时，甚至依赖A的上游模块的编译任务都可以直接跳过，不需要重新执行
• 多模块架构还支持并行执行无依赖的模块任务，全量构建时的速度提升也非常明显

内容的提问来源于stack exchange，提问作者Sami