Plug the Leak: Memory Management in Flutter
summary
A small demo app deliberately leaks a TextEditingController left undisposed and a singleton list that adds a million objects per tap, producing 3 leaks and about 6 million objects (~90 MB) visible in the profiler. Diagnosis uses Flutter DevTools memory view together with leak_tracker package to locate the retaining path to initState and the offending methods. Fixes are concrete: call dispose, null out surviving references, use weak references or mixins for disposal, enable lint rules and prefer const where possible.
AI-written summary · about
chapters (9)
- 0:00Introduction
- 2:07What is memory leak
- 5:38Objects and references
- 8:28Memory allocation
- 12:03Finding memory leaks
- 19:05Fixing common leaks
- 21:14Optimization techniques
- 27:42Recap and summary
- 29:06Q&A and closing
related talks
21mAdvanced Memory Management in Flutter
34mLet’s Talk About Memory Leaks In Dart And Flutter
41mCrash-Proof Flutter: Building Apps That Refuse to Die
40mThread by Thread: The Hidden Battle for Flutter Stability
35mA small leak can sink a great ship
34mMemory Leaks & Performance Considerations: A Cookbook
47mLeakCanary, and Then? Unraveling Android Memory Leaks
25mMemory leaks on Android: lessons learned and methodology