Get closer to science and explore the truth of the Ali Idle Fish Team’s data-driven Flutter experience



The flutter page of idle fish client has served hundreds of millions of users. At this time, the user experience of flutter page is particularly important. Perfecting the flutter stability monitoring system can detect online performance problems as early as possible, and can also be used as a measure of user experience improvement. So what’s the performance of Flutter? Is it as slippery as the official propaganda? Can Native’s performance metrics be used to detect Flutter pages? Here we share with you the performance stability monitoring scheme of Flutter which we summarized in practice.


Excessive frame dropout visually results in Karton phenomenon, which is reflected in the user’s poor sliding operation; page loading takes too long and easily interrupts the operation process; Flutter exceptions can lead to logic bugs or even white screen after abnormal code occurs. These problems can easily test the patience of users and arouse users’disgust.

So we set the following three indicators as online Flutter performance standards:

  1. Page Sliding Fluency
  2. Page loading time (first screen time + interactive time)
  3. Exception rate

The ultimate goal is to enable these data metrics to drive Flutter user experience upgrades.

Page Sliding Fluency

Let’s first get a general idea of the screen rendering process: CPU first stores the UI object into the displaylist list list, GPU executes the drawing instructions to execute the displaylist, extracts the corresponding meta-information, rasterizes the rendering, and displays it on the screen. This cycle realizes the screen refresh.

The mixed technology of Native and Flutter is adopted in idle fish client, and the group high availability scheme is adopted in FPS monitoring of Native page. Can Flutter page be directly monitored by this scheme?

The common FPS detection scheme is Choreographer. FrameCallBack on Android side, and CADisplayLink registered callbacks on IOS. The principle is similar. The Vsync signal is sent out every time and the corresponding callback is executed when the CPU starts to calculate, which means that the screen starts to refresh once and calculates the fixed-time screen. The number of curtain rendering is used to get fps. This method can only detect CPU cartons, which can not be monitored for GPU cartons. Because these two methods are used to detect and process the main thread, and the screen drawing of flutter is done in UI Task Runner. The real rendering operation is in GPU Task Runner. For the detailed flutter thread problem, you can refer to the article before Idle Fish: Understanding the thread mode of flutter engine in depth.

Here we come to the conclusion that:Native’s FPS detection method is not applicable to Flutter.

Flutter Official provides us with Performance Overlay as a frame rate detection tool, can we use it directly?

The figure above shows the frame rate statistics in Performance Overlay mode. As you can see, Flutter computes GPU and UI Task Runner separately. UI Task Runner is used by Flutter Engine to execute Dart root isolate code, and GPU Task Runner is used to execute device GPU related calls. By analyzing the source code of flutter engine, UI frame time is the total time spent executing window. onBeginFrame. GPU frame time is the time it takes to process CPU commands into GPU commands and send them to GPU.

This method can only be opened in debug and profile mode, and can not be used as online version of FPS statistics. But we can get inspiration in this way by listening to the Flutter page refresh callback methods handleBeginFrame (), handleDrawFrame () to calculate the actual FPS.

Specific ways of realization:

Register Widgets Flutter Binding listener page refresh callback handleBeginFrame (), handleDrawFrame ()

handleBeginFrame: Called by the engine to prepare the framework to produce a new frame.
handleDrawFrame: Called by the engine to produce a new frame.

The frame rate is calculated by calculating the time interval between handleBeginFrame and handleDrawFrame. The main flow chart is as follows:


At this point, we complete the statistics of page frame rate in Flutter. This method counts the CPU operation time in UI Task Runner. GPU operation is implemented in Flutter engine. To modify the engine to monitor the complete rendering time, most of our scenarios are not complicated to GPU carton. The problem is mainly focused on CPU. So most of the problems can be reflected. From the online data, the fluency of Flutter in release mode is quite good. The average of the main pages of IOS is basically maintained above 50 fps, while Android is slightly lower than ios. It should be noted that the average FPS of frame rate will have a dilution effect in the process of repeated sliding, leading to some Katon problems not exposed, so in addition to the average fps, we need to synthesize the data of frame dropping range, Katon seconds, sliding time to reflect the page fluency.

Page loading time

Highly available schemes within the group count the loading time of Native pages by checking the screen rendering degree when the container is laid out by opening the timer after the initialization of the container, calculating the screen coverage rate of the visible components, which is above 60% at the level of satisfying conditions and above 80% at the vertical level, and then checking the heartbeat of the main thread to determine whether or not it meets the page filling degree. Loading completed

Let’s look at the weex page loading process and the definition of statistical data.

Weex’s definition of page refresh stability: the time when view rendering is complete on screen and the view tree is stable

Specific implementation: When the view add/rm operation occurs on the screen, it is considered as an interactive point to record data. Until it doesn’t happen again.

Conceptually, the first screen length and interactive length of Flutter and weex are not exactly the same. The reason why Flutter chose to start computing time from routing jump is that this computing method is closer to user experience and can get more information about problems, such as the length of routing jump.

Flutter’s interactive endpoint algorithm is consistent with that of native. It can be seen that the tasks can interact when the components satisfy the padding level and complete the heartbeat check. In addition, for some empty pages, the component area is too small to reach the conditions of horizontal > 60%, vertical > 80%, so the last frame refresh before interaction is used. The interval is the end point.

The specific flow chart is as follows:


Due to JIT compilation in debug mode, the loading time of debug mode is longer than weex mode, but the AOT compilation time in release mode is much shorter, and the loading time of the whole page is still better than weex mode.

Exception rate

Flutter exceptions / errors cause the logic behind the code to not go to the page or cause a logical bug, so flutter exceptions need to be one of the criteria for stability.


Flutter Exception Rate = Number of exceptions / Flutter page PV

Molecule: Number of exceptions (whitelist filtered)

Flutter internal assert, try-catch, and some exception logic will call FlutterError. onError uniformly.

Monitor exceptions by redirecting FlutterError. onError to your method and report exceptions

Denominator: flutter page PV

The concrete realization is as follows:

Future<Null> main() async {
  FlutterError.onError = (FlutterErrorDetails details) async {
    Zone.current.handleUncaughtError(details.exception, details.stack);

  runZoned<Future<Null>>(() async {
    runApp(new HomeApp());
  }, onError: (error, stackTrace) async {
    await _reportError(error, stackTrace);

Among them, FlutterError. onError only captures errors and exceptions in the Flutter framework layer. Officials recommend that this method be customized to their own exceptions capture reporting requirements. In practice, we encounter a lot of exceptions that will not have any impact on the user experience will be triggered frequently. Such exceptions without improvement can be added to the whitelist filter report.


With the monitoring of online exceptions, hidden troubles can be detected early, problem stack information can be obtained, bugs can be easily located, and overall stability can be prompted.


So far, we have completed the statistics of flutter page sliding fluency, page loading time and Exception rate. We have a specific digital standard for Flutter performance, which provides a basis for future user experience improvement and performance problem investigation. At present, the product details page and the home release page of idle fish client have been fully fluttered. Interested students can experience the performance differences between the two pages and other pages. Finally, you are welcome to provide feedback and suggestions.

Author of this paper: Leisure Fish Technology – Coriander

Read the original text

This article is the original content of Yunqi Community, which can not be reproduced without permission.