Profiling with Flutter DevTools: CPU, Memory, and Network

Profiling with Flutter DevTools: CPU, Memory, and Network

Flutter DevTools is the official, browser-based performance suite for Flutter and Dart applications. It ships with the Flutter SDK and connects to a running app over the VM Service protocol. In this lesson you will learn how to open and use three of its most powerful tabs — Performance (CPU flame charts), Memory (heap allocations), and Network (HTTP traffic) — so that you can diagnose real performance problems rather than guessing at them.

Opening Flutter DevTools

There are two fast ways to open DevTools while your app is running:

• From the terminal — after flutter run --profile, press V (capital) in the terminal to open DevTools automatically in your default browser.
• From VS Code / Android Studio — click the DevTools icon in the debug toolbar, or run the Open DevTools command from the command palette.
• Standalone — run dart devtools and paste the VM Service URL shown in the terminal.

Once open, you will see a tab bar across the top: App Size, Performance, CPU Profiler, Memory, Network, Logging, and more. Focus on Performance, Memory, and Network for this lesson.

The Performance Tab — CPU Flame Charts

The Performance tab lets you record a timeline trace of a real interaction and visualise it as a flame chart. Each horizontal bar represents a function call; its width is proportional to the time it consumed. Bars are stacked vertically to show the call chain.

Key sections in the flame chart:

• UI thread — Dart code: your build() calls, gesture callbacks, and state updates. Anything over ~8 ms here threatens 60 fps.
• Raster thread — GPU rasterisation of the layer tree. Expensive shaders, compositing, and saveLayer calls appear here.
• Frame legend — the coloured frame indicators at the top; red frames exceeded the 16.6 ms budget.

// Run the app in profile mode
// flutter run --profile

// Then in your terminal press 'V' to open DevTools,
// navigate to the Performance tab,
// click "Record" (or press the record button),
// perform the interaction in your app (e.g. scroll a list),
// click "Stop" — the flame chart renders automatically.

// A typical slow build frame looks like this in Dart:
class HeavyListItem extends StatelessWidget {
  final int index;
  const HeavyListItem({super.key, required this.index});

  @override
  Widget build(BuildContext context) {
    // BAD: expensive work inside build() — shows as wide bar in flame chart
    final items = List<int>.generate(1000, (i) => i * index);
    return ListTile(title: Text('Item $index: ${items.last}'));
  }
}

In the flame chart you would see HeavyListItem.build as an unusually wide bar. Move the expensive work outside build() — to a cached variable, a FutureBuilder, or a separate isolate — and re-record to confirm the frame time drops.

The Memory Tab — Heap Allocations

The Memory tab shows a live timeline of your app's heap usage and lets you take heap snapshots to inspect which objects are alive and how much memory they occupy. The key metrics are:

• Dart Heap — memory allocated by your Dart code (objects, closures, collections).
• External — native memory referenced by Dart objects (decoded images, platform channel buffers).
• GC events — vertical markers showing when garbage collection ran; frequent GC spikes can cause jank.

// BAD: creating a new ImageProvider on every build — prevents cache reuse
class LeakyAvatar extends StatelessWidget {
  final String url;
  const LeakyAvatar({super.key, required this.url});

  @override
  Widget build(BuildContext context) {
    return CircleAvatar(
      // NetworkImage is recreated each build; old one lingers until GC
      backgroundImage: NetworkImage(url),
      radius: 40,
    );
  }
}

// GOOD: cache the provider in the State so it is created once
class CachedAvatar extends StatefulWidget {
  final String url;
  const CachedAvatar({super.key, required this.url});

  @override
  State<CachedAvatar> createState() => _CachedAvatarState();
}

class _CachedAvatarState extends State<CachedAvatar> {
  late final ImageProvider _provider;

  @override
  void initState() {
    super.initState();
    _provider = NetworkImage(widget.url); // created once
  }

  @override
  Widget build(BuildContext context) {
    return CircleAvatar(backgroundImage: _provider, radius: 40);
  }
}

To confirm a fix: take a snapshot before the fix, interact with the app to trigger the leak, take a second snapshot, and compare the two. The Memory tab's diff view shows which class instances grew — a class that should be a singleton but has 50 instances is an immediate red flag.

The Network Tab — HTTP Traffic

The Network tab records every HTTP and HTTPS request made through Dart's dart:io HttpClient (and therefore through the http and dio packages). For each request you can inspect the URL, method, status code, request and response headers, body size, and timeline (DNS lookup → connection → TLS → TTFB → download).

Common findings from the Network tab:

• Requests fired on every frame inside build() instead of initState().
• Large uncompressed response bodies that could be gzip-compressed server-side.
• Missing Cache-Control headers causing repeated downloads of static assets.
• Waterfalled requests that could be parallelised with Future.wait().

Putting It All Together — A Profiling Workflow

A disciplined profiling session follows this sequence:

• 1. Identify the symptom — a specific interaction that feels slow or a screen that uses too much memory.
• 2. Record in Performance tab — find the red frames and the widest bars in the UI thread.
• 3. Check Memory tab — take before/after snapshots around the interaction; look for objects that should be released but are not.
• 4. Inspect Network tab — confirm no redundant requests are running during the slow interaction.
• 5. Fix one thing at a time — change one variable, re-profile, and measure the impact before moving on.