Gradle怎么区分配置慢还是任务执行慢-java教程-PHP中文网

先用--profile定位瓶颈：执行./gradlew assembleDebug --profile，查看build/reports/profile/下HTML报告中的Configuration（若超40%说明脚本/插件过重）和Execution阶段（单任务耗时长则查编译/缓存），再结合--scan深入分析模块与插件级耗时。

gradle怎么区分配置慢还是任务执行慢

用 --profile 看清配置阶段和执行阶段耗时分布

Gradle 构建慢，90% 的时间卡在配置阶段或执行阶段，但两者成因完全不同。不区分就调参，大概率白忙活。最直接的办法是加 --profile 参数跑一次构建：./gradlew assembleDebug --profile。执行完会在 build/reports/profile/ 下生成 HTML 报告，打开就能看到三段耗时：Initialization、Configuration、Execution。

重点关注 Configuration 阶段占比——如果超过 40%，说明 build.gradle 脚本解析、插件加载、任务注册这些动作本身太重；如果 Execution 占比高（尤其单个 task 耗时长），才该去查编译器、依赖下载或缓存是否生效。

常见误判场景：

改了一行 Kotlin 代码，assembleDebug 耗时 82 秒，但 --profile 显示 Configuration 占 65 秒 → 实际不是编译慢，而是每次同步都重新解析全部模块的 build.gradle
CI 上 clean + build 总耗时飙升，但报告里 Execution 阶段大量任务标为 SKIPPED → 很可能配置缓存没启用，导致每次都要重走配置流程

用 --scan 快速定位具体哪个模块/插件拖慢配置

--scan 生成的构建扫描报告比 --profile 更细，能穿透到每个 Project 的配置耗时、插件 apply 时间、甚至哪一行 dependencies 块触发了远程仓库查询。执行 ./gradlew build --scan（首次需同意上传），打开链接后点「Configuration」标签页，就能看到按耗时排序的 Project 列表。

典型问题信号：

某个子模块的 Configuration 时间远高于其他模块（比如 3s vs 0.2s）→ 检查它是否用了动态版本号（1.2.+）、是否在 buildscript 里拉了大体积插件
org.jetbrains.kotlin.jvm 插件配置耗时 >1.5s → 可能 Kotlin 编译器版本与 Gradle 不匹配，或启用了未优化的 kotlinOptions { freeCompilerArgs += [...] }
大量 afterEvaluate 回调堆积 → 这类闭包会强制延迟到配置末期执行，容易引发隐式依赖和重复计算

为什么 configureOnDemand 在多模块项目里反而让配置更慢

org.gradle.configureondemand=true 听起来很合理：只配置当前需要的模块。但它有个关键前提——模块间依赖关系必须静态可推导。一旦项目里存在 project(':lib').tasks.findByName('jar') 这类运行时反射式引用，Gradle 就无法安全跳过其他模块的配置，最终 fallback 到全量配置，还额外增加了依赖图分析开销。

Gradle 9.8.0

下载

实测中，中大型 Android 项目开启 configureondemand 后，--profile 显示 Configuration 阶段反而增加 15~20%，因为：

Gradle 要反复扫描所有 build.gradle 文件，尝试推断哪些模块真正被依赖
AGP（Android Gradle Plugin）内部大量使用 afterEvaluate 和 project.afterEvaluate，与 on-demand 机制冲突
IDEA/AS 的 Gradle Sync 默认已做轻量级按需加载，命令行再开 on-demand 属于重复决策

建议：除非是纯 Java 多模块且无跨模块 task 引用的项目，否则关掉 configureondemand，改用 org.gradle.parallel=true + org.gradle.caching=true 更有效。

执行慢但 profile 显示 task 是 up-to-date？那问题不在 Gradle

如果 --profile 报告里绝大多数 task 都标着 UP-TO-DATE 或 FROM-CACHE，但整体耗时仍高，说明瓶颈根本不在 Gradle 任务调度层。这时候要往外看：

检查是否卡在 Download https://repo.maven.apache.org/... —— 这属于网络 IO，跟 Gradle 无关，得配国内镜像或离线仓库
观察 JavaCompile 或 KotlinCompile task 的输入文件列表是否异常庞大（比如整个 src/main/java 被当成输入）→ 可能 sourceSets 配置错误，导致增量编译失效
IDEA 里点击 Run 按钮慢，但命令行 ./gradlew run 正常 → 问题在 IDE 的构建集成层，不是 Gradle 本身

真正难排查的，往往是那些“看起来很快、但总要等几秒才开始真正干活”的间隙——比如 Daemon 启动后等待 JVM 类加载完成、或 AGP 初始化 native toolchain 的过程。这些不会出现在 --profile 的 task 表里，得靠 --debug 日志逐行扫 Starting Build 到第一个 task 开始之间的日志块。