介绍
Build Performance 用于观察构建耗时变化，识别慢任务和可疑配置，让构建优化从感觉变成可追踪的数据。
为什么使用 Build Performance
Android 构建慢通常不是单一原因造成的，可能来自依赖解析、annotation processing、资源处理、未命中缓存、配置阶段开销或 CI 环境差异。
核心能力
- 记录构建耗时、任务状态和历史趋势。
- 识别耗时任务、重复构建步骤和可疑配置。
- 结合 Gradle 配置给出本地或 CI 优化建议。
- 帮助团队在发版节奏中持续关注构建健康。
功能细节
能力 1
记录构建耗时、任务状态和历史趋势。
能力 2
识别耗时任务、重复构建步骤和可疑配置。
能力 3
结合 Gradle 配置给出本地或 CI 优化建议。
能力 4
帮助团队在发版节奏中持续关注构建健康。
典型工作流
- 运行一次或多次构建以采集耗时数据。
- 查看任务耗时排行和历史趋势。
- 根据建议调整缓存、并行构建或模块配置。
- 对比优化前后的构建时间。
适合的使用场景
- 构建时间突然变慢时快速定位方向。
- 比较本地和 CI 构建差异。
- 为多模块或多 flavor 项目建立构建性能基线。
开始使用
- 在 ADB Pro 工具窗口中打开 Build Performance 标签页。
- 确认当前 Android 项目已经完成 Gradle 同步，并选择需要处理的模块或产物。
- 按页面提示执行扫描、分析或生成操作。
- 查看结果、日志和建议，再决定是否应用到项目配置中。
验证方式
- 重新执行相关 Gradle 构建或分析任务，确认没有新的错误。
- 检查输出日志和 IDE 面板结果，确认状态、路径和产物符合预期。
- 如果改动会影响 release 包，建议结合 Release Readiness 再做一次发布前检查。
常见问题
这个功能会直接修改项目文件吗？
默认以扫描、分析和结果展示为主。只有在你明确执行应用、生成或注入配置等操作时，才会修改项目文件。
适合在发版前什么时候运行？
建议在 release 构建产物生成后运行，并在上传应用商店或交给 QA 前结合 Release Readiness 做一次完整确认。
它和其他 ADB Pro 功能如何配合？
这个功能通常和 Build Tools、AAB Tools、Signing Tools 或 Release Readiness 串联使用，用来把单点操作放进完整 Android 发版流程。