Unveiling the Unseen Threat: Demystifying Memory Leaks in Android
summary
Explains how Android memory leaks occur when short‑lived objects like Activity or View get referenced by long‑lived holders such as singletons or ViewModel and remain reachable so GC doesn't free them, shows that leaks are often silent and require long runs to surface, and demonstrates practical tooling: LeakCanary hooks lifecycle, keeps WeakReference to destroyed Activities and triggers a heap dump saved as .hprof, then uses Shark to trace paths from GC roots to leaked objects for diagnosis.
AI-written summary · about
chapters (9)
- 0:00Introduction
- 2:08What are memory leaks
- 6:25Memory leaks in Android
- 8:35Detecting leaks with tools
- 10:01LeakCanary detection
- 14:53Analyzing leak categories
- 15:57Common causes and tips
- 19:54Production performance monitoring
- 20:37Closing thoughts and Q&A
related talks
42mSpeaking of Leaking
33mNuking Nasty Memory Leaks
47mLeakCanary, and Then? Unraveling Android Memory Leaks
31mA Small Leak Can Sink A Great Ship
37mRoot causing memory growth with LeakCanary 3
34mMemory Leaks & Performance Considerations: A Cookbook
53mMemory on Android, Leaks and OOM
49mPokeLeaks: Gotta Catch 'em All