安卓即时运行缓慢构建

Question

我经常听到讨论立即运行的优点，但我的团队和我经常遇到这个功能的显著问题，并因此而导致编码体验下降。

在使用立即运行之前，我们的干净编译需要约1分30秒，然后我们会得到大约25或偶尔40秒的构建。尽管立即运行确实有时会将编译时间缩短至6-12秒，但其他时候，它会导致我们进入疯狂长时间的编译，我们见过最长的编译时间长达13分钟，很大程度上抵消了增量编译所带来的任何收益。

看起来大部分时间，即使是小更改编译仍需40秒。有时只需要6秒钟，但这相当罕见。

感觉立即运行已经降低了我们持续高效地工作的能力。以下是我们应用程序的一些特定配置：

Android Studio 2.1.1、Android插件2.1

multiDexEnabled true

dexOptions {
  preDexLibraries true
  javaMaxHeapSize "4g"
  maxProcessCount 4
  incremental true
  dexInProcess true
}

org.gradle.daemon=true
org.gradle.parallel=true
org.gradle.jvmargs=-Xmx6g -XX:MaxPermSize=512m

我们是否做错了什么，或者有人找到了解决方法吗？

编辑：好几个开发者都遇到了这个问题。我正在这里追踪一个错误。请随意标记它并参与讨论。

- spierce7

---

不是答案，但我们决定暂停使用即时运行功能，直到他们解决一些明显的问题。我们遇到了不一致的问题，它们似乎与高效开发的理念相矛盾。 - zgc7009

欢迎来到Android Studio PR的世界。AS团队发布了一些新功能，但它们似乎并不是完全准备好的，他们认为开发人员会“适应”的 - Instant Run也不例外（请原谅双关语）。我的经验是，随着每次发布，AS似乎越来越糟糕...就像它处于良好状态一样。 - adelphus

ADT在构建apk和加载项目方面的执行速度比Studio更好，每个版本都添加更多功能使得Android Studio变成了一个内存食客。 - Maveňツ

我发现gradle的转移整体效果要好得多。我的构建变得更加灵活，总体构建时间也显著减少了。我不介意AndroidStudio / IntelliJ占用尽可能多的内存。这就是IDE能够如此快速的原因。如今内存非常便宜。过去5年中，我所有的电脑都至少有16GB的内存。 - spierce7

Answer 1

我们现在能够更好地利用即时运行的性能。以下是我们所做的更改：

1. 我们发现 Lombok 引起了守护进程的内存泄漏，导致即时运行出现问题。我们通过使用一个新开启的守护进程进行构建，构建需要约15秒，但在一个小时之后，对应最简单的变更需要超过1分钟才能完成。我们发现将应用迁移出 lombok 可以修复内存泄漏问题。

2. 我们停止使用即时运行的热交换和预热。这些往往会导致错误或问题，而且你需要注意是否更改需要重新加载应用程序。相反，我们开始使用冷交换功能。冷交换由“重新运行”按钮触发，在 Android Studio 中为播放/启动按钮右侧的第四个按钮。它是带有向左和向上箭头的停止按钮。我们发现在即时运行中进行代码的冷交换更加可靠，而且它还执行了完整的应用程序重启，基本上像普通构建一样，只是更快。

3. 升级到最新的 Android Studio 插件版本。插件已经得到了改进。它仍然存在问题，但比以前更好了。我期待插件 2.3 会有更多的 bug 修复。

总体来说还不是完美的。我仍然不得不忍受奇怪的构建问题，并偶尔进行构建清理。仍然感觉像一个测试版。

- spierce7