skip to content

In Flutter DevTools, what do the memory view's Profile Memory, Diff Snapshots and Trace Instances tabs each help you find?

level: juniorimportance: should knowfreq 35%

answer

  1. a chart plus three tabs
  2. allocation by class right now
  3. before and after a feature
  4. who allocates a chosen class
  5. retaining paths on an instance

basics

~20 s

Profile Memory lists current allocation by class; Diff Snapshots compares heap snapshots taken before and after an interaction to show which classes grew and what retains them; Trace Instances records the call stacks that allocate the classes you select.

solid answer

~40 s

The DevTools **memory view** has a live chart plus three tabs. **Profile Memory** shows what is allocated now, per class and memory type, and can refresh on every GC or export CSV. **Diff Snapshots** is the leak tool: I take a heap snapshot, exercise a feature, take another and diff them, which shows per-class changes in instance count, shallow size and retained size, and for a selected class the **retaining paths** that keep its instances alive. **Trace Instances** answers *who allocates this*: I pick classes, use the app, press Refresh and read the allocating call stacks in a bottom-up or call-tree view. The chart above them plots Dart heap, native memory, RSS and GC events over time.

go deeper

for a junior

Remember the three tabs by their question: what is allocated now (Profile Memory), what a feature left behind (Diff Snapshots), who allocates a class (Trace Instances).

for a middle

Explain the snapshot-interact-snapshot-diff workflow, why you repeat the feature, and what instance count, shallow size, retained size and retaining paths each tell you.

for a senior

Show you choose the tool by symptom, read the chart for the trend first, and know the limits: debug-mode numbers carry overhead, and native memory such as images lives outside the Dart heap.

for a principal

Consider how memory checks fit the release process: which flows get a periodic snapshot diff, and when automated leak tests replace manual DevTools sessions.

## The memory view at a glance The **memory view** in Flutter DevTools shows how a running Dart or Flutter app uses memory and gives you tools to find leaks and bloat. It connects to the app through the Dart VM service, so it works with debug and profile builds. It has two parts: an **expandable chart** at the top and **three tabs** below it. ## The chart The chart is a time series polled about every **500 ms**. Its legend includes: - **Dart/Flutter heap**, the objects your Dart code allocated; - **Dart/Flutter native**, memory outside the Dart heap but still in the footprint, such as decoded images or file buffers; - **Allocated**, the capacity of all Dart heaps, usually slightly above the used size; - **RSS**, the process's resident set size; - **GC events** and the engine's **raster cache**. Use it to see the shape of a problem: a heap that returns to the same level after a feature closes is healthy; one that climbs after each repetition is suspicious. ## The three tabs | Tab | Question it answers | How you use it | |---|---|---| | **Profile Memory** | what is allocated right now, by class and memory type | read the table, toggle **Refresh on GC** to watch it live, export CSV | | **Diff Snapshots** | what a feature left behind | snapshot, interact, snapshot again, diff; filter by class or package | | **Trace Instances** | which code allocates a given class | select classes, interact, press **Refresh**, read the call stacks | ### Profile Memory A table of current allocations per class. It is the quickest way to see that, say, thousands of `ChatMessage` objects are alive, or that one class dominates the heap. The class filter is shared with Diff Snapshots. ### Diff Snapshots The tab for leaks. A **heap snapshot** records the objects the VM can reach at that moment and the references between them. The workflow: 1. Bring the app to a baseline state and take a snapshot. 2. Run the feature under suspicion, ideally several times, and return to the baseline screen. 3. Take a second snapshot and **diff** the two. 4. Filter with **Filter classes and packages** to your own package, and sort by instance delta. 5. Select a class to see its instances and their **retaining paths**, the chains of references from a root that keep each instance alive. The diff reports instance counts, **shallow size** (the object itself) and **retained size** (what would be freed with it). DevTools assigns an object's size as retained only to the members of its **shortest** retaining path. Snapshots can be exported and later imported for offline analysis. ### Trace Instances When you know *what* grows but not *who creates it*, trace it: 1. Select the classes to trace. 2. Interact with the app to trigger the code. 3. Press **Refresh** and select a traced class. 4. Read the allocation call stacks, either **bottom-up** (the distinct stacks that allocated instances) or as a **call tree** (top-down, expandable callers to callees). ## Choosing the tab - A crash from running out of memory, or a device slowing down: start with the chart and Profile Memory to see what is big. - Memory that grows each time a screen opens and closes: Diff Snapshots and retaining paths. - Unexpected allocation churn from one class: Trace Instances. Older DevTools versions had an *Analysis* tab; DevTools 2.20 retired it and introduced the diff tab that became Diff Snapshots.

  • Why run the same feature several times before taking the second snapshot in Flutter's Diff Snapshots tab?
    A single run mixes a real leak with one-off allocations such as caches, lazily created singletons or fonts. After N repetitions, a leak shows as an instance delta that scales with N, for example five extra `_ChatScreenState` objects after five cycles, while one-time allocations stay constant. That makes the leaking class stand out in the diff.
  • In Flutter DevTools, when would you use Trace Instances instead of Diff Snapshots?
    When you already know which class is growing or churning but not which code creates it. Trace Instances records the allocating call stacks for the classes you select while you use the app, so you land on the constructor call site. Diff Snapshots tells you what survived and what retains it, not where it was allocated.

saying these in an interview costs you the question

  • Profile Memory shows which references keep an object alive.
  • One snapshot is enough to prove a leak.
  • The memory view only shows the Dart heap, not native memory such as decoded images.
  • Trace Instances lists retaining paths for every object in the heap.
  • The memory view works only in release builds because debug numbers are meaningless.