A Small Leak Can Sink A Great Ship
summary
Memory leaks silently drive heap growth until short GCs (2–5 ms) give way to stop‑the‑world large GCs (50–100 ms) and eventual OOMs; detection is automated by LeakCanary 2 (rewritten in Kotlin) which watches destroyed activities/fragments, waits thresholds (5 retained when visible, 1 in background), triggers heap dumps, and analyzes with Shark to produce leak traces. The workflow includes a leak re‑upload service that logs traces as non‑fatal errors via Crashlytics.recordException, surfaces counts in Crashlytics, and wires to CI, Slack and Jira.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 1:30What is a memory leak
- 2:56App memory structure
- 7:35Android memory management
- 13:16Impact of memory leaks
- 15:02Detecting memory leaks
- 16:30LeakCanary 2 overview
- 21:27Integrating LeakCanary
- 23:54Leak detection in tests
- 24:37Automating leak reporting
- 26:44Firebase Crashlytics setup
- 29:35Best practices to avoid leaks
- 30:40Closing thoughts
related talks
35mA small leak can sink a great ship
37mLeakCanary, then what? Nuking Nasty Memory Leaks
37mRoot causing memory growth with LeakCanary 3
33mNuking Nasty Memory Leaks
24mUnveiling the Unseen Threat: Demystifying Memory Leaks in Android
37mUniversal heap trimming with LeakCanary 3
39mLeakCanary 2: Leaner, Better, Faster, Kotliner!
42mSpeaking of Leaking