目录

Performance Detection

Time-Consuming Launch Event Detection

Overview

Time-consuming launch events are used to measure the time consumed in the application launch process that can be perceived by the system and users. The measurement can be implemented in various scenarios, including launch from the home screen, status bar, and recent task list. You can subscribe to this event to obtain the time consumed in key phases of the launch process.

[h2]Implementation Principle

The start time of the startup event statistics is the time when the user taps the screen. The default end time is the time when the startup animation is complete. The user can call the reportDrawCompleted API to transfer the customized end time based on the site requirements.

icon_input_time: time when the user taps the screen

animation_finish_time: launch duration defined by the system from when the finger leaves the screen to when the launch animation ends. This duration cannot be customized.

extend_time: startup duration customized by the developer. The duration is the duration from the time when the finger leaves the screen to the time when the developer invokes the reportDrawnCompleted interface. You can call the reportDrawnCompleted API at a proper time as required. If the API is not called or is not called within 5 seconds after the finger leaves the screen, the value of this indicator is 0.

[h2]Constraints

  1. The launch event indicates that the application is started by users, excluding the automatic process restart.

  2. The launch duration is a behavior event, which is reported immediately after being triggered and is not restricted by the threshold.

[h2]How to Obtain Events

You can subscribe to HiAppEvent to obtain the startup time consumption event and related information. For details, see HiAppEvent Introduction. Start the time-consuming event subscription.

Scrolling Event Detection

Overview

Scrolling frame loss events are used to detect frame freezes during list scrolling. If this event is subscribed, it is reported when frame freezes last for more than 50 ms during list scrolling.

[h2]Implementation Principle

  1. Calculation Method

    Scrolling frame loss events are reported when frame freezes occur in the application main thread or the RenderService process during list scrolling.

    The scrolling process starts when the scrolling gesture is recognized and ends when the page stops scrolling. The frame freeze duration is calculated separately from the application main thread and RenderService.

  2. Report the threshold.

    If the duration of a single frame exceeds 50 ms, a scrolling frame loss event occurs. Specifically, this event is reported when the value of max_render_frametime or max_app_frametime exceeds 50 ms.

[h2]Constraints

If the duration of a single frame does not exceed 50 ms, this event is not reported.

Logging Mechanism

Scrolling frame loss events trigger the call stack collection of the main thread.

  1. Startup time

    The sampling stack functionality for scrolling frame loss events is enabled only during scrolling.

  2. Stacking time

    The stack sampling is triggered when the freeze duration of the application main thread reaches the reporting threshold during scrolling.

Log Specifications

  1. Log aging:

    In most cases, the size of a stack file is 7 KB to 10 KB. The watchdog directory in the app sandbox can store a maximum of 10 MB files. If the total file size exceeds 10 MB, the user needs to manually delete files. The path to watchdog is /data/storage/el2/log/watchdog/.

    If you do not manually delete the files, the system will delete them.

  2. You can obtain the log path

    You can obtain the log path from external_logs.

  3. Format of the sampling stack

    Currently, stack capturing supports only the ARM64 architecture. The stack capture result contains both native frames and JS frames parsed. To avoid excessive consumption of system resources, a process can be collected only once a day.

An example of the stack capture result is as follows:

This sampling stack contains the call information of the application main thread when the sliding occurs for more than 50 ms. Generally, the sliding stuttering process is short. Therefore, the call stack is collected when the problem occurs. The clustering can be performed based on the sampling stack data reported by the stuttering in the same scenario to determine the specific root cause of the stuttering in the scenario. For details about how to parse the sampling stack, see Log Specifications of the Timeout Call Stack of the Main Thread.

[h2]How to Obtain Logs

HiAppEvent provides a fault subscription API. For details, see HiAppEvent Introduction. Subscribe to the scrolling frame loss event.