Android Instant Run慢速构建

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

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

编辑:几个开发人员似乎遇到了这个问题.我在这里跟踪一个错误.随意加星标并添加到讨论中.

Answer 1

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

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

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