先定位真瓶颈：运行./gradlew --profile build查看耗时报告，若某任务占30%以上（如mergeDebugResources、compileDebugKotlin），应优先分析其成因而非盲目调参；配置优化需匹配实际瓶颈，否则无效。
先跑 ./gradlew --profile build，看耗时报告里哪个任务占了 30% 以上——别调任何配置，先定位真瓶颈。
为什么不能一上来就改 gradle.properties
很多人看到构建慢，第一反应是开并行、加大内存、开缓存。但实际项目里，org.gradle.parallel=true 对单模块项目几乎没用；-Xmx4g 在 GC 不频繁时也压根不生效；org.gradle.caching=true 如果本地没配 build-cache 目录或远程服务，只会默默 fallback 到无缓存状态。更常见的是：90% 的时间卡在 mergeDebugResources 或 compileDebugKotlin 这类任务上，而它们的耗时和 JVM 参数关系极小，和资源格式、Kotlin 编译器插件、模块耦合度强相关。
真正该优先检查的，是构建链路中「非预期高耗时环节」：
-
Configuration阶段耗时高 → 说明build.gradle里写了太多运行时逻辑（比如遍历文件、读取环境变量、动态生成 task） -
download类任务排前三 → 网络或仓库配置问题，不是 Gradle 本身慢 -
transform或process开头的任务持续 >10s → 资源未压缩、AAPT2 启动卡顿、或开启了冗余的代码扫描（如lint插入到主构建流）
怎么快速判断是不是网络/依赖下载拖慢了构建
执行 ./gradlew build --dry-run，观察输出里是否大量出现 Resolve files of configuration ':app:debugRuntimeClasspath' 这类日志。如果它反复出现且耗时长，再补一句 ./gradlew --refresh-dependencies build ——如果这次明显变慢，基本锁定是依赖解析问题。
进一步验证：
- 打开
~/.gradle/caches/modules-2/metadata，看对应依赖的元数据文件时间戳是否异常陈旧（比如早于你上次更新依赖的时间） - 手动 curl 一下
build.gradle里repositories声明的 URL，例如curl -I https://maven.aliyun.com/repository/central，确认响应头有200 OK且time_namelookup和time_connect都在 200ms 内 - 检查是否误启用了
mavenLocal()，尤其当本地~/.m2/repository里有损坏的 POM 文件时，Gradle 会卡在解析阶段不报错只干等
Daemon 没起作用的典型信号
运行 gradle --status，如果输出为空，或显示 No daemons are currently running，说明 Daemon 根本没活下来。这不是配置没开，而是被外力杀掉了：
- CI 脚本里写了
gradle --stop或pkill -f gradle——每次都是冷启动，构建时间天然比本地多 30%~50% - Android Studio 设置里勾选了
Delegate IDE build/run actions to Gradle，但又在 Terminal 里用不同 JDK 运行./gradlew，导致 Daemon 进程被隔离，无法复用 - IDEA 的
Help → Edit Custom VM Options里加了冲突参数（比如同时设了-XX:+UseG1GC和-XX:+UseParallelGC），JVM 启动失败后自动降级为无 Daemon 模式
容易被忽略的「隐性卡点」：AGP 版本与资源处理
Android Gradle Plugin 8.0+ 默认启用 AAPT2 的增量编译，但如果你项目里还保留着 android.enableAapt2=false（旧版迁移残留），或者 build.gradle 中强制关了 android.experimental.useNewResourceProcessor=true，那所有资源合并都会退回到全量重处理模式。一个含 200 张图的 module，mergeDebugResources 可能从 1.2s 涨到 8.7s。
这类问题不会报错，也不会出现在 profile 报告的「Top Tasks」前列（因为它被拆成几十个子任务分散计时了），但你能在 app/build/intermediates/incremental/mergeDebugResources/ 目录下观察到每次构建都清空重来——这就是最直接的证据。
真正的提速起点，从来不是堆参数或镜像源，而是看清构建过程里哪一步在「假装工作」：是反复下载同一个依赖，还是每次都在重解压 WebP，又或者只是因为某段 Groovy 脚本在配置阶段读了三次 local.properties。盯住耗时数字，而不是配置项名字。
