Android Studio 编译慢并不一定意味着电脑需要升级。一个中型项目从按下运行按钮到安装成功，往往要经历 Gradle 配置解析、依赖下载与冲突解决、Java/Kotlin 源码编译、资源合并与处理、DEX 转换、APK 打包等多个阶段。任何一个环节被低效配置拖住，都会让整体耗时成倍增加。要真正解决卡顿，应当先找到时间究竟耗在了哪里，再针对构建链路中的关键节点做减法。
如果只是修改 gradle.properties 里的内存参数，效果通常并不明显。原因在于卡顿可能是多个因素叠加的结果：依赖树过于庞大、模块拆分不合理、Kotlin 注解处理器仍然使用缓慢的 kapt，或者 IDE 自身缓存目录被安全软件实时扫描。下面从测量、配置、依赖、编译策略和硬件环境五个层面，给出可落地的优化路径。
一、先用构建报告定位耗时任务
优化之前需要数据支撑。Gradle 提供了 --profile 参数，可以在构建结束后生成一份 HTML 报告。在项目根目录执行 ./gradlew assembleDebug --profile，构建完成后打开 build/reports/profile 目录下的报告文件，按耗时排序即可看到每个任务的执行时间。
常见的耗时大户包括 :app:compileDebugKotlin、:app:mergeDebugResources、:app:dexBuilderDebug 和 :app:packageDebug。如果 Kotlin 编译占用了百分之六十以上的时间，重点应放在 Kotlin 编译参数和注解处理器上；如果依赖解析时间异常长，则需要检查依赖树和仓库顺序。不要凭感觉猜测瓶颈，报告会直接指出最值得处理的前几个任务。
在 Android Studio 中也可以使用 Build Analyzer：从 Build 窗口点击构建记录，右侧面板会显示各阶段耗时、插件耗时以及告警提示。该工具更适合日常快速分析，不需要记住命令行参数。
二、调整 Gradle 与 JVM 参数，解除默认限制
Gradle 默认给 JVM 分配的内存通常只有 1GB 左右，对于大型项目远远不够。项目根目录的 gradle.properties 是优化构建的第一个切入点。通过增加堆内存、开启并行与缓存，可以在不修改代码的前提下获得明显提速。
org.gradle.jvmargs=-Xmx4g -XX:MaxMetaspaceSize=1g -XX:+UseParallelGC org.gradle.parallel=true org.gradle.caching=true org.gradle.configureondemand=true org.gradle.daemon=true android.enableJetifier=false
org.gradle.parallel=true 允许 Gradle 并行执行相互独立的模块任务，多核 CPU 项目收益明显。org.gradle.caching=true 开启构建缓存，让未变化的输入直接复用上次输出。org.gradle.configureondemand=true 则会跳过未请求模块的配置阶段，适合多模块但每次只运行单个模块的场景。需要留意 android.enableJetifier 如果项目已经全面迁移到 AndroidX，应设为 false，避免额外的字节码转换开销。
堆内存大小要根据机器实际可用内存设置，过大会触发系统交换分区反而变慢。一般笔记本 16GB 内存可以给 Gradle 分配 3GB 到 4GB，32GB 内存可以尝试 6GB。还要检查 gradle.properties 中是否存在 org.gradle.jvmargs 的重复定义，多个模块的配置可能互相覆盖。
三、精简依赖树与模块边界
依赖解析是构建初期的重要耗时环节。执行 ./gradlew :app:dependencies 可以打印完整的依赖树，很多重复或冲突的库会拖慢资源合并和 DEX 转换。应优先使用 implementation 替代 api，因为 api 会把依赖暴露给所有下游模块，一旦发生变化就会引发大范围重新编译。
对于大型项目，可以按业务域拆分模块，但模块数量不宜过多。十几个小模块虽然能减少单模块编译范围，却增加了配置解析和模块间依赖检查的成本。通常单个模块的源码规模控制在合理区间，配合 implementation 的严格边界，才能让增量编译只发生在受影响的模块内。使用 Gradle Version Catalog 统一管理依赖版本，也能减少动态版本解析带来的网络请求。
此外，关闭不需要的构建特性可以降低任务数量。在模块的 build.gradle 中按需启用 buildFeatures，例如不使用 DataBinding 就将其关闭，不生成 BuildConfig 也可以设置 buildConfig false。每个被关闭的特性都对应着一组可以跳过的任务。
四、加速 Kotlin 编译并迁移 kapt 到 KSP
Kotlin 编译是 Android 项目中最容易成为瓶颈的环节之一。在 gradle.properties 中可以给 Kotlin 编译守护进程单独分配内存，并保持增量编译开启：
kotlin.incremental=true kotlin.daemon.jvmargs=-Xmx3g kotlin.compiler.execution.strategy=in-process
kotlin.compiler.execution.strategy=in-process 让 Kotlin 编译器直接在 Gradle 守护进程中运行，减少进程间通信开销，适合中小型项目；大型项目也可以使用 daemon 策略并调大守护进程内存。若当前项目仍在使用 kapt 处理注解，建议评估迁移到 KSP，因为 KSP 不生成 Java 存根，能显著降低注解处理时间。将依赖从 kapt 改为 ksp，并把注解处理器替换为对应的 KSP 版本，常见库如 Room、Glide、Hilt 都已支持。
迁移过程可以逐步进行：先在一个模块中把 kapt 依赖替换为 ksp，验证生成代码无误后再推广到其他模块。即便无法立即迁移，也应当检查 kapt 是否使用了 correctErrorTypes 等降低性能的选项，并尽量把注解处理器的依赖范围缩小到真正需要的模块。
五、利用增量构建、构建缓存与配置缓存
增量构建和缓存是提升二次编译速度的关键。Gradle 会检查输入和输出的变化，只有当源码或资源真正变动时才重新执行任务。确保 org.gradle.caching=true 已经开启，并且在命令行构建时添加 --build-cache 参数，可以让不同工程之间也复用相同输出的缓存。
配置缓存则更进一步，将整个构建的配置阶段结果保存下来，下次运行直接加载配置。在 gradle.properties 中加入 org.gradle.configuration-cache=true 即可启用。不过该特性在某些插件或自定义 Task 中可能存在兼容性问题，建议先在分支上验证，确认没有序列化错误后再合并到主分支。对于 CI 环境，可以结合远程缓存服务，让团队共享构建缓存，减少每个开发者的重复编译。
./gradlew assembleDebug --build-cache --parallel
在本地开发时，尽量避免使用 clean 命令。频繁 clean 会清空所有增量信息，下一次必须执行完整构建。只有在出现缓存异常或构建产物错误时才需要清理，日常改代码直接运行 assembleDebug 或 installDebug 即可。
六、优化 IDE 与系统运行环境
Android Studio 自身也需要合理配置。打开 Help 菜单中的 Edit Custom VM Options，为 IDE 进程分配足够的堆内存，例如 -Xmx4g。同时关闭不常用的插件，尤其是某些第三方 UI 插件会持续占用后台线程。在 Settings 中关闭不必要的自动导入和实时检查功能，也能降低界面卡顿。
系统层面的干扰常常被忽略。Windows 自带的 Defender 或第三方杀毒软件如果实时扫描项目目录，每一次文件变动都会触发安全检测，严重拖慢编译。可以将项目目录、.gradle 目录和 Android SDK 目录加入排除列表。固态硬盘对随机小文件读写提升巨大，如果项目仍放在机械硬盘上，迁移到 NVMe SSD 往往比升级 CPU 更有效。
最后，保持电源模式为高性能，避免笔记本在电池供电时进行降频。CPU 核心数方面，Gradle 并行任务数量默认等于处理器核心数，物理核心数越多，并行编译收益越大。对于使用 AMD 或 Intel 大小核架构的处理器，可以结合系统调度工具让 Gradle 进程尽量运行在高性能核心上。
Android Studio编译速度性能优化修改时间：2026-08-24 04:25:45