How does the DevTools memory view help you actually detect a genuine memory leak, such as one caused by forgetting to properly dispose of a controller or cancel an active stream subscription?

The DevTools memory view lets you take and carefully compare memory snapshots at two genuinely different points in time, such as immediately before and then again immediately after repeatedly navigating to and then back away from a specific screen several times in a row, and if the total number of instances of a specific class, such as a particular AnimationController or a StreamSubscription, keeps steadily and consistently growing across each successive navigation cycle rather than properly returning back down to its original expected baseline count, that is a genuinely strong, telling indicator of an actual real memory leak, most commonly caused by forgetting to properly call dispose or cancel on that specific object at the appropriate correct point in its own lifecycle.

@override
void dispose() {
  _controller.dispose();
  _subscription.cancel();
  super.dispose();
}