第四节：获取构建性能数据——用数据说话，而不是猜

做性能优化，最怕什么？凭感觉乱调。我见过太多人一上来就改 Gradle 配置，改完发现更慢了。其实第一步很简单：先拿到真实数据。Gradle 给了我们三把尺子——--profile、--scan 和 Android Studio 内置的 Build Analyzer。这三样东西，说白了就是帮你看清「时间都花在哪了」。

我个人习惯先把三种方法都跑一遍，交叉对比。为什么？因为每个工具看到的维度不一样，合起来才完整。下面我分别说说怎么用，以及你在实际项目中会碰到哪些坑。

1. 用 --profile 生成性能瀑布图

这个参数是最直接的。你加在 gradle 命令后面，构建完就会在项目根目录下生成一个 build/reports/profile/ 目录，里面有个 HTML 文件。打开它，你会看到一张瀑布图。

./gradlew assembleDebug --profile

这个报告分成三大块：

• 配置阶段：Gradle 解析 build.gradle 文件的时间。如果你有几十个模块，这里可能就占了十几秒。
• 依赖解析阶段：下载和解析远程依赖的时间。慢的话，大概率是某个仓库超时。
• 任务执行阶段：每个 Task 的耗时。这是你真正要关注的重点——哪个 Task 最慢？

我在项目中遇到过一个问题：明明只改了一行代码，但每次构建都要跑 full compile。打开 --profile 一看，有个自定义 Task 的 up-to-date 判断写错了，导致永远都重新执行。所以，profile 报告里每个 Task 的「增量状态」列一定要看。

2. 用 --scan 生成可分享的深度报告

--scan 是 Gradle 团队推出的更强大的分析工具。它会生成一个链接，你可以发给团队成员甚至发给 Gradle 社区求助。

命令很简单：

./gradlew assembleDebug --scan

构建结束后，控制台会打印一个链接，例如：

Publishing build scan...
https://gradle.com/s/abcdef123456

点进去你能看到什么？很多！

• 构建参数、JVM 配置、Gradle 版本
• 每个 Task 的精确耗时、执行顺序
• 依赖树（有没有重复依赖、冲突）
• 缓存命中率（Build Cache 用得好不好）
• 性能警告（比如某个插件拖慢了配置阶段）

我曾经有一次发现项目的构建时间突然多了 30 秒，打开 --scan 一看，有个老旧的插件在配置阶段下载了 200MB 的数据。直接禁用那个插件，构建时间立马恢复正常。所以，--scan 特别适合「增量问题排查」——比如这次构建比上次慢，对比两个 scan 就能定位差异。

3. 用 Android Studio Build Analyzer 做实时分析

Android Studio 4.1 之后内置了 Build Analyzer。它不需要额外命令，你只需要在 IDE 里点一下「Build」→「Analyze Build…」就行。它会自动跑一次构建，然后弹出分析窗口。

Build Analyzer 的最大优点是：可视化瀑布图 + 交互式筛选。你可以直接看到每个 Task 的耗时条形图，点击某个 Task 还能看到它的输入文件、输出文件、依赖关系。如果你在看一个大项目，Build Analyzer 还能帮你快速找到「瓶颈 Task」。

不过要注意，Build Analyzer 只能分析本地那次构建。如果你需要对比不同分支、不同环境的构建性能，还是得靠 --scan 或者自己保存 profile 报告。

三种方式对比表格

我个人的工作流

嗯，这里我分享一个实用流程：

1. 日常开发中，觉得构建慢了，先点一下 Build Analyzer，看一眼瀑布图，心里有个底。
2. 如果想深入排查某个 Task 为什么会慢，我会加 --profile 再跑一次，拿到详细的时间分配。
3. 遇到怀疑是依赖问题或者需要团队协助时，用 --scan 生成链接，贴在聊天工具里。

简单来说，日常看 Analyzer，深入看 profile，分享看 scan。