17、构建扫描:Build Scan介绍、发布构建扫描、分析构建性能、团队协作
说实话,很多团队用Gradle好几年,构建慢得跟蜗牛似的,却从来不知道问题出在哪。
我记得刚接手一个遗留项目时,每次构建都要跑6分多钟。大家习以为常,甚至养成了「按了构建就去倒杯咖啡」的习惯。后来我用Build Scan一查,好家伙,一个过时的插件占了将近一半的时间。
Build Scan,说白了就是Gradle给你的一份「构建体检报告」。它能告诉你每一步花了多久、下载了什么、缓存命中了多少。今天我们就把它聊透。
什么是Build Scan
Build Scan是Gradle官方提供的一个构建分析工具。它会把一次构建的完整信息上传到云端(或者你自己的服务器),生成一个可分享的网页链接。
这个链接里有什么?
- 每个Task的执行耗时
- 依赖下载的详细记录
- 缓存命中与未命中的原因
- 构建失败的具体堆栈
- 插件和配置的版本信息
我个人习惯在每次性能优化前后都跑一次Scan,对比数据。你想想看,没有数据支撑的优化,那不叫优化,叫玄学。
核心价值:Build Scan把「我觉得构建慢」变成了「构建慢在Task X,耗时Y秒,原因是Z」。
发布构建扫描
发布Build Scan非常简单。Gradle从4.3版本开始内置了--scan参数。
./gradlew build --scan
运行完这条命令,控制台会输出一个链接。比如:https://scans.gradle.com/s/abc123。点开它,你就看到了完整的构建报告。
嗯,这里要注意:默认情况下,Scan会上传到Gradle的公共服务器。如果你有隐私顾虑,可以部署自己的Gradle Enterprise实例。我曾在金融项目里遇到过客户死活不肯用外部服务,最后我们搭了内部服务器,一样好用。
如果你用的是Gradle 6.0及以上版本,还可以通过插件方式更精细地控制:
// build.gradle
plugins {
id 'com.gradle.build-scan' version '3.16'
}
buildScan {
termsOfServiceUrl = 'https://gradle.com/terms-of-service'
termsOfServiceAgree = 'yes'
publishAlways() // 每次构建都自动发布
}
发布后,你可以设置链接的有效期。默认30天,付费版可以永久保存。
小技巧:在CI/CD流水线中加上--scan参数,每次构建都自动生成报告。出了问题直接翻Scan,比看一堆控制台日志高效得多。
分析构建性能
拿到Scan链接后,怎么读?我一般按这个顺序来:
- 看总耗时——先确认是不是真的慢
- 看Task执行时间——按耗时排序,找出前几名
- 看缓存命中率——如果命中率低于80%,说明配置有问题
- 看依赖下载——是不是每次都在下载同样的东西
举个例子。有一次我发现某个项目的compileJava任务耗时异常,点进去一看,它居然在每次构建时都重新处理所有源文件。原因是什么?增量编译被一个自定义插件关掉了。
Build Scan的界面里,每个Task都可以展开。你会看到:
- Task的输入和输出文件
- 是否被缓存
- 执行结果(成功/失败/跳过)
- 耗时分布图
我曾经遇到过一个经典问题:构建时间从2分钟突然涨到10分钟。查Scan发现,一个测试任务里有个循环打印日志的代码,每次构建要输出几十万行。去掉那行日志,时间直接回到2分钟。
避坑指南:我曾经见过有人只看总耗时,不看细分。结果优化了半天,发现慢的是网络下载,跟构建脚本半毛钱关系没有。记住:先定位,再优化。
团队协作
Build Scan最被低估的功能,其实是协作。
你想想看,以前你跟同事说「构建好慢啊」,对方只能回一句「是啊」。现在你可以直接把Scan链接丢到群里:「看,Task X占了60%的时间,谁有空看看?」
具体怎么用?
- Code Review时附上Scan链接——证明你的改动没有拖慢构建
- 新人入职时分享历史Scan——让他快速了解项目构建的瓶颈
- 每周构建健康报告——把Scan数据导出,对比趋势
我带的团队有个习惯:每次合并PR前,CI会自动跑一次Build Scan。如果构建时间比上次增加了20%以上,Scan链接会直接@相关开发者。这个机制逼着大家关注构建性能,而不是「反正能跑就行」。
另外,Gradle Enterprise还支持构建对比功能。你可以把两次构建的Scan放在一起,逐项对比差异。比如:
| 指标 | 优化前 | 优化后 | 变化 |
|---|---|---|---|
| 总耗时 | 6分12秒 | 2分08秒 | -65% |
| 缓存命中率 | 34% | 89% | +55% |
| 依赖下载次数 | 47次 | 12次 | -74% |
这种数据摆在面前,你说服老板升级硬件、重构脚本,底气都足很多。
一句话总结:Build Scan不只是给开发者看的,它是整个团队优化构建效率的「共同语言」。
知识体系图
下面这张图梳理了本章的核心逻辑:从发布Scan,到分析性能,再到团队协作,环环相扣。
从发布到分析,再到团队协作,Build Scan把构建优化从「个人经验」变成了「团队数据」。我建议你从今天开始,每次构建都加上--scan。坚持一周,你会发现自己对项目的理解深了一个层次。
最后一个小建议:别等到构建慢到忍不了才用Scan。把它当成日常工具,就像git log一样。你会发现很多潜在问题,在它们变成灾难之前就被解决了。
公众号:蓝海资料掘金营,微信deep3321