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

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

编辑：几个开发者似乎遇到了这个问题。我正在跟踪a bug here.随意加注并加入讨论。

Answer 1

我们现在可以通过即时运行获得更好的性能。以下是我们所做的更改：

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

Android Instant Run慢速构建

1 个答案: