gradle构建变慢的根源常是配置阶段执行耗时操作，如i/o、网络请求或遍历目录，应移至dofirst/dolast或用provider延迟求值，并通过--dry-run和构建扫描验证优化效果。
Gradle 构建变慢，如果根源在配置阶段执行了耗时操作，问题会很隐蔽但影响巨大——它会让 每次构建都卡在解析脚本环节，哪怕你只运行 ./gradlew clean 或 tasks 这类轻量命令。关键在于：配置阶段不是“干活”的地方，而是“画任务图”的地方，任何耗时逻辑放在这里，都会拖垮整个构建流程。
识别配置阶段的耗时行为
常见陷阱包括：
- 在
build.gradle顶层或 task 配置块中直接调用new File(...).listFiles()、FileUtils.copyDirectory()等 I/O 操作 - 执行网络请求，比如检查远程 API、读取外部配置服务返回值
- 遍历大量子项目或资源目录并做复杂判断（如递归扫描 assets 文件夹）
- 在
android {}或dependencies {}块外写死逻辑，例如def version = getLatestVersionFromMavenCentral()
把耗时逻辑移出配置阶段
核心原则是：只在真正需要执行任务时才运行这些代码。推荐做法是封装进 doFirst 或 doLast 闭包：
-
doFirst：任务开始前执行，适合做前置校验（如检查文件是否存在）、动态设置输入参数 -
doLast：任务完成后执行，适合做结果处理、日志上报、归档等 - 避免在
configure、afterEvaluate或顶级脚本中做实际工作
示例改造：
❌ 错误写法（配置阶段就执行）：
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
task copyAssets {
if (!new File("src/main/assets/data").exists()) {
throw new GradleException("Missing assets!")
}
from "src/main/assets"
into "$buildDir/output"
}
✅ 正确写法（仅在任务执行时校验）：
task copyAssets {
from "src/main/assets"
into "$buildDir/output"
doFirst {
if (!fileTree("src/main/assets/data").matching { include "**/*.json" }.files.isEmpty()) {
throw new GradleException("No JSON assets found!")
}
}
}
用 lazy 属性和 provider 替代即时计算
Gradle 6.0+ 推荐使用 Provider 和 RegularFileProperty 等延迟求值类型，它们不会在配置阶段触发实际读取：
- 用
project.layout.projectDirectory.file("config.yaml")替代new File("config.yaml") - 用
providers.fileContents(...).map { ... }延迟解析内容 - 用
project.providers.systemProperty("env").forUseAtConfigurationTime()显式声明哪些系统属性必须提前读取
验证优化是否生效
改完后，用以下方式确认配置阶段不再“卡住”：
- 运行
./gradlew --dry-run assembleDebug：只走配置阶段，不执行任务。观察耗时是否明显下降 - 启用构建扫描：
./gradlew assembleDebug --scan，在生成的报告中查看 “Configuration time” 占比 - 添加 JVM 参数
-Dorg.gradle.configuration-cache=true（需 Gradle 6.6+），强制启用配置缓存，它会直接报错指出所有非法的配置期操作
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
