运行gradle build --profile生成html报告可直观定位初始化、配置、执行三阶段耗时，重点关注configuration time是否下降及execution time中compilejava、mergedebugresources等任务占比。
用 --profile 快速定位耗时阶段
最直接的方式是运行 gradle build --profile，它会在 build/reports/profile/ 下生成 HTML 报告，展示初始化、配置、执行三个阶段各自耗时。重点关注「Configuration time」是否明显下降——如果优化了配置缓存但这里没变，说明缓存没生效或脚本不兼容；如果「Execution time」里 compileJava 或 mergeDebugResources 占比仍高，说明并行或增量编译可能未触发。
跑 gradle-profiler 做可重复的基准测试
gradle-profiler 不是看单次结果，而是多次运行取平均值，能排除瞬时干扰。比如对比开启 org.gradle.parallel=true 前后：
- 先执行
gradle-profiler --benchmark --project-dir . :app:assembleDebug - 改完
gradle.properties后再跑一次，观察total build time和task execution time的变化幅度 - 注意加
--no-daemon参数会强制冷启动，这反而会掩盖 daemon 优化效果，日常测试应保持 daemon 开启
检查构建缓存命中率是否真实提升
光开 org.gradle.caching=true 不等于缓存就起效。运行构建后看控制台输出是否有类似 Cached output of task ':app:compileDebugKotlin' is up-to-date 的提示；更可靠的是在 ~/.gradle/caches/build-cache-1 目录下观察文件增长，或用 gradle build --scan 查看在线构建扫描报告里的「Cache statistics」面板——命中率低于 60% 通常意味着任务输入不稳定（比如动态读取时间戳、随机数）或环境变量未声明为 inputs.property。
增量构建必须用真实代码变更来验证
很多人误以为 clean + build 就能测出增量效果，其实不是。clean 会清掉所有中间产物，根本不会走增量逻辑。正确做法是：
- 先完整构建一次（确保所有任务 up-to-date）
- 只改一个
.java文件里的一行代码 - 再跑
gradle compileJava，观察是否只有该文件被重编译，且耗时远低于全量编译 - 如果
compileJava依然跑了全部源文件，检查是否禁用了kotlin.incremental或 Java 编译器参数里漏了-parameters
build.gradle 里调用了 System.getenv()，整个缓存就会静默失效。这些细节不会报错，但会让优化形同虚设。
