How we achieved a 6x reduction of ANRs - Part 2: Fixing ANRs
Article Summary
Bumble's Android team slashed their ANR (Application Not Responding) rate by 6x. Here's how they debugged one of mobile's most frustrating problems.
ANRs happen when Android's main thread blocks for too long, creating a terrible user experience. Bumble's team discovered that 60% of their ANRs occurred during app startup, triggered by push notification broadcasts.
Key Takeaways
- Cut cold app startup time by 50% through lazy initialization and background tasks
- SharedPreferences apply() can block the main thread during Activity lifecycle events
- Moving push notifications to a separate process reduced ANRs by 2x instantly
- Background app launches took 5 seconds on average, with 3% exceeding the 10 second ANR threshold
By optimizing app startup, fixing SharedPreferences blocking, and isolating push handling in a separate process, Bumble reduced their ANR rate from 0.80% to 0.28%.
About This Article
Bumble found that 60% of ANRs happened during Application.onCreate. Background app launches had 3% exceed Android's 10-second ANR threshold for broadcast receivers, while manual launches had no such limit.
The team used CPU trace dumps from Android Studio's profiler to find bottlenecks. They then applied lazy initialization, moved work to background threads, and turned off third-party content provider auto-initialization to cut startup overhead.
The 95th percentile for cold app startup fell from about 10 seconds to about 5 seconds. This cut the overall ANR count by a third during the first optimization phase, before the team made additional fixes.