Flutter Memory Leak Engineering

Operating rules

• Diagnose ownership before adding cleanup calls.
• Treat leak_tracker as lifecycle verification, not as a universal heap leak detector.
• Distinguish notDisposed, notGCed, and gcedLate; they describe different failures and require different fixes.
• Separate disposal from garbage collection: disposed objects can remain retained, and collected objects can still have violated a cleanup contract.
• Prefer one clear owner for every disposable/cancelable/removable resource.
• Keep longer-lived objects from retaining shorter-lived widgets, routes, sessions, controllers, or BuildContext unless the lifetime is intentional.
• Use standard not-disposed checking as the high-signal default; enable expensive/experimental retention diagnostics only for focused investigations.
• Do not silence failures before finding the creation site, owner, teardown path, and retaining reference.
• Do not treat increasing RSS as proof of a tracked Dart lifecycle leak.
• Escalate unresolved growth or retaining chains to Flutter DevTools Memory.
• Keep fixed lifecycle bugs as deterministic regression tests.
• Preserve repository architecture unless ownership/lifetime is actually wrong.

Research baseline and freshness

The supplied guide targets leak_tracker 11.0.2 and the current split between:

• leak_tracker for core tracking/classification;
• leak_tracker_testing for test helpers;
• leak_tracker_flutter_testing for Flutter widget-test integration;
• Flutter FlutterMemoryAllocations for framework lifecycle instrumentation;