10

我一直听到关于即时运行的讨论，好像它的状态很好，但是我和我的团队经常遇到该功能的重大问题，并且因此而降低了编码体验。

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

似乎大多数时候，小的变化仍然需要 40 秒。有时是 6 秒，但这种情况很少见。

感觉很像即时运行降低了我们持续有效地工作的能力。以下是我们的一些应用特定配置：

安卓工作室 2.1.1，安卓插件 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

我们做错了什么，还是有人找到了解决办法？

编辑：几个开发人员似乎遇到了这个问题。我在这里跟踪一个错误。随意给它加星标并加入讨论。

4

1 回答 1

1

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

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

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

于 2016-12-07T04:07:34.090 回答