skip to content

In Flutter, what is the Dart VM service, and what does the DevTools network view record through it?

level: middleimportance: should knowfreq 30%

answer

  1. the URL flutter run prints
  2. debug and profile, not release
  3. dart:io HttpClient, dio included
  4. http_profile-based clients
  5. --start-paused for startup traffic

basics

~20 s

The Dart VM service is the tooling protocol a debug or profile Flutter app exposes; flutter run prints its URL. Through it, the DevTools network view records HTTP, HTTPS and WebSocket traffic from dart:io (dio included) and http_profile clients.

solid answer

~40 s

The **Dart VM service** is the debugging and inspection protocol the Dart runtime exposes; `flutter run` prints "A Dart VM Service on <device> is available at: ..." and DevTools, IDE debuggers, hot reload and the terminal commands all talk to it. It exists in debug and profile builds; release builds disable debugging and service extensions. The **network view** records **HTTP, HTTPS and WebSocket** traffic that goes through `dart:io`, such as `HttpClient` and packages built on it like `dio`, plus traffic from clients that report through `http_profile`, such as `cupertino_http`, `cronet_http` and `ok_http`. I can search, filter with keys like `m:get s:404 t:json`, and inspect headers, bodies and timing. Web apps use the browser's network tools instead, and to capture startup requests I run `flutter run --start-paused` and resume once recording has begun.

code

bash · 3 lines
bash
# Start paused so startup requests are recorded
flutter run --start-paused
# Open the printed DevTools link, go to Network, confirm recording, then resume the app.

go deeper

for a junior

Know that DevTools connects through the Dart VM service whose URL flutter run prints, and that the network view shows the app's HTTP requests.

for a middle

Explain which builds expose the VM service, what traffic the network view records (dart:io, dio, http_profile clients), and how to filter and capture startup requests.

for a senior

Show you can explain a missing request (web build, unsupported client, recording started late) and pick profile mode when you need realistic behaviour with tools attached.

for a principal

Recognise that release builds have no such window, and plan the logging, metrics and error reporting that replace DevTools in production.

## The Dart VM service When a Dart program runs on the Dart VM with debugging enabled, the VM exposes a **service protocol**, a JSON-RPC interface over a local WebSocket, that lets tools inspect and control it: list isolates, pause and resume, set breakpoints, evaluate expressions, read heap statistics, and call **service extensions** that the Flutter framework registers. `flutter run` prints its address, for example: ``` A Dart VM Service on Pixel 8 is available at: http://127.0.0.1:52345/abc=/ ``` Everything interactive in the Flutter dev loop rides on it: - **DevTools** (inspector, memory, logging, network, debugger); - **IDE debuggers** and their breakpoints; - **hot reload** and the `flutter run` terminal keys. ## Which builds expose it | Mode | VM service | Consequence | |---|---|---| | Debug | yes, with service extensions | every DevTools view, hot reload, breakpoints | | Profile | yes, with some service extensions | profiling, tracing, source-level tools can connect | | Release | no; debugging disabled | no DevTools connection at all | That is why in-app diagnostics for release must come from logging and error reporting rather than DevTools. ## The network view The DevTools **network view** inspects **HTTP, HTTPS and WebSocket** traffic of a Dart or Flutter app. What it records: - all traffic that originates from **`dart:io`**, such as `HttpClient` and packages built on it, including **`dio`**; - traffic from clients that log through **`http_profile`**, which includes **`cupertino_http`**, **`cronet_http`** and **`ok_http`**. For a **web** app, requests go through the browser, so the docs recommend the browser's own developer tools instead. ## Using it 1. Open the Network page; recording starts immediately. **Pause** and **Resume** control it. 2. Each request appears in the table as **Pending** until its response completes. 3. Select a request to see general and timing information, request and response headers, and bodies. 4. Use search and the filter dialog. Filter keys: `method` or `m`, `status` or `s`, `type` or `t`; other text matches method, URI, status and type. For example `my-endpoint m:get t:json s:200` or `https s:404`. ## Capturing startup traffic Requests sent during app startup happen before you can open DevTools. The documented workaround: 1. Start the app paused with `flutter run --start-paused` (for a Dart program, `dart run --pause-isolates-on-start --observe`). 2. Open DevTools from the printed link and go to the Network page. 3. Make sure recording has started, then **resume** the app. ## Interview angles - "Why does my request not show up?" It did not go through `dart:io` or an `http_profile`-aware client, or the app is a web build, or it happened before recording started. - "Can I use DevTools against a release build?" No; there is no VM service. Use profile mode for realistic performance with tooling attached. - HTTP requests are also visible as asynchronous events on the performance timeline, which helps line them up with frames.

  • A Flutter web app's API calls never appear in the DevTools network view; why?
    On the web, requests go through the browser, not through `dart:io` or an `http_profile`-aware client, so the network view has nothing to record. The docs recommend the browser's developer tools for web network traffic.
  • How do you filter the DevTools network view down to failed JSON GET requests?
    Use the filter keys in the search field: `m:get t:json` narrows by method and type, and adding a status such as `s:500` or `s:404` narrows by status code. Text without a key, such as an endpoint fragment, is matched against method, URI, status and type.

saying these in an interview costs you the question

  • DevTools can attach to a release build through the VM service.
  • The network view records browser fetch requests of a Flutter web app.
  • Only the http package's traffic is recorded, never dio's.
  • Startup requests are always captured if you open DevTools quickly enough.
  • The VM service is a remote production monitoring endpoint.