Flutter Analysis and Practice: Design of the Performance Stability Monitoring Solution

Flutter pages of Xianyu have served hundreds of millions of users, and it is essential to ensure the user experience of Flutter pages. Improving the Flutter performance and stability monitoring system helps detect online performance problems as early as possible and improve user experience. How is the performance of Flutter? Is it as smooth as it claims? Can the native performance metrics be used to detect Flutter pages? We will share the Flutter performance stability monitoring solution summarized from the practices of Xianyu.

4.2.1 Flutter Performance Stability Goals

Therefore, Xianyu has formulated the following three metrics as the performance stability criteria for online Flutter:

  • Page sliding smoothness
  • Page loading time (first meaningful paint + interaction time)
  • Exception rate

All of these metrics are designed to improve the Flutter user experience.

4.2.2 Page Sliding Smoothness

In the native-Flutter hybrid solution adopted by the Xianyu client, the high-availability solution of Alibaba Group is used for FPS monitoring of native pages. Can this solution be directly used for Flutter pages?

In the general FPS detection solution, the Android client uses Choreographer.FrameCallBack and the iOS client uses the callback registered by CADisplayLink. The principles are similar. Each time the VSync signal is sent, the CPU starts computing. When the corresponding callback is executed, the screen starts to refresh. The number of screen renderings in a fixed period of time is the FPS. This method can only detect CPU lagging but not GPU lagging. Both methods detect problems in the main thread. The Flutter screen rendering is performed in the UI TaskRunner, whereas the real rendering operation is performed in the GPU TaskRunner.

This means that the native FPS detection method is not suitable for Flutter.

Flutter officially provides Performance Overlay as a frame rate detection tool, as shown in Figure 4–6.

Figure 4–6

Figure 4–6 shows the frame rate statistics in Performance Overlay mode. Flutter calculates the frame rates by GPU TaskRunner and UI TaskRunner separately. The UI TaskRunner is used by the Flutter Engine to execute Dart root isolate code, and the GPU TaskRunner is used to execute GPU-related calls. According to the analysis of the Flutter Engine source code, the UI frame time indicates the total time spent in executing window.onBeginFrame, while the GPU frame time indicates the time spent in converting CPU commands into GPU commands and sending them to GPUs.

This method can be enabled only in Debug and Profile modes and cannot be used for online FPS statistics. However, you can call back handleBeginFrame() and handleDrawFrame() through the Flutter listening page to calculate the actual FPS.

4.2.2.1 Implementation Methods

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

Calculate the frame rate according to the time interval between handleBeginFrame and handleDrawFrame, as shown in Figure 4-7.

Figure 4–7

4.2.2.2 Results

4.2.3 Page Loading Time

4.2.3.1 Comparison Between Native and Weex Page Loading Algorithms

Figure 4–8

Figure 4–9 shows the Weex page loading process and definitions of statistics.

Figure 4–9

The page refresh stabilization time of Weex is the time required for the view rendering to complete and the view tree to become stable, as shown in Figure 4–10.

The add or remove operation of the view on the screen may be considered as an interaction point and data is recorded until the operation does not take place again.

Figure 4–10

The first meaningful paint and the interaction times have different meanings in Weex and Flutter. Flutter starts to calculate the duration from route redirection because this calculation method is closer to the user experience, and more information about the issues, such as the route redirection time, can be obtained.

4.2.3.2 Implementation of Flutter

Figure 4–11 shows the specific process.

Figure 4–11

4.2.3.3 Results

4.2.4 Exception Rate

4.2.4.1 Definition

Regarding the number of exceptions (with the whitelist filtered out), upon Flutter’s internal assert, try-catch, and some exception logic, FlutterError.onError is called to monitor the number of exceptions by redirecting FlutterError.onError to corresponding methods, and report the exception information.

The Flutter PV is implemented:

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);
});
}

FlutterError.onError only captures the errors and exceptions at the Flutter framework layer. Officially, we recommend that you customize this method based on your requirements for capturing and reporting exceptions. In practice, many exceptions that have no impact on user experience are frequently triggered. You can add these exceptions to the whitelist to avoid reporting.

4.2.4.2 Results

Here, we have collected the Flutter page sliding smoothness, page loading time, and exception rate, which provide specific criteria for Flutter performance measurement, as well as a basis for user experience improvement and performance problem locating. Currently, the product details page and the main publishing page of the Xianyu client have been fully based on Flutter. You are free to experience the performance differences between the two pages and other pages.

Original Source:

Follow me to keep abreast with the latest technology news, industry insights, and developer trends.