构建速度优化
问题
Android 项目构建慢如何优化?有哪些提速方案?
答案
构建耗时分析
# 生成构建扫描报告
./gradlew assembleDebug --scan
# 查看每个 Task 耗时
./gradlew assembleDebug --profile
# 报告在 build/reports/profile/
优化策略总览
Gradle 配置优化
gradle.properties
# 开启并行编译
org.gradle.parallel=true
# Gradle Daemon 常驻内存
org.gradle.daemon=true
# JVM 内存配置
org.gradle.jvmargs=-Xmx4g -XX:+UseParallelGC -XX:MaxMetaspaceSize=512m
# 开启构建缓存
org.gradle.caching=true
# 开启 Configuration Cache(Gradle 8.1+)
org.gradle.configuration-cache=true
# 非 Android 的 Kotlin 项目增量编译
kotlin.incremental=true
kapt → KSP 迁移
kapt 需要生成 Java Stub,是构建最大的瓶颈之一。KSP 直接操作 Kotlin 符号,速度提升约 2 倍:
| 注解处理器 | kapt 支持 | KSP 支持 |
|---|---|---|
| Room | ✅ | ✅ |
| Hilt/Dagger | ✅ | ✅(Hilt 2.48+) |
| Moshi codegen | ✅ | ✅ |
| Glide | ✅ | ✅ |
build.gradle.kts 迁移示例
// ❌ kapt(慢)
// kapt("androidx.room:room-compiler:2.6.0")
// ✅ KSP(快)
ksp("androidx.room:room-compiler:2.6.0")
模块化对增量编译的影响
修改 feature-home 模块的代码:
未模块化(单体):
整个 app 模块重新编译 → 慢
模块化后:
只重新编译 feature-home → 快
其他模块命中缓存 → 跳过
关键指标对比
| 优化手段 | 预估收益 | 实施难度 |
|---|---|---|
| 增大 JVM 内存 | 10-20% | 低 |
| 开启并行编译 | 20-30% | 低 |
| 开启构建缓存 | 30-50% | 低 |
| kapt → KSP | 20-40% | 中 |
| Configuration Cache | 10-20% | 中 |
| 模块化拆分 | 30-60% | 高 |
常见面试问题
Q1: Gradle Configuration Cache 是什么?
答案:
Gradle 的三个阶段(初始化→配置→执行)中,配置阶段会执行所有 build.gradle 脚本来构建 Task 图。Configuration Cache 将 Task 图序列化缓存到磁盘,后续构建如果配置未变化,直接反序列化恢复 Task 图,跳过整个配置阶段。
限制条件:build.gradle 中不能引用全局可变状态(如 System.getenv() 需声明为 Input),否则缓存失效。
Q2: 如何定位构建慢的原因?
答案:
--profile:生成 HTML 报告,查看每个 Task 耗时排名--scan:上传到 Gradle Build Scan 网站,可视化分析,包括 Task 串行/并行、缓存命中率- 常见瓶颈:
kapt*Task 占比最高 → 迁移到 KSP- 首次构建慢但增量构建快 → 正常,关注增量构建时间
lintDebug耗时长 → 开发阶段可禁用:./gradlew assembleDebug -x lintDebug