Android Instant Run 构建缓慢

Question

我一直听到有人讨论即时运行，好像它的状态很好，但是我和我的团队经常遇到该功能的重大问题，并因此导致编码体验下降。

在即时运行之前，我们的干净构建大约需要 1 分 30 秒，之后我们会得到大约 25 秒或偶尔 40 秒的构建。虽然即时运行有时确实似乎将构建时间减少到 6-12 秒，但在其他时候，它会导致我们进入疯狂的长时间构建，我们已经看到它需要长达 13 分钟，这在很大程度上抵消了增量编译带来的任何 yield 。

似乎大多数时候，小的变化仍然需要 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

我们是不是做错了什么，或者有人找到了变通办法吗？

编辑:一些开发者似乎遇到了这个问题。我正在跟踪 a bug here.欢迎加注星标并加入讨论。

Answer 1

我们现在从即时运行中获得了更好的性能。以下是我们所做的更改:

1. 我们发现 Lombok 在即时运行的守护进程中导致了内存泄漏。我们发现内存泄漏是因为使用刚预热的守护进程，我们的构建将花费大约 15 秒，但在构建应用程序更改一个小时后，我们的构建将开始花费 > 1 分钟来进行最简单的更改。我们发现将我们的应用程序从 lombok 迁移出来修复了内存泄漏。
2. 我们停止使用即时运行的热代码和暖代码交换。我们发现这些通常会导致错误或问题，更不用说您需要注意您正在更改的内容是否需要重新加载 Application。相反，我们开始使用冷交换功能。冷交换是由“重新运行”按钮触发的，它是 Android Studio 中播放/开始按钮右侧的 4 个按钮。这是停止按钮，箭头从左手边出来并向上。我们发现在即时运行中冷交换代码更可靠，它还会执行完整的应用程序重启，本质上就像正常构建一样，只是速度更快。
3. 已升级到最新的 Android Studio 插件版本。插件变得更好了。它仍然有问题，但它更好。我希望插件 2.3 能修复更多错误

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