先用--profile定位瓶颈：执行./gradlew assembleDebug --profile，查看build/reports/profile/下HTML报告中的Configuration（若超40%说明脚本/插件过重）和Execution阶段（单任务耗时长则查编译/缓存），再结合--scan深入分析模块与插件级耗时。
用 --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 到全量配置，还额外增加了依赖图分析开销。
实测中，中大型 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或KotlinCompiletask 的输入文件列表是否异常庞大（比如整个src/main/java被当成输入）→ 可能 sourceSets 配置错误，导致增量编译失效 - IDEA 里点击 Run 按钮慢，但命令行
./gradlew run正常 → 问题在 IDE 的构建集成层，不是 Gradle 本身
真正难排查的，往往是那些“看起来很快、但总要等几秒才开始真正干活”的间隙——比如 Daemon 启动后等待 JVM 类加载完成、或 AGP 初始化 native toolchain 的过程。这些不会出现在 --profile 的 task 表里，得靠 --debug 日志逐行扫 Starting Build 到第一个 task 开始之间的日志块。
