Question 1

There is jank in the app — how do you diagnose it?

Accepted Answer

Step by step: (1) run in profile mode, because debug numbers mislead; (2) use the performance overlay to identify which interaction janks — scrolling, a transition, an animation; (3) open that frame in the DevTools timeline and see whether the time went to the UI thread or the raster thread; (4) UI thread → CPU profiler and rebuild counts; raster thread → painting complexity. Only then do I change anything, and I re-measure the same scenario to confirm the fix actually worked. Changing code without measuring is guessing.

Question 2

How do you find a memory leak?

Accepted Answer

I build a repeatable scenario: open and close the suspect screen ten times. In the DevTools Memory tab I watch whether retained memory fails to come back down after a GC — that confirms a leak. Then I take a heap snapshot and check how many instances of my own classes (_OrderScreenState, say) survive: with the screen closed it should be zero. Following the retaining path almost always lands in the same place — a StreamSubscription, an AnimationController or a listener never removed in dispose(). Prevention: write dispose() when you create the screen rather than leaving it for later.

Question 3

Why are measurements in debug mode misleading?

Accepted Answer

In debug mode Dart runs under the JIT without optimisation, and assertions, service extensions and debug checks are all active. The result is an app substantially slower than a release build — sometimes several times over. The practical danger: jank you see in debug may not exist in release, so you spend time fixing a problem that is not there; or the reverse, something that looks fine in debug becomes a problem in release. So performance decisions are made in profile mode and, where possible, on a real device — emulators introduce distortions of their own.

Symptom	Where to look	Typical cause
Stutter while scrolling	Performance → frame timeline	A heavy `itemBuilder`, non-const items
Freeze when a screen opens	CPU Profiler	Heavy synchronous computation or a large JSON parse
Memory grows over time	Memory → allocations	An uncancelled subscription or controller
A widget is unexpectedly large	Inspector → Layout Explorer	The parent passed tight constraints

DevTools and profiling

📚 Sources and documentation