Android Instant Run Slow Builds

Question

I keep hearing instant run discussed as if it's in a great shape, however my team and I regularly experience significant issues with the feature, and a degraded coding experience because of it.

Before instant run, our clean builds were ~1min 30sec, and after that we'd get builds that were ~25sec or the occasional 40sec. While instant run does indeed seem to decrease builds sometimes to 6-12 seconds, other times, it's caused us to get into crazy long builds that we've seen take as long as 13 minutes, largely offsetting any gains from the incremental compile.

It also seems that a majority of the time, small changes are still taking 40 seconds. Sometimes it's 6 seconds, but that's pretty rare.

It feels a lot like instant run has degraded our ability to work consistently and efficiently. Here are some of our app specific configurations:

Android Studio 2.1.1, Android Plugin 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

Are we doing something wrong, or has anyone found a work around?

EDIT: Several devs seem to be encountering this. I'm tracking a bug here. Feel free to star it and add to the discussion.

Lilias

Not that it is an answer, but we decided to hold off on utilizing the instant run feature until they have some of the apparent kinks worked out. We were having inconsistent issues and they certainly seemed to contradict the efficient development idea. – Weasner

"...as if it's in great shape". Welcome to the world of Android Studio PR. The AS team release new features that just aren't ready for prime time, with the belief that developers will just "get used to it" - Instant Run is no exception (excuse the pun). My experience is that AS seems to be getting progressively worse with each release... – Mozellemozes

ADT had better execution speed than Studio is having(in building apk and loading projects), Adding more features in every release is making android studio to become a memory eater. – Stowers

I've found that the move the gradle overall has been much better. I've gained a lot of flexibility with my builds, and the build time overall has decreased fairly significantly. I'm fine with AndroidStudio / IntelliJ eating up as much memory as it wants. That's how the IDE can be so fast. Memory is dirt cheap these days. All my computers for the past 5 years have had at least 16GB of ram. – Lilias

Answer 1

We're getting much better performance out of instant run now. Here are the changes we made:

1. We found out that Lombok was causing a memory leak in the daemon with instant run. We identified the memory leak because using a freshly warmed up daemon, our build would take ~15 seconds, but after an hour of building the app with changes, our build would start taking >1 minute for the simplest changes. We found that migrating our app off of lombok fixed the memory leak.
2. We stopped using instant-run hot and warm code swapping. We found that these often caused errors or problems, not to mention that you needed to pay attention to whether or not what you were changing required the Application to be reloaded. Instead we started using the cold swap feature. Cold swap is triggered by the "Rerun" button, which is 4 buttons to the right of the play / start button in Android Studio. It's the stop button with the arrow coming out the left hand side and going up. Cold swapping the code in instant run we found more reliable, and it also performs a full application restart, essentially acting like a normal build, except faster.
3. Upgraded to the latest Android Studio plugin version. The plugin has gotten better. It still has issues, but it's better. I expect more bug fixes with plugin 2.3

Overall it's still not perfect. I still have to endure strange build issues, and do build cleans occasionally. Still feels like a beta.

Lilias