Detecting Memory Leaks in Android Applications
Article Summary
Dropbox's Android team was fighting OutOfMemoryError crashes. The culprit? Memory leaks hiding in activity lifecycles that traditional debugging couldn't catch.
Lily Chen from Dropbox shares how her team built an automated system to detect and fix memory leaks before they reach production. The post covers common leak patterns, detection strategies using LeakCanary, and practical fixes that reduced crashes.
Key Takeaways
- Fragment views referencing long-lived services create leaks between onDestroy callbacks
- LeakCanary integrated with Bugsnag and CI tests surfaces leaks automatically
- ViewBindingHolder eliminates boilerplate and prevents view lifecycle leaks in fragments
- Temporal leaks from async tasks require longer profiling to distinguish from real issues
Automating leak detection in CI with LeakCanary catches bad patterns before production, teaching engineers better coding practices while protecting users on lower-end devices.
About This Article
Dropbox engineers had a hard time tracking down memory leaks. When OutOfMemoryError crashes happened, they only saw the final screen that ran out of memory, not where the leak actually started or why.
Lily Chen's team added LeakCanary to their process and used custom annotations like @SkipLeakDetection to control when leak detection ran in CI tests. This gave them heap dump analysis and leak traces right when the leaks occurred.
LeakCanary caught leaks in CI before they reached production. One example was MvRx mocks that weren't cleaned up properly and held onto 198KB of memory. Finding these issues early helped engineers write better code and kept crashes away from users with lower-end devices.