Skip to content

Performance monitoring

Performance monitoring samples the device while it runs and charts the result. It is the module most people open first, and the one where reading the numbers correctly matters most.

  1. Select the device and scope to an app.
  2. Open Performance.
  3. Press start, drive the app on the device, press stop.

The chart updates live; the capture is what you keep.

Percentage of a core, so a value above 100% is normal on a multi-core device and simply means more than one core is busy. What matters is the shape: a flat 40% during scrolling is a workload, a 5% baseline that spikes to 90% for 200 ms is a stall.

Percentage of GPU utilisation. High GPU with a stable frame rate is fine. High GPU with a dropping frame rate means you are render-bound — too much overdraw, too many layers, effects that force offscreen passes.

Resident footprint of the process. Watch the trend rather than the value: a sawtooth that returns to the same floor is a working cache, a staircase that never comes back down is a leak. iOS kills processes that climb too far, and that kill looks like a crash with no exception in the report.

Frames per second as presented. See FPS and jank — the average is nearly useless on its own, and the dips are the whole story.

Bytes in and out for the process. This is volume, not content — the performance module counts traffic, it does not read it. A useful shape: a screen that pulls megabytes on open shows up here long before anyone looks at the requests. For the requests themselves, use the packet-capture module.

An energy-impact figure rather than milliamp-hours. Useful comparatively — this build against the last one, your app against another — rather than as an absolute. For an absolute answer over days, see usage history.

Capture the same interaction on both and put the two runs side by side. This is the honest way to answer “is our app heavy?”, because “heavy” only means anything relative to something.

A mini-program runs inside a host app, so scoping to the host measures the host plus everything in it. Scope to the mini-program’s own process instead when the question is about the mini-program.

  • Sample the same interaction each time. Scroll the same list the same distance. Two captures of different interactions are not a comparison.
  • Let the device settle. The first seconds after a launch are dominated by startup work.
  • Watch thermal state. A hot phone throttles, and a throttled capture describes the temperature, not the code.
  • Use a real device, not the newest one. The flagship on your desk is not what your users have.

The performance overview is free. Performance charts and performance history are paid — see pricing.

FPS and jank · Energy · Usage history