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链接后,怎么读?我一般按这个顺序来:

  1. 看总耗时——先确认是不是真的慢
  2. 看Task执行时间——按耗时排序,找出前几名
  3. 看缓存命中率——如果命中率低于80%,说明配置有问题
  4. 看依赖下载——是不是每次都在下载同样的东西

举个例子。有一次我发现某个项目的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 知识体系 Build Scan 发布构建扫描 --scan 参数 build-scan 插件 Gradle Enterprise 分析构建性能 Task耗时排序 缓存命中率 依赖下载分析 团队协作 分享Scan链接 CI自动发布 构建对比 发布 → 分析 → 协作 让构建优化有据可依

从发布到分析,再到团队协作,Build Scan把构建优化从「个人经验」变成了「团队数据」。我建议你从今天开始,每次构建都加上--scan。坚持一周,你会发现自己对项目的理解深了一个层次。

最后一个小建议:别等到构建慢到忍不了才用Scan。把它当成日常工具,就像git log一样。你会发现很多潜在问题,在它们变成灾难之前就被解决了。


公众号:蓝海资料掘金营,微信deep3321