1# Application Freeze (appfreeze) Log Analysis 2 3## Introduction 4 5Application freeze (appfreeze) means that an application does not respond to user operations (for example, clicking) within a given period of time. OpenHarmony provides a mechanism for detecting appfreeze faults and generates appfreeze logs for fault analysis. 6 7> **NOTE** 8> 9> This guide applies only to applications in the stage model. 10> Before using this guide, you must have basic knowledge about the JS applications, C++ program stacks, and application-related subsystems. 11 12## How to Obtain 13 14appfreeze log is a type of fault logs managed together with the native process crash, JS application crash, and system process crash logs . You can obtain the log in any of the following ways. 15 16### Collecting Logs by Using Shell 17 18appfreeze logs start with **appfreeze-** in **/data/log/faultlog/faultlogger/**. 19 20The log files are named in the format of **appfreeze-application package name-application UID-time (seconds level)**. 21 22 23 24### Collecting Logs by Using DevEco Studio 25 26DevEco Studio collects device fault logs and saves them to FaultLog. 27 28The logs are displayed by the bundle name, fault, and time. 29 30 31 32 33### Collecting Logs by Using faultLogger APIs 34 35The FaultLogger module provides APIs to query various fault information. For details, see [@ohos.faultLogger](../reference/apis/js-apis-faultLogger.md). 36 37 38## appfreeze Detection 39 40Currently, appfreeze detection supports the fault types listed in the following table. 41 42| Fault Type| Description| 43| -------- | -------- | 44| THREAD_BLOCK_6S | The application main thread times out due to a suspension.| 45| APPLICATION_BLOCK_INPUT | The user input response times out.| 46| LIFECYCLE_TIMEOUT | Ability lifecycle switching times out.| 47| APP_LIFECYCLE_TIMEOUT | Application lifecycle switching times out.| 48 49### Application Main Thread Timeout 50 51If this fault occurs, the main thread of the current application is suspended or too many tasks are executed, affecting task execution smoothness and experience. 52 53Such a fault can be detected as follows: The watchdog thread of the application periodically inserts an activation detection subthread to the main thread and inserts a timeout reporting subthread to its own thread. If activation detection is not executed within 3 seconds, the THREAD_BLOCK_3S event is reported; if activation detection is not executed within 6 seconds, the THREAD_BLOCK_6S event is reported. The two events together form an appfreeze log. The following figure shows the working principle. 54 55 56 57### User Input Response Timeout 58 59This fault affects user experience. If this fault occurs, the system does not respond to a click event within 10 seconds. 60 61Such a fault can be detected as follows: When a user clicks a certain button of the application, the input system sends a click event to the application. If the input system does not receive a response from the application within 10 seconds, a fault event is reported. The following figure shows the working principle. 62 63 64 65### Lifecycle Switching Timeout 66 67This fault refers to an ability lifecycle switching timeout (LIFECYCLE\_TIMEOUT) or an application lifecycle switching timeout (APP\_LIFECYCLE\_TIMEOUT). 68 69The fault occurs during lifecycle switching and affects the switchover between abilities in the current application or the switchover between applications. 70 71Such a fault can be detected as follows: Upon the start of a lifecycle switchover process, the main thread inserts a timeout task to the watchdog thread, and then removes the timeout task when the lifecycle switchover is complete. If the timeout duration expires, a fault event is reported. 72 73 74 75The timeout duration varies according to the lifecycle. 76 77| Lifecycle| Timeout Duration| 78| -------- | -------- | 79| Load | 10s | 80| Terminate | 10s | 81| Connect | 3s | 82| Disconnect | 0.5s | 83| Foreground | 5s | 84| Background | 3s | 85 86## appfreeze Log Analysis 87 88To identify the cause of appfreeze, analyze the appfreeze logs together with HiLog logs. 89 90The following example uses main tread suspension as an example to illustrate how to conduct log analysis. You can treat other types of faults in a similar way. 91 92appfreeze logs are divided into several parts, including header information, and general and specific information in the body. 93 94### Log Header Information 95 96| Field| Description| 97| -------- | -------- | 98| Reason | Reason why the application does not respond. For details, see [appfreeze Detection](#appfreeze-detection).| 99| PID | PID of the failed process, which can be used to search for related process information in the log.| 100| PACKAGE_NAME | Application package name.| 101 102 103 104### General Information in the Log Body 105 106General information is present in all logs. It contains the fields listed in the following table. You can search for these fields to locate the related information in the log. 107 108| Field| Description| 109| -------- | -------- | 110| EVENTNAME | One or more fault events that constitute the cause of main thread suspension.| 111| TIMESTAMP | Time when the fault event reported. You can narrow down the time range for viewing HiLog logs based on the timeout duration described in [appfreeze Detection](#appfreeze-detection).| 112| PID | PID of the failed process, which can be used with the timestamp and timeout duration to search for related process information in the log.| 113| PACKAGE_NAME | Application package name.| 114| MSG | Dump information or description of the fault.| 115| OpenStacktraceCatcher | Stack trace information of the process.| 116| BinderCatcher | Information about IPC calls between a process and other system processes, such as the call waiting time.| 117| PeerBinder Stacktrace | Information about stack trace of the peer process.| 118| cpuusage | CPU usage of the device.| 119| memory | Memory usage of the process.| 120 121The following is an example process stack of OpenStacktraceCatcher. 122 123In this example, when the stack surface window sends events through IPC, the process is stuck in the IPC communication phase. 124 125 126 127Example BinderCatcher information: 128 129In the following example, process 1561 sends an IPC request to process 685 but does not receive any response within 10 seconds. 130 131 132 133Example PeerBinder Stacktrace information: 134 135The following example shows the stack information of process 685, which is suspended at the peer end. 136 137 138 139Example CPU usage information: 140 141The following example shows the CPU usage information of the device. 142 143 144 145Example memory usage information: 146 147The following example shows the memory usage information of the process. 148 149 150 151### Specific Information in the Log Body (Application Main Thread Timeout) 152 153According to [Application Main Thread Timeout] (#application-main-thread-timeout), the log in which **Reason** is **THREAD\_BLOCK\_6S** consists of two parts: THREAD\_BLOCK\_3S and THREAD\_BLOCK\_6S. By comparing the two parts, you can determine whether the appfreeze is due to a suspension or an excess number of tasks. 154 155THREAD\_BLOCK\_3S is followed by THREAD\_BLOCK\_6S in the log. You can use the **EVENTNAME** field to search for the locations of the two events in the log. 156 157Both events contain the **MSG** field, which stores information about the processing queue of the main thread when the suspension occurs. Hence, you can view the status of the event processing queue of the main thread at the two time points. 158 159The example log shows that the event carrying **05:06:18.145** in the low-priority queue is being processed, and it is present in both the THREAD_BLOCK_3S and THREAD_BLOCK_6S. This indicates that the main thread suspension is not caused by an excess number of tasks. 160 161Because THREAD_BLOCK_6S indicates a main thread suspension, you only need to analyze the stack information of the main thread (the ID of the main thread is the same as the process ID). In the example log, the main thread stack is run in the JS through ArkUI and therefore it can be concluded that the suspension occurs in the JS. Because stack is present in both THREAD_BLOCK_3S and THREAD_BLOCK_6S in the same position, the JS suspension is not caused by an excess number of tasks. 162THREAD_BLOCK_3S: 163 164 165 166THREAD_BLOCK_6S: 167 168 169 170Then, you can check for the code segment being executed on the application side based on the HiLog log. 171 172Generally, you can view the [general information in the log body](#general-information-in-the-log-body) to check for the cause of the suspension, for example, IPC suspension, high CPU usage, memory leakage, or high memory usage. 173 174### Specific Information in the Log Body (User Input Response Timeout) 175 176If **Reason** is **APPLICATION\_BLOCK\_INPUT**, no response is received within 10 seconds after a user click. 177 178You can find the event description in **MSG**. 179 180For details, see [General Information in the Log Body](#general-information-in-the-log-body). Note that there is a high probability that the main thread is suspended in the case of no response to the user input. You can compare the stack and BinderCatcher information in two log records for further analysis. If there is no log record indicating a main thread suspension, a large number of other events may exist before the input event. This may not cause a main thread suspension but can probably result in no response to user input. 181 182### Specific Information in the Log Body (Lifecycle Switching Timeout) 183 184For a lifecycle switching timeout, **Reason** can be **LIFECYCLE\_TIMEOUT** or **APP\_LIFECYCLE\_TIMEOUT**. 185 186**LIFECYCLE\_TIMEOUT** indicates a lifecycle switching timeout at the ability level, and **APP\_LIFECYCLE\_TIMEOUT** indicates a lifecycle switching timeout at the application level. 187 188MSG indicates the lifecycle that encounters a timeout. 189 190In this example, **LIFECYCLE\_TIMEOUT** indicates that the timeout occurs during switching of the ability to the background, and **APP\_LIFECYCLE\_TIMEOUT** indicates that the timeout occurs in the application termination phase. You can locate related HiLog logs according to the timeout duration described in [Lifecycle Switching Timeout] (#lifecycle-switching-timeout). 191 192LIFECYCLE_TIMEOUT: 193 194 195 196APP_LIFECYCLE_TIMEOUT: 197 198 199 200For details about other log information, see [General Information in the Log Body](#general-information-in-the-log-body). Note that there is a high probability that the main thread is suspended during lifecycle switching. You can compare the stack and BinderCatcher information in two log records for further analysis. 201
