This is the fifth day of my participation in the First Challenge 2022

This article, translated from 👉Using the Performance View, is the third article in the DevTools series on how to use the Performance tool.

Past highlights:

👉 DevTools can do

👉 DevTools can do

👉 DevTools Must Know Must Know series – Flutter Inspector

Here is the text

What is Performance?

The Performance view provides information about the Performance and time of the Flutter page. It consists of three parts:

  • Flutter frame table

  • Timeline event table

  • CPU analyzer

Note: Use the Profile pattern to analyze application performance. Frames rendered in Release mode cannot be captured, so profile mode is generally used.

The Performance view also supports data import and export, which will be described later.

Flutter frame table

This table contains the frame information for the Flutter application. Each strip represents a frame of a Flutter. The bars are colored, and different colors represent different jobs on a frame: UI threads, raster threads.

Select a bar and the timeline events associated with that frame are displayed at the bottom of the table. Events are enclosed in blue parentheses.

UI

The UI thread executes the Dart code in the Dart virtual machine: code written by the developer and code for the framework. Our App creates and displays a scene. The UI thread creates a Layer tree, which carries platform-independent rendering information, and then gives the Layer tree to the Raster thread to render on the device. Don’t block the UI thread.

Raster

Raster threads perform graphical processes in Engine. The thread takes the Layer tree and gives it to the GPU to render. The developer cannot directly access the Raster thread and its data, but if the thread is full, the Dart code you develop might be doing too much. Skia runs on this thread.

Sometimes the scene constructed by the Layer tree is easy, but the Raster thread can be heavy to run. In this case, the developer needs to find out what causes the Raster thread to slow down. Specifying specific types of work can be taxing for a GPU. This can be caused by multiple calls to saveLayer() : interacting with multiple transparent objects, clipping, shading, and so on.

For more information, see 👉Identifying Problems in the GPU Graph.

Jank

Jank frames are represented by little red bars. If a frame is completed in more than ~16 ms, it is Jank’s frame. To achieve 60 FPS, each frame must be within ~16 ms. UI Jank or dropping frames will not achieve this goal.

For more information, see 👉Identifying Problems in the GPU Graph.

Timeline event table

The timeline event table shows all captured events. The framework sends events at build, draw, and HTTP traffic. These events are displayed on Timeline, and developers can also send their own events via the DART: Developer Timeline and TimelineTask APIs.

Frame tables support zooming and panning:

  • Zoom, mouse wheel or trackpad zoom

  • Move horizontally, click and drag the table

  • Move vertically, click drag or Alt plus Scroll

  • The WASD keyboard can also control zooming and movement

Developers can click on events to see more CPU information

CPU analyzer

Click the Record button to start recording CPU analysis, and click again to stop analysis. The CPU data is displayed in the analysis window from the VM.

The Profile size

The default CPU sample collection rate for a VM is 1 sample / 250 μs. Profile Granularity: Medium is selected by default in the analysis window. This rate also supports modifications, which can be seen at the top of the page. The lithologic ratios are low-1/1000 μs, medium-1/250 μs, and high-1/50 μs. It is important to know the purpose of each scenario.

Higher granularity means higher sample collection rates and, therefore, more samples. Because the high sample collection rate will make the VM frequently collect terminal data, it may also affect the performance of APP, which may also lead to the overflow of VM sample buffer. The VM has already made the sample space limit. In the case of high sample collection rates, the space will fill up quickly and overflow quickly. This means that the original record may be lost.

Low granularity means lower sample collection rate and therefore fewer samples. Therefore, the impact on APP performance is relatively small. The buffer situation is reversed.

The frame table

This TAB shows the record of the CPU sample. Is a top-down call stack tracing, from the top to the bottom. The width of the stack frame represents the CPU time spent. The wider the stack frame, the more attention we need to pay and the more optimization we need.

Call tree

The call tree shows the call trace of a method, and the table is top-down, showing how the method can expand to show its callers.

  • Total time

    The duration of this method execution and submethods

  • Self time

    Duration of executing this method

  • Method

    The name of the method being called

  • Source

    Method call point source file

Bottom up

The Bottom Up window shows method call tracing, but only a summary of CPU analysis. This means that each method is the last method on the call stack, from which you can see the call chain. Method can be expanded to show the caller

  • Total time

    The duration of this method execution and submethods

  • Self time

    The execution duration of this method

  • Method

    The name of the method being called

  • Source

    Method call point source file

    Import and export

    DevTools allows you to import and export snapshot files. Click the Export button to download the current performance data. If you import it, you can just drag it. DevTools only supports importing files exported from DevTools