Android's Multidex Slows Down App Startup
Article Summary
Michael Ma from Groupon discovered that enabling multidex increased their Android app startup time by 15% on pre-Lollipop devices. Here's how his team clawed that performance back.
When Android apps hit the 65k method limit, multidex is the standard solution. But this convenience comes with a hidden cost: significantly slower app launches on devices running KitKat and below. Groupon's engineering team documented their journey to identify and fix this performance regression.
Key Takeaways
- Multidex caused 15% slower app startup on all Android 4.4 and earlier devices
- Pre-Android 5.0 devices have extra overhead loading classes from secondary dex files
- Using ClassLoader.findLoadedClass() identifies which classes to move into main dex
- Moving startup-critical classes to main dex restored original performance levels
- Treat multidex as last resort after code cleanup and refactoring options
By identifying and relocating startup-critical classes to the main dex file, Groupon eliminated the 15% performance penalty and matched pre-multidex startup speeds.
About This Article
Groupon hit Android's 65k method limit and turned to multidexing. The Gradle plugin's Proguard analysis created an incomplete maindexlist.txt file, which led to java.lang.NoClassDefFoundError exceptions when the app started up.
Michael Ma's team made a multidex.keep file with the classes that were throwing NoClassDefFoundError exceptions. They wrote a build.gradle script that merged this file with the auto-generated maindexlist.txt before the app compiled.
The team used ClassLoader.findLoadedClass() at runtime to find which classes needed to load at startup, then moved those classes to the main dex file. This got Groupon's app startup performance back to where it was before multidexing, across all the devices they tested.