1# Analyzing App Freeze 2 3App freeze (appfreeze) means that an application does not respond to a click event within a certain period of time. OpenHarmony provides a mechanism for detecting appfreeze and generates appfreeze logs for fault analysis. 4 5> **NOTE** 6> 7> This guide applies only to applications in the stage model. Before using this guide, you must have basic knowledge about the JS applications, C++ program stacks, and application-related subsystems. 8 9## AppFreeze Detection 10 11Currently, appfreeze detection supports the fault types listed in the following table. 12 13| Fault| Description| 14| -------- | -------- | 15| THREAD_BLOCK_6S | The application main thread times out.| 16| APP_INPUT_BLOCK | The user input response times out.| 17| LIFECYCLE_TIMEOUT | Ability lifecycle switching times out.| 18 19### Application Main Thread Timeout 20 21This fault indicates that the main thread of this application is suspended or too many tasks are executed, which affects task execution smoothness and experience. 22 23Such a fault can be detected as follows: The watchdog thread of the application periodically inserts an activation detection to the main thread and inserts a timeout reporting mechanism to its own thread. If the activation detection is not executed within 3 seconds, the **THREAD_BLOCK_3S** event is reported. If the activation detection is not executed within 6 seconds, the **THREAD_BLOCK_6S** event is reported. The two events constitute an AppFreeze log. 24 25The following figure shows the working principle. 26 27 28 29### User Input Response Timeout 30 31This fault occurs when the system does not respond to a click event within 5 seconds. 32 33Such a fault can be detected as follows: When a user clicks a 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 5 seconds, a fault event is reported. 34 35The following figure shows the working principle. 36 37 38 39### Lifecycle Switching Timeout 40 41Lifecycle switching timeout refers to an [UIAbility Lifecycle](../application-models/uiability-lifecycle.md#uiability-lifecycle) switching timeout or a [PageAbility Lifecycle](../application-models/pageability-lifecycle.md#pageability-lifecycle) switching timeout. 42 43The fault occurs during lifecycle switching and affects Ability switching and PageAbility switching of the application. 44 45Such a fault can be detected as follows: Upon the start of a lifecycle switching process, the main thread inserts a timeout task to the watchdog thread, and then removes the timeout task when the lifecycle switching is complete. If the timeout task is not removed within a specific time frame, a fault event is reported. 46 47The lifecycle switching timeout events consist of **LIFECYCLE_HALF_TIMEOUT** and **LIFECYCLE_TIMEOUT**. **LIFECYCLE_HALF_TIMEOUT** is used as the warning event of **LIFECYCLE_TIMEOUT** to capture the Binder information. 48 49 50 51The timeout duration varies according to the lifecycle. 52 53| Lifecycle| Timeout Duration| 54| -------- | -------- | 55| Load | 10s | 56| Terminate | 10s | 57| Connect | 3s | 58| Disconnect | 0.5s | 59| Foreground | 5s | 60| Background | 3s | 61 62## appfreeze Log Analysis 63 64To identify the cause of appfreeze, analyze the appfreeze logs together with HiLog logs. 65 66The following example shows an appfreeze log analysis. You can analyze the fault based on actual situation. 67 68AppFreeze logs consist of header information, and general and specific information in the body. 69 70### Header Information 71 72| Field| Description| 73| -------- | -------- | 74| Reason | Reason why the application does not respond. For details, see [AppFreeze Detection](#appfreeze-detection).| 75| PID | PID of the failed process, which can be used to search for related process information in the HiLog logs.| 76| PACKAGE_NAME | Application process package name.| 77 78``` 79============================================================ 80Device info:OpenHarmony 3.2 81Build info:OpenHarmony 4.0.5.3 82Module name:com.xxx.xxx 83Version:1.0.0 84Pid:1561 85Uid:20010039 86Reason:LIFECYCLE_TIMEOUT 87sysfreeze:LIFECYCLE_TIMEOUT LIFECYCLE_TIMEOUT at 20230317170653 88>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 89DOMAIN:AAFWK 90STRINGID:LIFECYCLE_TIMEOUT 91TIMESTAMP:2023/XX/XX/XX-XX:XX:XX:XX 92PID:1561 93UID:20010039 94PACKAGE_NAME:com.xxx.xxx 95PROCESS_NAME:com.xxx.xxx 96MSG:ability:EntryAbility background timeout 97``` 98 99### General Information in the Log Body 100 101General information is present in all the aforementioned logs. It contains the fields listed in the following table. You can search for these fields to locate the related information in the log. 102 103| Field| Description| 104| -------- | -------- | 105| EVENTNAME | One or more fault events that constitute the cause of main thread freeze.| 106| TIMESTAMP | Time when a fault event is reported. You can narrow down the time range to view HiLog logs based on the timeout duration described in [AppFreeze Detection](#appfreeze-detection).| 107| PID | PID of the failed process, which can be used with the timestamp and timeout duration to search for related process information in the HiLog logs.| 108| PACKAGE_NAME | Application process package name.| 109| MSG | Dump information or description of the fault.| 110| BinderCatcher | Information about IPC calls between a process and other system processes, such as the call waiting time.| 111| PeerBinder Stacktrace | Stack trace information of the peer process.| 112| cpuusage | CPU usage of the device.| 113| memory | Memory usage of the process.| 114 115> **NOTE** 116> 117> When the device is heavily loaded and the call stack is obtained in low-overhead mode, the function name and **build-id** information may be lost. 118 119The **MSG** field includes the cause of the freeze event and task information in the main thread queue of the application. 120 121The task information in the main thread queue includes: 122 123- The running task and its start time. If the task start time is much earlier than the log report time, the running task causes the freeze event. 124 125- Historical task time. If a new task cannot respond in time, you can check whether there are too many historical tasks based on historical task time. 126 127- Tasks that are not executed in the stack. 128 129**Example of the calling process stack:** 130 131Locate the application stack information by searching for the **PID**. In the following stack, the window stays in the IPC communication phase when it sends events to the system through the IPC. 132 133``` 134OpenStacktraceCatcher -pid==1561 packageName is com.example.myapplication 135Result: 0 ( no error ) 136Timestamp:2017-08-0817:06:53.000 137Pid:1561 138Uid:20010039 139Process name:com.example.myapplication 140Tid:1561,Name:i.myapplication 141#00 pc 0017888c /system/lib/libark_jsruntime.so 142#01 pc 00025779 /system/lib/platformsdk/libipc_core.z.so(OHOS:BinderConnector:WriteBinder(unsigned Long,void*)+56) 143#02 pc 000265a5 /system/lib/platformsdk/libipc_core.z.so(OHOS:BinderInvoker:TransactWithDriver(bool)+216) 144#03 pc 0002666f /system/lib/platformsdk/libipc_core.z.so(OHOS:BinderInvoker:StartWorkLoop()+18) 145#04 pc 000270a9 /system/lib/platformsdk/libipc_core.z.so(OHOS:BinderInvoker:JoinThread(bool)+32) 146#05 pc 00023783 /system/lib/platformsdk/libipc_core.z.so(OHOS:IPCWorkThread:ThreadHandler(void*)+290) 147#06 pc 00e1c6f7 /system/lib/libace.z.so 148#07 pc 0091bbdd /system/lib/libace.z.so 149#08 pc 0092fd9d /system/lib/libace.z.so 150#09 pc 0092fa5f /system/lib/libace.z.so 151#10 pc 0092cd6b /system/lib/libace.z.so 152#11 pc 009326a9 /system/lib/libace.z.so 153#12 pc 0093054b /system/lib/libace.z.so 154#13 pc 009324f3 /system/lib/libace.z.so 155#14 pc 003989e1 /system/lib/libace.z.so 156#15 pc 0045dd4b /system/lib/libace.z.so 157#16 pc 00d24fef /system/lib/libace.z.so 158#17 pc 0041e6e9 /system/lib/libace.z.so 159#18 pc 0000b4d9 /system/lib/platformsdk/libeventhandler.z.so(OHOS:AppExecFwk:EventHandler:DistributeEvent(std::__h:unique_ptr<0 #19 pc 00012829 /system/lib/platformsdk/libeventhandler.z.so)) 160#20 pc 00011841 /system/lib/platformsdk/libeventhandler.z.so(OHOS:AppExecFwk:EventRunner:Run()+64) 161#21 pc 00054a8b /system/lib/libappkit_native.z.so(OHOS:AppExecFwk:MainThread:Start()+278) 162#22 pc 00011503 /system/bin/appspawn 163#23 pc 0001141f /system/bin/appspawn 164#24 pc 0000ee97 /system/bin/appspawn 165``` 166 167**Example of BinderCatcher information**: 168 169Search for the **PID** to find out the process with which this process communicates and the waiting duration of the synchronous communication. 170 171In the following example, process **1561** sends an IPC request to process **685** but does not receive any response within 10 seconds. 172 173``` 174PeerBinderCatcher -pid==1561 Layer_==0 175 176 177BinderCatcher -- 178 1561:1561 to 685:0 code 0 Wait:10.366245919 s 179 1329:1376 to 487:794 code 0 Wait:0.12070041 s 180 181pid context request started max ready free_async_space 1821561 binder 0 3 16 4 520192 183544 binder 0 4 16 5 520192 1841104 binder 0 1 16 2 520192 1851397 binder 0 1 16 3 520192 186... 187``` 188 189**Example of PeerBinder Stacktrace information**: 190 191The following example shows the stack information of process **685**, which is suspended at the peer end. 192 193``` 194PeerBinder Stacktrace -- 195 196PeerBinderCatcher start catcher stacktrace for pid 685 197Result: 0 ( no error ) 198Timestamp:2017-08-0817:06:55.000 199Pid:685 200Uid:1000 201Process name:wifi_manager_service 202Tid:658,Name:wifi_manager_service 203#00 pc 000669f0 /system/lib/ld-musl-arm.so.1 204#01 pc 000c60cc /system/lib/ld-musl-arm.so.1 205#02 pc 000c5040 /system/lib/ld-musl-arm.so.1 206#03 pc 000c6818 /system/lib/ld-musl-arm.so.1(__pthread_cond_timedwait_time64+596) 207#04 pc 000bd058 /system/lib/libc++.so 208#05 pc 0008592c /system/lib/ld-musl-arm.so.1(ioctl+72) 209#06 pc 00025779 /system/lib/platformsdk/libipc_core.z.so(OHOS:BinderConnector:WriteBinder(unsigned long,void*)+56) 210#07 pc 000265a5 /system/lib/platformsdk/libipc_core.z.so(OHOS:BinderInvoker:TransactWithDriver(bool)+216) 211#08 pc 0002666f /system/lib/platformsdk/libipc_core.z.so(OHOS:BinderInvoker:StartWorkLoop()+18) 212#09 pc 000270a9 /system/lib/platformsdk/libipc_core.z.so(OHOS:BinderInvoker:JoinThread(bool)+32) 213#10 pc 00023783 /system/lib/platformsdk/libipc_core.z.so(OHOS:IPCWorkThread:ThreadHandler(void*)+290) 214#11 pc 0007b4d9 /system/lib/platformsdk/libeventhandler.z.so 215#12 pc 00072829 /system/lib/platformsdk/libeventhandler.z.so 216#13 pc 00071841 /system/lib/platformsdk/libeventhandler.z.so(OHOS:AppExecFwk:EventRunner:Run()+64) 217#14 pc 00094a8b /system/lib/libappkit_native.z.so(OHOS:AppExecFwk:MainThread:Start()+278) 218 219Tid:1563,Name:IPC_0_1563 220#00 pc 0009392c /system/lib/ld-musl-arm.so.1(ioctl+72) 221#01 pc 00025779 /system/lib/platformsdk/libipc_core.z.so(OHOS:BinderConnector:WriteBinder(unsigned long,void*)+56) 222``` 223 224**Example of CPU usage information**: 225 226The following example shows the CPU usage information of the device. 227 228``` 229Load average: 2.87 / 1.45 / 0.58; the cpu load average in 1 min,5 min and 15 min 230CPU usage from 2023-03-10 17:06:53 to 2023-03-10 17:06:53 231Total: 29%; User Space: 28%; Kernel Space: 1%; iowait: 6%; irq: 0%; idle: 62% 232Details of Processes: 233 PID Total Usage User Space Kernel Space Page Fault Minor Page Fault Major Name 234 1561 23% 23% 0% 9985 26 i.myapplication 235 527 1% 1% 0% 3046 9 hidumper_servic 236 242 1% 1% 0% 69799 280 hiview 237``` 238 239**Example of memory usage information**: 240 241The following example shows the memory usage information of the process. 242 243``` 244-------------------------------------------[memory]---------------------------------------- 245 Pss Shared Shared Private Private Swap SwapPss Heap Heap 246 Total CLean Dirty CLean Dirty Total Total Size Alloc 247 (kB) (kB) (kB) (kB) (kB) (kB) (kB) (kB) (kB) 248------------------------------------------------------------------------------------------- 249guard 0 0 0 0 0 0 0 0 0 250native heap 185 0 180 0 160 0 0 0 0 251AnonPage other 17881 12 12376 88 15948 0 0 0 0 252stack 292 0 0 0 292 0 0 0 0 253.S0 5053 63408 4172 1812 2640 0 0 0 0 254.ttf 1133 3092 0 4 0 0 0 0 0 255dev 10 0 108 8 0 0 0 0 0 256FilePage other 121 556 8 0 4 0 0 0 0 257------------------------------------------------------------------------------------------ 258Total 34675 67068 16844 1912 19044 0 0 0 0 259``` 260 261### Specific Information in the Log Body (Application Main Thread Timeout) 262 263The value of **Reason** is **THREAD_BLOCK_6S**. According to [Application Main Thread Timeout](#application-main-thread-timeout), **THREAD_BLOCK** consists of **THREAD_BLOCK_3S** and **THREAD_BLOCK_6S**. By comparing the two parts, you can determine whether the appfreeze is due to a suspension or excessive tasks. 264 265**THREAD\_BLOCK\_3S** is followed by **THREAD\_BLOCK\_6S** in the log. You can search for **EVENTNAME** to locate the two events in the log. 266 267Both events contain the **MSG** field, which stores information about the processing queue of the main thread when the fault occurs. Hence, you can view the status of the event processing queue of the main thread at the two time points. 268 269The example log shows that the event that started at **05:06:18.145** in the low-priority queue is running, and it is displayed in both the **THREAD_BLOCK_3S** and **THREAD_BLOCK_6S** logs. This indicates that the main thread suspension is not caused by excessive tasks. 270 271Because **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. Both **3S** and **6S** are stacks in this position, indicating that the JS is suspended. However, the cause is not that there are too many tasks. 272 273THREAD_BLOCK_3S: 274 275``` 276start time:2017/08/08-17:06:24:380 277DOMAIN = AAFWK EVENTNAME THREAD_BLOCK_3S 278TIMESTAMP = 2017/08/08-17:06:24:363 279PID = 1561 280UID = 20010039 281TID = 1566 282PACKAGE_NAME com.example.myapplication 283PROCESS_NAME com.example.myapplication 284eventLog_action pb:1 eventLog_interval 10 285MSG = App main thread is not response!EventHandler dump begin curTime:2017-08-08 05:06:24.362 286 Event runner (Thread name =Thread ID 1561)is running 287 Current Running:start at 2017-08-08 05:06:18.145,Event send thread 1561,send time =2017-08-08 05:06:18.145,handle time =2017-08-08 05: 288 Immediate priority event queue information: 289 Total size of Immediate events 0 290 High priority event queue information: 291 No.1 Event send thread 1561,send time 2017-08-08 05:06:18.039,handle time 2017-08-08 05:06:21.539,task name [anr_handler.cpp(Send Total size of High events 1)] 292 Low priority event queue information: 293 No.1:Event{send thread=1566,send time=2017-08-0805:06:21.062,handle time=2017-08-0805:06:21.062,id=1} 294 Total size of Low events 1 295 Idle priority event queue information: 296 Total size of Idle events 0 297 Total event size :2 298 299 Timestamp: 2017-08-0817:06:24.4142447784 300 Pid: 1561 301 Uid: 20010039 302 Process name: com.example.myapplication 303 Tid:1561 Name:i.myapplication 304 at anonymous entry (D:/project/MyApplication_test/entry/build/default/intermediates/loader_out/default/ets/pages/Index_.js:0:1) 305 #00 pc 0017909c /system/lib/libark_jsruntime.so 306 #01 pc 00177ebb /system/lib/libark_jsruntime.so 307 #02 pc 0024b4bb /system/lib/libark_jsruntime.so 308 #03 pc 00fbed23 /system/lib/libace.z.so 309 #04 pc 00d8208f /system/lib/libace.z.so 310 ... 311``` 312 313THREAD_BLOCK_6S: 314``` 315start time: 2017/08/08-17:06:27:299 316DOMAIN = AAFWK 317EVENTNAME THREAD_BLOCK_6S 318TIMESTAMP = 2017/08/08-17:06:27:292 319PID = 1561 320UID = 20010039 321TID = 1566 322PACKAGE_NAME com.example.myapplication 323PROCESS NAME com.example.myapplication eventLog_action cmd:c,cmd:m,tr,k:SysRqFile 324eventLog_interval 10 325MSG = App main thread is not response!EventHandler dump begin curTime:2017-08-08 05:06:27.291 326 Event runner (Thread name =Thread ID =1561)is running 327 Current Running:start at 2017-08-08 05:06:18.144, Event {send thread 1561,send time =2017-08-08 05:06:18.145,handle time =2017-08-08 05: 328 Immediate priority event queue information: 329 Total size of Immediate events 0 330 High priority event queue information: 331 No.1 Event send thread 1561,send time 2017-08-08 05:06:18.039,handle time 2017-08-08 05:06:21.539,task name [arr_handler.cpp(Se Total size of High events 1 332 Low priority event queue information: 333 No.1:Event{send thread=1566,send time=2017-08-0805:06:21.062,handle time=2017-08-0805:06:21.062,id=1} 334 No.2 Event send thread 1566,send time 2017-08-08 05:06:24.369,handle time 2017-08-08 05:06:24.369,id =1 335 Total size of Low events 2 336 Idle priority event queue information: 337 Total size of Idle events 0 338 Total event size 3 339 340Timestamp:2017-08-0817:0k:27,4142447784 341Pid:1561 342Uid:20010039 343Process name:com.example.myapplication 344Tid:1561 Name:i.myapplication 345 at anonymous entry (D:/project/MyApplication_test/entry/build/default/intermediates/loader_out/default/ets/pages/Index_.js:0:1) 346 #00 pc 00178dcc /system/lib/libark_jsruntime.so 347 #01 pc 00177ebb /system/lib/libark_jsruntime.so 348 #02 pc 0024b4bb /system/lib/libark_jsruntime.so(panda:FunctionRef:Call(panda:ecmascript:EcmaVM const*,panda:Local<panda:JSValueRef>,par 349 #03 pc 00fbed23 /system/lib/libace.z.so 350 #04 pc 00d8208f /system/lib/libace.z.so 351 #05 pc 00d7af1b /system/lib/libace.z.so 352``` 353 354Check the code being executed on the application side based on the HiLog log. 355 356Generally, you can view the [General Information in the Log Body](#general-information-in-the-log-body) to determine the cause of an appfreeze event, including peer communication suspension, high CPU usage, memory leaks, or a large amount of memory. 357 358### Specific Information in the Log Body (User Input Response Timeout) 359 360The value of **Reason** is **APP_INPUT_BLOCK**, indicating that no response is received within 5 seconds after a click event. 361 362You can find the event description in **MSG**. 363 364For 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 logs for further analysis. If there is no main thread suspended, it may indicate that there is a large number of other events before the input event. This may not cause a main thread suspension but can probably result in no response to user input. 365 366### Specific Information in the Log Body (Lifecycle Switching Timeout) 367 368**LIFECYCLE_TIMEOUT** consists of two events, namely **LIFECYCLE_HALF_TIMEOUT** and **LIFECYCLE_TIMEOUT**. 369 370**MSG** indicates the lifecycle that encounters a timeout. 371 372In the following example, **LIFECYCLE_TIMEOUT** indicates that the process times out when **Ability** is switched to background. You can find HiLog information based on the timeout duration of [Lifecycle Switching Timeout](#lifecycle-switching-timeout). 373 374LIFECYCLE_TIMEOUT: 375 376``` 377DOMAIN:AAFWK 378STRINGID:LIFECYCLE 379TIMEOUT TIMESTAMP:2023/03/10-17:06:53:65 380PID:1561 381UID:20010039 382PACKAGE_NAME:com.example.myapplication 383PROCESS_NAME:com.example.myapplication 384MSG:ability:EntryAbility background timeout 385``` 386 387For 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 logs for further analysis. 388 389## Application Exit 390 391If any of the following faults occurs on an application, the application will be killed to ensure that the application can be recovered: 392 393| Fault| Description| 394| -------- | -------- | 395| THREAD_BLOCK_6S | The application main thread times out.| 396| APP_INPUT_BLOCK | The user input response times out.| 397| LIFECYCLE_TIMEOUT | Ability lifecycle switching times out.| 398 399## Fault Analysis 400 401To locate an appfreeze event, you need to obtain related logs such as fault logs, hilog logs, and trace logs. 402 403### Obtaining the Log 404 405The appfreeze log is managed together with the native process crash, JS application crash, and system process crash logs in the FaultLog module. You can obtain the log in any of the following ways. 406 407- Method 1: DevEco Studio 408 409 DevEco Studio collects device fault logs and saves them to **FaultLog**. For details, see <!--RP1-->[DevEco Studio User Guide-FaultLog](https://developer.huawei.com/consumer/cn/doc/harmonyos-guides-V5/ide-fault-log-V5)<!--RP1End-->. 410 411- Method 2: HiAppEvent APIs 412 413 hiAppEvent provides APIs to subscribe to various fault information. For details, see [Introduction to HiAppEvent](hiappevent-intro.md). 414 415<!--Del--> 416- Method 3: Shell 417 418 AppFreeze logs are stored in the device-specific **/data/log/faultlog/faultlogger/** directory. The log files are named in the format of **appfreeze-application bundle name-application UID-time (milliseconds).log**. 419 420  421<!--DelEnd--> 422 423### Confirming Basic Information 424 425#### Obtain basic information such as the process ID of the freeze application and whether the application is in the foreground. 426 427``` 428Generated by HiviewDFX@OpenHarmony 429============================================================ 430Device info:HUAWEI Mate 60 Pro 431Build info:ALN-AL00 x.x.x.xx(XXXXXXX) 432Fingerprint:ef8bd28f8b57b54656d743b546efa73764c77866a65934bd96f2678f886813b7 433Module name:com.xxx.xxx 434Version:1.2.2.202 435VersionCode:1002002202 436PreInstalled:Yes 437Foreground:No --> Indicates that the application is not in the foreground. 438Pid:15440 439Uid:20020029 440Reason:THREAD BLOCK 6S 441appfreeze: com.xxx.xxx THREAD_BLOCK 6S at 20240410164052 442DisplayPowerInfo:powerState: AWAKE 443>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 444``` 445 446#### Obtain the fault occurrence time 447 448Fault report time: 449 450``` 451>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 452DOMAIN:AAFWK 453STRINGID: THREAD BLOCK 6S 454TIMESTAMP: 2024/04/10-16:40:52:743 --> The timestamp when the fault is reported. 455PID:15440 456UID:20020029 457PACKAGE NAME:com.xxx.xxx 458PROCESS NAME:com.xxx.xxx 459**************************************** 460``` 461 462Detection durations for different faults in different scenarios: 463 464| THREAD_BLOCK_6S |APP_INPUT_BLOCK|LIFECYCLE_TIMEOUT| 465| -------- |--------|--------| 466|Foreground application: 6s<br> Background application: 3s * 5 + 6s = 21s| 5s | Load: 10s<br> Active: 5s<br> Inactive: 0.5s<br> Terminate: 10s<br> Connect: 3s<br> Disconnect: 0.5s<br> Restart: 5s<br> Foreground: 5s<br> Background: 3s| 467 468**NOTE** 469 4701. The detection duration of **THREAD_BLOCK_3S** is half that of **THREAD_BLOCK_6S**, while **LIFECYCLE_HALF_TIMEOUT** is half that of **LIFECYCLE_TIMEOUT**. **THREAD_BLOCK_3S** and **LIFECYCLE_HALF_TIMEOUT** are warnings and do not report logs independently. **THREAD_BLOCK_6S** and **LIFECYCLE_TIMEOUT** are errors and report logs with the corresponding warning. 471 4722. When **THREAD_BLOCK_3S** occurs in the foreground application, **THREAD_BLOCK_6S** will be triggered. 473 4743. In the background application, when **THREAD_BLOCK_3S** occurs for five consecutive times (the value of **backgroundReportCount_** is **5**), the **THREAD_BLOCK_6S** event is reported. Consequently, the detection durations of **THREAD_BLOCK_3S** and **THREAD_BLOCK_6S** are 18s and 21s respectively. 475 476The fault occurrence time can be obtained based on the detection duration and the fault reporting time. 477 478### Viewing **eventHandler** Information 479 480You can search for the keyword **mainHandler dump is** to view the **eventHandler dump** information in logs. 481 4821. **dump begin curTime** & **Current Running**. 483 484``` 485mainHandler dump is: 486 EventHandler dump begin curTime: 2024-08-08 12:17:43.544 --> Time when dump begins. 487 Event runner (Thread name =, Thread ID = 18083) is running --> Information about the running thread. 488 Current Running: start at 2024-08-08 12:17:16.629, Event { send thread = 35882, send time = 2024-08-08 12:17:16.628, handle time = 2024-08-08 12:17:16.629, trigger time = 2024-08-08 12:17:16.630, task name = , caller = xx } 489 --> trigger time--> Time when the task starts to run. 490``` 491 492Running duration of the current task = dump begin curTime – trigger time. In this example, the running duration of the current task is 27s. 493 494If the task running duration is longer than the fault detection duration, the running task causes the application freeze event. In this case, you need to check the task. 495 496If the current task running duration is short, the task is only one of the tasks running in the main thread within the detection duration and may not be the task that consumes most time. You are advised to check the task that consumes the longest time recently (in **History event queue information**). In this case, the watchdog cannot be scheduled because the thread is busy. 497 4982. **History event queue information**. 499 500``` 501 Current Running: start at 2024-08-08 12:17:16.629, Event { send thread = 35882, send time = 2024-08-08 12:17:16.628, handle time = 2024-08-08 12:17:16.629, trigger time = 2024-08-08 12:17:16.630, task name = , caller = [extension_ability_thread.cpp(ScheduleAbilityTransaction:393)]} 502 History event queue information: 503 No. 0 : Event { send thread = 35854, send time = 2024-08-08 12:17:15.525, handle time = 2024-08-08 12:17:15.525, trigger time = 2024-08-08 12:17:15.527, completeTime time = 2024-08-08 12:17:15.528, priority = High, id = 1 } 504 No. 1 : Event { send thread = 35854, send time = 2024-08-08 12:17:15.525, handle time = 2024-08-08 12:17:15.525, trigger time = 2024-08-08 12:17:15.527, completeTime time = 2024-08-08 12:17:15.527, priority = Low, task name = MainThread:SetRunnerStarted } 505 No. 2 : Event { send thread = 35856, send time = 2024-08-08 12:17:15.765, handle time = 2024-08-08 12:17:15.765, trigger time = 2024-08-08 12:17:15.766, completeTime time = 2024-08-08 12:17:15.800, priority = Low, task name = MainThread:LaunchApplication } 506 No. 3 : Event { send thread = 35856, send time = 2024-08-08 12:17:15.767, handle time = 2024-08-08 12:17:15.767, trigger time = 2024-08-08 12:17:15.800, completeTime time = 2024-08-08 12:17:16.629, priority = Low, task name = MainThread:LaunchAbility } 507 No. 4 : Event { send thread = 35854, send time = 2024-08-08 12:17:15.794, handle time = 2024-08-08 12:17:15.794, trigger time = 2024-08-08 12:17:16.629, completeTime time = 2024-08-08 12:17:16.629, priority = IDEL, task name = IdleTime:PostTask } 508 No. 5 : Event { send thread = 35852, send time = 2024-08-08 12:17:16.629, handle time = 2024-08-08 12:17:16.629, trigger time = 2024-08-08 12:17:16.629, completeTime time = , priority = Low, task name = } 509``` 510 511You can search for time-consuming tasks in History event queue information. The task whose **completeTime time** is empty is the current task. 512Task running duration = completeTime time – trigger time. 513Filter out the tasks that take a longer time and check the running status of the tasks. 514 5153. **VIP priority event queue information**. 516 517``` 518 VIP priority event queue information: 519 No. 1 : Event { send thread = 3205, send time = 2024-08-07 04:11:15.407, handle time = 2024-08-07 04:11:15.407, task name = ArkUIWindowInjectPointerEvent, caller = [task_runner_adapter_impl.cpp(PostTask:33)]} 520 No. 2 : Event { send thread = 3205, send time = 2024-08-07 04:11:15.407, handle time = 2024-08-07 04:11:15.407, task name = ArkUIWindowInjectPointerEvent, caller = [task_runner_adapter_impl.cpp(PostTask:33)]} 521 No. 3 : Event { send thread = 3205, send time = 2024-08-07 04:11:15.407, handle time = 2024-08-07 04:11:15.407, task name = ArkUIWindowInjectPointerEvent, caller = [task_runner_adapter_impl.cpp(PostTask:33)]} 522 No. 4 : Event { send thread = 3961, send time = 2024-08-07 04:11:15.408, handle time = 2024-08-07 04:11:15.408, task name = MMI::OnPointerEvent, caller = [input_manager_impl.cpp (OnPointerEvent:493)]} 523 No. 5 : Event { send thread = 3205, send time = 2024-08-07 04:11:15.408, handle time = 2024-08-07 04:11:15.408, task name = ArkUIWindowInjectPointerEvent, caller = [task_runner_adapter_impl.cpp(PostTask:33)]} 524 No. 6 : Event { send thread = 3205, send time = 2024-08-07 04:11:15.409, handle time = 2024-08-07 04:11:15.409, task name = ArkUIWindowInjectPointerEvent, caller = [task_runner_adapter_impl.cpp(PostTask:33)]} 525 No. 7 : Event { send thread = 3205, send time = 2024-08-07 04:11:15.409, handle time = 2024-08-07 04:11:15.409, task name = ArkUIWindowInjectPointerEvent, caller = [task_runner_adapter_impl.cpp(PostTask:33)]} 526 No. 8 : Event { send thread = 3205, send time = 2024-08-07 04:11:15.409, handle time = 2024-08-07 04:11:15.409, task name = ArkUIWindowInjectPointerEvent, caller = [task_runner_adapter_impl.cpp(PostTask:33)]} 527 No. 9 : Event { send thread = 3205, send time = 2024-08-07 04:11:15.410, handle time = 2024-08-07 04:11:15.410, task name = ArkUIWindowInjectPointerEvent, caller = [task_runner_adapter_impl.cpp(PostTask:33)]} 528 ... 529``` 530 531To ensure timely response to the user, all tasks in the user input event propagation are high-priority tasks. The VIP priority event queue is created by the system and records the transmission process of user input -> screen -> window -> ArkUI -> application. It is irrelevant to third-party application events and does not need to be concerned. 532 5334. **High priority event queue information**. 534 535``` 536 High priority event queue information: 537 No. 1 : Event { send thread = 35862, send time = 2024-08-08 12:17:25.526, handle time = 2024-08-08 12:17:25.526, id = 1, caller = [watchdog.cpp(Timer:156)]} 538 No. 2 : Event { send thread = 35862, send time = 2024-08-08 12:17:28.526, handle time = 2024-08-08 12:17:28.526, id = 1, caller = [watchdog.cpp(Timer:156)]} 539 No. 3 : Event { send thread = 35862, send time = 2024-08-08 12:17:31.526, handle time = 2024-08-08 12:17:31.526, id = 1, caller = [watchdog.cpp(Timer:156)]} 540 No. 4 : Event { send thread = 35862, send time = 2024-08-08 12:17:34.530, handle time = 2024-08-08 12:17:34.530, id = 1, caller = [watchdog.cpp(Timer:156)]} 541 No. 5 : Event { send thread = 35862, send time = 2024-08-08 12:17:37.526, handle time = 2024-08-08 12:17:37.526, id = 1, caller = [watchdog.cpp(Timer:156)]} 542 No. 6 : Event { send thread = 35862, send time = 2024-08-08 12:17:40.526, handle time = 2024-08-08 12:17:40.526, id = 1, caller = [watchdog.cpp(Timer:156)]} 543 No. 7 : Event { send thread = 35862, send time = 2024-08-08 12:17:43.544, handle time = 2024-08-08 12:17:43.544 ,id = 1, caller = [watchdog.cpp(Timer:156)]} 544 Total size of High events : 7 545``` 546 547The watchdog task is in the priority queue, which is sent every 3 seconds. 548 549Compare the movements of the watchdog task in the queue of the warning and block events. 550 551warning: 552``` 553 High priority event queue information: 554 No. 1 : Event { send thread = 35862, send time = 2024-08-08 12:17:25.526, handle time = 2024-08-08 12:17:25.526, id = 1, caller = [watchdog.cpp(Timer:156)]} 555 No. 2 : Event { send thread = 35862, send time = 2024-08-08 12:17:28.526, handle time = 2024-08-08 12:17:28.526, id = 1, caller = [watchdog.cpp(Timer:156)]} 556 No. 3 : Event { send thread = 35862, send time = 2024-08-08 12:17:31.526, handle time = 2024-08-08 12:17:31.526, id = 1, caller = [watchdog.cpp(Timer:156)]} 557 No. 4 : Event { send thread = 35862, send time = 2024-08-08 12:17:34.530, handle time = 2024-08-08 12:17:34.530, id = 1, caller = [watchdog.cpp(Timer:156)]} 558 Total size of High events : 4 559``` 560 561block: 562``` 563 High priority event queue information: 564 No. 1 : Event { send thread = 35862, send time = 2024-08-08 12:17:25.526, handle time = 2024-08-08 12:17:25.526, id = 1, caller = [watchdog.cpp(Timer:156)]} 565 No. 2 : Event { send thread = 35862, send time = 2024-08-08 12:17:28.526, handle time = 2024-08-08 12:17:28.526, id = 1, caller = [watchdog.cpp(Timer:156)]} 566 No. 3 : Event { send thread = 35862, send time = 2024-08-08 12:17:31.526, handle time = 2024-08-08 12:17:31.526, id = 1, caller = [watchdog.cpp(Timer:156)]} 567 No. 4 : Event { send thread = 35862, send time = 2024-08-08 12:17:34.530, handle time = 2024-08-08 12:17:34.530, id = 1, caller = [watchdog.cpp(Timer:156)]} 568 No. 5 : Event { send thread = 35862, send time = 2024-08-08 12:17:37.526, handle time = 2024-08-08 12:17:37.526, id = 1, caller = [watchdog.cpp(Timer:156)]} 569 Total size of High events : 5 570``` 571 572In the preceding example, the block queue is longer than the warning queue, but the first task does not change. The possible causes are as follows: 573- The running task is suspended. As a result, other tasks are not scheduled and executed. 574- Tasks in the queue with a higher priority are stacked. As a result, watchdog tasks in the queue with a lower priority are not scheduled. 575 576### Viewing Stack Information 577 578Check the stack using the obtained PID and TID. The result may show as follows: 579 5801. The stack information shows that the process is suspended. 581 582``` 583Tid:3025, Name: xxx 584# 00 pc 00000000001b4094 /system/lib/ld-musl-aarch64.so.1(__timedwait_cp+188)(b168f10a179cf6050a309242262e6a17) 585# 01 pc 00000000001b9fc8 /system/lib/ld-musl-aarch64.so.1(__pthread_mutex_timedlock_inner+592)(b168f10a179cf6050a309242262e6a17) 586# 02 pc 00000000000c3e40 /system/lib64/libc++.so(std::__h::mutex::lock()+8)(9cbc937082b3d7412696099dd58f4f78242f9512) --> The so. file is suspended while waiting for a lock. 587# 03 pc 000000000007ac4c /system/lib64/platformsdk/libnative_rdb.z.so(OHOS::NativeRdb::SqliteConnectionPool::Container::Release(std::__h::shared_ptr<OHOS::NativeRdb::SqliteConnectionPool::ConnNode>)+60)(5e8443def4695e8c791e5f847035ad9f) 588# 04 pc 000000000007aaf4 /system/lib64/platformsdk/libnative_rdb.z.so(OHOS::NativeRdb::SqliteConnectionPool::ReleaseNode(std::__h::shared_ptr<OHOS::NativeRdb::SqliteConnectionPool::ConnNode>)+276)(5e8443def4695e8c791e5f847035ad9f) 589# 05 pc 000000000007a8c0 /system/lib64/platformsdk/libnative_rdb.z.so(5e8443def4695e8c791e5f847035ad9f) 590# 06 pc 00000000000b36ec /system/lib64/platformsdk/libnative_rdb.z.so(OHOS::NativeRdb::SqliteSharedResultSet::Close()+324)(5e8443def4695e8c791e5f847035ad9f) 591# 07 pc 000000000006da94 /system/lib64/module/data/librelationalstore.z.so(OHOS::RelationalStoreJsKit::ResultSetProxy::Close(napi_env__*, napi_callback_info__*) (.cfi)+212)(5c7c67512e12e0e53fd23e82ee576a88) 592# 08 pc 0000000000034408 /system/lib64/platformsdk/libace_napi.z.so(panda::JSValueRef ArkNativeFunctionCallBack<true>(panda::JsiRuntimeCallInfo*)+220)(f271f536a588ef9d0dc5328c70fce511) 593# 09 pc 00000000002d71d0 /system/lib64/module/arkcompiler/stub.an(RTStub_PushCallArgsAndDispatchNative+40) 594# 10 at parseResultSet (entry/build/default/cache/default/default@CompileArkTS/esmodule/release/datamanager/datawrapper/src/main/ets/database/RdbManager.ts:266:1) 595# 11 at query (entry/build/default/cache/default/default@CompileArkTS/esmodule/release/datamanager/datawrapper/src/main/ets/database/RdbManager.ts:188:1) 596``` 597 598The so. file is suspended while waiting for a lock. In this case, locate the error code by decompiling and check the context to fix the bug. 599 6002. The IPC request is suspended. 601 602``` 603Tid:53616, Name:xxx 604# 00 pc 0000000000171c1c /system/lib/ld-musl-aarch64.so.1(ioctl+176)(b168f10a179cf6050a309242262e6a17) 605# 01 pc 0000000000006508 /system/lib64/chipset-pub-sdk/libipc_common.z.so(OHOS::BinderConnector::WriteBinder(unsigned long, void*)+100)(1edec25445c569dd1093635c1da3bc0a) --> The binder is suspended. 606# 02 pc 000000000004d500 /system/lib64/platformsdk/libipc_core.z.so(OHOS::BinderInvoker::TransactWithDriver(bool)+296)(6151eca3b47aa2ab3e378e6e558b90f3) 607# 03 pc 000000000004c6c0 /system/lib64/platformsdk/libipc_core.z.so(OHOS::BinderInvoker::WaitForCompletion(OHOS::MessageParcel*, int*)+128)(6151eca3b47aa2ab3e378e6e558b90f3) 608# 04 pc 000000000004c304 /system/lib64/platformsdk/libipc_core.z.so(OHOS::BinderInvoker::SendRequest(int, unsigned int, OHOS::MessageParcel&, OHOS::MessageParcel&, OHOS::MessageOption&)+348)(6151eca3b47aa2ab3e378e6e558b90f3) 609# 05 pc 00000000000319ac /system/lib64/platformsdk/libipc_core.z.so(OHOS::IPCObjectProxy::SendRequestInner(bool, unsigned int, OHOS::MessageParcel&, OHOS::MessageParcel&, OHOS::MessageOption&)+124)(6151eca3b47aa2ab3e378e6e558b90f3) 610# 06 pc 0000000000031cfc /system/lib64/platformsdk/libipc_core.z.so(OHOS::IPCObjectProxy::SendRequest(unsigned int, OHOS::MessageParcel&, OHOS::MessageParcel&, OHOS::MessageOption&)+184)(6151eca3b47aa2ab3e378e6e558b90f3) 611# 07 pc 0000000000023c7c /system/lib64/libipc.dylib.so(<ipc::remote::obj::RemoteObj>::send_request+268)(7006cb5520edc22f64d04df86cb90152) 612# 08 pc 000000000000b904 /system/lib64/libasset_sdk.dylib.so(<asset_sdk::Manager>::send_request+48)(4073ec22b58b83f79883d5fc8102ce77) 613# 09 pc 000000000000b600 /system/lib64/libasset_sdk.dylib.so(<asset_sdk::Manager>::query+156)(4073ec22b58b83f79883d5fc8102ce77) 614# 10 pc 0000000000006d94 /system/lib64/libasset_sdk_ffi.z.so(query_asset+116)(9a309896092ba014c878289a54688679) 615# 11 pc 0000000000006740 /system/lib64/module/security/libasset_napi.z.so((anonymous namespace)::NapiQuerySync(napi_env__*, napi_callback_info__*) (.cfi)+220)(ef7afe850712e4822f085ed0ac184e8a) 616# 12 pc 0000000000034408 /system/lib64/platformsdk/libace_napi.z.so(panda::JSValueRef ArkNativeFunctionCallBack<true>(panda::JsiRuntimeCallInfo*)+220)(f271f536a588ef9d0dc5328c70fce511) 617``` 618 6193. The warning and error stacks are the same. The stack top displays the synchronous codes. 620 621The warning and error stacks are as follows: 622 623``` 624Tid:14727, Name:xxx 625# 00 pc 00000000001c4c60 /system/lib/ld-musl-aarch64.so.1(pread+72)(b168f10a179cf6050a309242262e6a17) 626# 01 pc 0000000000049154 /system/lib64/platformsdk/libsqlite.z.so(unixRead+180)(48485aa23da681fc87d8dc0b4be3e34c) 627# 02 pc 0000000000053e98 /system/lib64/platformsdk/libsqlite.z.so(readDbPage+116)(48485aa23da681fc87d8dc0b4be3e34c) 628# 03 pc 0000000000053d48 /system/lib64/platformsdk/libsqlite.z.so(getPageNormal+864)(48485aa23da681fc87d8dc0b4be3e34c) 629# 04 pc 00000000000757a0 /system/lib64/platformsdk/libsqlite.z.so(getAndInitPage+216)(48485aa23da681fc87d8dc0b4be3e34c) 630# 05 pc 0000000000077658 /system/lib64/platformsdk/libsqlite.z.so(moveToLeftmost+164)(48485aa23da681fc87d8dc0b4be3e34c) 631# 06 pc 000000000006aa34 /system/lib64/platformsdk/libsqlite.z.so(sqlite3VdbeExec+34532)(48485aa23da681fc87d8dc0b4be3e34c) 632# 07 pc 000000000002e424 /system/lib64/platformsdk/libsqlite.z.so(sqlite3_step+644)(48485aa23da681fc87d8dc0b4be3e34c) 633# 08 pc 00000000000b1a70 /system/lib64/platformsdk/libnative_rdb.z.so(FillSharedBlockOpt+408)(5e8443def4695e8c791e5f847035ad9f) 634# 09 pc 0000000000082a94 /system/lib64/platformsdk/libnative_rdb.z.so(OHOS::NativeRdb::SqliteStatement::FillBlockInfo(OHOS::NativeRdb::SharedBlockInfo*) const+76)(5e8443def4695e8c791e5f847035ad9f) 635# 10 pc 00000000000b4214 /system/lib64/platformsdk/libnative_rdb.z.so(OHOS::NativeRdb::SqliteSharedResultSet::ExecuteForSharedBlock(OHOS::AppDataFwk::SharedBlock*, int, int, bool)+236)(5e8443def4695e8c791e5f847035ad9f) 636``` 637 638Based on [Analyzing Trace Logs](#analyzing-trace logs), check whether the execution of the function at stack top times out. 639 6404. The stack is a temporary stack, and the warning stack is not the same as the error stack. 641 642Warning stack: 643 644``` 645Tid:3108, Name:xxx 646# 00 pc 0000000000146e2c /system/lib/ld-musl-aarch64.so.1(open64+224)(b168f10a179cf6050a309242262e6a17) 647# 01 pc 0000000000014600 /system/lib64/chipset-pub-sdk/libextractortool.z.so(OHOS::AbilityBase::ZipFileReader::init()+600)(c4893935af8fc8cb36569be5ccdebfa9) 648# 02 pc 0000000000014144 /system/lib64/chipset-pub-sdk/libextractortool.z.so(OHOS::AbilityBase::ZipFileReader::CreateZipFileReader(std::__h::basic_string<char, std::__h::char_traits<char>, std::__h::allocator<char>> const&)+392)(c4893935af8fc8cb36569be5ccdebfa9) 649# 03 pc 000000000000f724 /system/lib64/chipset-pub-sdk/libextractortool.z.so(OHOS::AbilityBase::ZipFile::Open()+728)(c4893935af8fc8cb36569be5ccdebfa9) 650# 04 pc 000000000000a808 /system/lib64/chipset-pub-sdk/libextractortool.z.so(OHOS::AbilityBase::Extractor::Init()+124)(c4893935af8fc8cb36569be5ccdebfa9) 651# 05 pc 000000000000c4a4 /system/lib64/chipset-pub-sdk/libextractortool.z.so(OHOS::AbilityBase::ExtractorUtil::GetExtractor(std::__h::basic_string<char, std::__h::char_traits<char>, std::__h::allocator<char>> const&, bool&, bool)+596)(c4893935af8fc8cb36569be5ccdebfa9) 652# 06 pc 00000000000391e4 /system/lib64/platformsdk/libglobal_resmgr.z.so(OHOS::Global::Resource::GetIndexData(char const*, std::__h::unique_ptr<unsigned char [], std::__h::default_delete<unsigned char []>>&, unsigned long&)+284)(5c4263e737507b4a8f2ee7196a152dbd) 653# 07 pc 0000000000038590 /system/lib64/platformsdk/libglobal_resmgr.z.so(OHOS::Global::Resource::HapResource::LoadFromHap(char const*, std::__h::shared_ptr<OHOS::Global::Resource::ResConfigImpl>&, bool, bool, unsigned int const&)+80)(5c4263e737507b4a8f2ee7196a152dbd) 654# 08 pc 00000000000384e8 /system/lib64/platformsdk/libglobal_resmgr.z.so(OHOS::Global::Resource::HapResource::Load(char const*, std::__h::shared_ptr<OHOS::Global::Resource::ResConfigImpl>&, bool, bool, unsigned int const&)+364)(5c4263e737507b4a8f2ee7196a152dbd) 655# 09 pc 000000000002f118 /system/lib64/platformsdk/libglobal_resmgr.z.so(OHOS::Global::Resource::HapManager::AddResourcePath(char const*, unsigned int const&)+280)(5c4263e737507b4a8f2ee7196a152dbd) 656# 10 pc 000000000002efdc /system/lib64/platformsdk/libglobal_resmgr.z.so(OHOS::Global::Resource::HapManager::AddResource(char const*, unsigned int const&)+52)(5c4263e737507b4a8f2ee7196a152dbd) 657``` 658 659Error stack: 660 661``` 662Tid:3108, xxx 663# 00 pc 00000000003e13cc /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::JSObject::GetProperty(panda::ecmascript::JSThread*, panda::ecmascript::JSHandle<panda::ecmascript::JSTaggedValue> const&, panda::ecmascript::JSHandle<panda::ecmascript::JSTaggedValue> const&, panda::ecmascript::JSShared::SCheckMode)+164)(13376099388381a01b166c00a8af99fb) 664# 01 pc 00000000003d5518 /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::JSIterator::IteratorStep(panda::ecmascript::JSThread*, panda::ecmascript::JSHandle<panda::ecmascript::JSTaggedValue> const&)+228)(13376099388381a01b166c00a8af99fb) 665# 02 pc 0000000000570fa8 /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::RuntimeStubs::StArraySpread(unsigned long, unsigned int, unsigned long)+592)(13376099388381a01b166c00a8af99fb) 666# 03 pc 00000000002d53c0 /system/lib64/module/arkcompiler/stub.an(RTStub_CallRuntime+40) 667# 04 at doTask (product/phone/build/default/cache/default/default@CompileArkTS/esmodule/release/staticcommon/launchercommon/src/main/ets/db/RdbTaskPool.ts:1:1) 668# 05 at update (product/phone/build/default/cache/default/default@CompileArkTS/esmodule/release/staticcommon/launchercommon/src/main/ets/db/RdbTaskPool.ts:1:1) 669# 06 at updateAppNameByAbilityInfoAndType (product/phone/build/default/cache/default/default@CompileArkTS/esmodule/release/staticcommon/launchercommon/src/main/ets/db/RdbStoreManager.ts:12:1) 670# 07 at anonymous (product/phone/build/default/cache/default/default@CompileArkTS/esmodule/release/staticcommon/launchercommon/src/main/ets/model/AppModel.ts:0:1) 671# 08 pc 0000000000304a94 /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::InterpreterAssembly::Execute(panda::ecmascript::EcmaRuntimeCallInfo*)+144)(13376099388381a01b166c00a8af99fb) 672# 09 pc 0000000000201d84 /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::builtins::BuiltinsPromiseJob::PromiseReactionJob(panda::ecmascript::EcmaRuntimeCallInfo*)+348)(13376099388381a01b166c00a8af99fb) 673# 10 pc 00000000002d6e14 /system/lib64/module/arkcompiler/stub.an(RTStub_AsmInterpreterEntry+208) 674``` 675 676In this case, the stacks are irregular because they are captured during thread running, which indicates that the thread does not freezes. If the thread is busy, analyze and optimize the application based on [Analyzing Trace Logs](#analyzing-trace logs) and hilog logs. 677 678### Viewing Binder Information 679 680Obtain the binder information after the warning event if it occurs, otherwise, obtain the binder information after the block event. 681 6821. Obtain the Binder information. 683 684``` 685PeerBinderCatcher -- pid==35854 layer_ == 1 686BinderCatcher -- 687 35854:35854 to 52462:52462 code 3 wait:27.185154163 s frz_state:3 -> 35854:35854 to 52462:53462 code 3 wait:27.185154163 s 688 ... 689 52462:52462 to 1386:0 code 13 wait:24.733640622 s frz_state:3 -> 52462:52462 to 1386:0 code 13 wait:24.733640622 s 690``` 691This example shows that there is a call chain from the main thread of process 35854 to process 52462 and to process 1386. You can analyze the cause of the block event based on the stack information of the peer processes. 692 6932. Check whether the thread ID is **0**. 694 695When the thread ID of a process is **0**, it indicates that the application is IPC_FULL. That is, all IPC threads of the application are in use, and no other thread is allocated to the request. As a result, the request is blocked. For example, the thread ID of 1386 process is **0**, which can be analyzed based on its stack. 696 697``` 698pid context request started max ready free_async_space 699 70035862 binder 0 2 16 2 519984 701 70235854 binder 0 2 16 3 520192 703 70435850 binder 0 2 16 3 520192 705 70613669 binder 0 1 16 3 520192 707 708... 709 7101386 binder 1 15 16 0 517264 -> binderInfo 711 7121474 binder 0 2 16 4 520192 713``` 714 715As shown in the stack, the number of threads in the ready state of process 1386 is 0. This indicates that some IPC threads of the process may be blocked. To analyze why the IPC threads are not released, you can check the following causes: An IPC thread that holds the lock is blocked. As a result, other threads are suspended while waiting for the lock. 716 717**free_async_space** is unavailable. As a result, there is no sufficient buffer space for the request of the new IPC thread. It should be noted that this value is required by both synchronous and asynchronous requests. Generally, **free_async_space** is unavailable when a large number of asynchronous requests are sent in a short period of time. 718 7193. Check whether the value of **waitTime** is too small. 720 721**waitTime** indicates the IPC duration. If the value of **waitTime** is far less than the fault detection duration, the suspension is not caused by the IPC request. 722If the main thread on the application sends multiple IPC requests in a short period of time, the value of **waitTime** will be large. As a result, the thread is suspended. 723 724In this case, you can check the following items: 725 - Whether the wait time of a single request is as expected. If the wait time of a single request is greater than the normal value (for example, the request whose normal wait time is 20 ms waits for 1s), check why the API performance does not meet the expectation. 726 - Whether the frequent calling on the application is proper. 727 7284. Check whether there is no calling relationship and whether the stack is an IPC stack. 729 730Check whether the stack is a temporary stack, that is, whether the warning stack is the same as the block stack. It is possible that the warning stack is an IPC stack, and the block stack is a temporary stack because the IPC request has ended when the binder is captured, and the IPC request takes a short time. 731It should be noted that binder information is not obtained in real time when a fault occurs and is delayed. For faults that require half-period detection, binder information is accurately captured because most binder information can be collected within the fault period. For other faults, the off-site binder information may be captured when the reporting is delayed. 732 733You can view the execution duration of binder based on [Analyzing Trace Logs](#analyzing-trace logs). 734 735### Analyzing HiLog logs 736 737#### DFX-related Logs 738 7391. Fault report (reportEvent). 740 741 742 7432. Stack capture (signal: 35). 744 745 746 7473. Background application check for five times before reporting, about 21s. 748 749 750 7514. Application exit reason record. 752 753 754 7555. APP_FREEZE kills the application. 756 757 758 759#### Procedure 760 761View [Obtain the fault occurrence time](#obtain-the-fault-occurrence-time), and determine the fault occurrence time based on the fault type. Analyze the HiLog logs in the specific period to obtain the status of the running thread. 762 763- If no application log is printed, the application freezes when the logging API is called. 764 765  766 767 **...** 768 769  770 771 As shown in the preceding figure, the **APP_INPUT_BLOCK** error is reported at **07:24:08.167**, and the application main thread does not print logs after **07:24:01.581**. Check whether the logic of **FormManagerService: ** 772 773 **[form_mgr_proxy.cpp(GetFormsInfoByApp:1128)]** times out. 774 775- If the application logs are printed frequently, check whether the logs are normal. 776 777  778 779 As shown in the preceding figure, a large number of logs are printed before the process is killed by **APP_FREEZE**. Check whether the logs are normal in the **ImageEffect** domain. 780 781### Analyzing Trace Logs 782 783The possible causes are as follows: 784 7851. The duration of each service is not long, but the number of services is too large. Therefore, the process runs intensively in a long period of time and occupies the main thread. 786 787 788 789 790 791In the preceding figure, the **animator** in **PriviewArea::updateShotComponent** is executed for 9.2s. 792 793The thread is busy executing a service cyclically and analyzing each service segment. 794 795- If the service scenario is not normal (the service should not be called frequently), analyze the service code and find out why the service is executed cyclically. 796 797- Otherwise, check whether the service segment takes more time than expected and why the performance does not meet the design specifications. 798 7992. The process times out when executes a function. 800 801 802 803In the preceding figure, the execution duration of **OHOS::AppExecFwk::FormMgrAdapter::GetFormsInfoByApp** exceeds 8s. 804 805## Case Study 806 807### Typical Case of ThreadBlock - Incorrect Use of Locks 808 809#### Background 810 811The xxx service reports the appfreeze problem **THREAD_BLOCK_6S**. 812 813#### Error Codes 814 815The fourth line is locked, while the function in the sixth line fails and returns without unlocking. As a result, other threads are waiting for the locked function. 816 817```cpp 818int xxx() 819{ 820 ... 821 mutex_.lock(); 822 AIContext aiContext; 823 if (ConvertRpcHandle2AIContext(inputs[0], aiContext) != aicp::SUCCESS) { 824 return FAILED; 825 } 826 ... 827} 828``` 829 830#### Impact 831 832The background application freezes and related functions are unavailable, but it is imperceptible to the user. 833 834#### Fault Locating 835 836Extract the key fault logs. 837 838``` 839appfreeze: com.example.hmsapp.xxx THREAD_BLOCK_6S at 20240408082432 840DisplayPowerInfo:powerState:AWAKE 841``` 842 843The value of **Foreground** indicates that the application is a background application. Therefore, it can be inferred that when the 3s event is reported, the background application is frozen for 18s. 844 845``` 846Module name:com.xxx.xxx.xxx 847Version:1.2.2.202 848VersionCode:1002002202 849PreInstalled:Yes 850Foreground: No --> Indicates that the application is in the background. 851Pid:43675 852Uid:20020029 853Reason:THREAD_BLOCK_6S 854``` 855 856The **THREAD_BLOCK_3S** event is reported at **08:24:29:612**. 857The **THREAD_BLOCK_6S** event is reported at **08:24:32:638**. The interval is 3s as expected. 858 859``` 860>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 861DOMAIN:AAFWK 862STRINGID:THREAD_BLOCK_6S 863TIMESTAMP:2024/04/08-08:24:32:638 864PID:43675 865UID:20020029 866PACKAGE_NAME:com.xxx.xxx.xxx 867PROCESS_NAME:com.xxx.xxx.xxx 868******************************************* 869start time: 2024/04/08-08:24:29:627 870DOMAIN = AAFWK 871EVENTNAME = THREAD_BLOCK_3S 872TIMESTAMP = 2024/04/08-08:24:29:612 873PID = 43675 874UID = 20020029 875PACKAGE_NAME = com.xxx.xxx.xxx 876PROCESS_NAME = com.xxx.xxx.xxx 877``` 878 879When the **THREAD_BLOCK_3S** event is reported, the **EventHandler** is captured at **08:24:29.413**. The cause is as expected: "App main thread is not response!" The main thread does not respond. The running task is sent at **08:24:01.514**. 880 881``` 882MSG = 883Fault time:2024/04/08-08:24:29 884App main thread is not response! 885mainHandler dump is: 886 EventHandler dump begin curTime: 2024-04-08 08:24:29.413 887 Event runner (Thread name = , Thread ID = 43675) is running 888 Current Running: start at 2024-04-08 08:24:01.514, Event { send thread = 43675, send time = 2024-04-08 08:24:01.514, handle time = 2024-04-08 08:24:01.514, task name = uvLoopTask } 889``` 890 891The watchdog task is in **High priority event queue**. As shown in the following figure, a task is thrown to the main thread every 3 seconds, which is as expected. 892 893The queue of **THREAD_BLOCK_3S** is similar to that of **THREAD_BLOCK_6S**, with one more event in the queue of **THREAD_BLOCK_6S**. 894 895The earliest event is sent at **08:24:11.388**, which is 18s earlier than the report time **08:24:29:612** as expected. 896 897``` 898 High priority event queue information: 899 No.1 : Event { send thread = 43679, send time = 2024-04-08 08:24:11.388, handle time = 2024-04-08 08:24:11.388, id = 1, caller = [watchdog.cpp(Timer:139)] } 900 No.2 : Event { send thread = 43679, send time = 2024-04-08 08:24:14.458, handle time = 2024-04-08 08:24:14.458, id = 1, caller = [watchdog.cpp(Timer:139)] } 901 No.3 : Event { send thread = 43679, send time = 2024-04-08 08:24:17.383, handle time = 2024-04-08 08:24:17.383, id = 1, caller = [watchdog.cpp(Timer:139)] } 902 No.4 : Event { send thread = 43679, send time = 2024-04-08 08:24:20.363, handle time = 2024-04-08 08:24:20.363, id = 1, caller = [watchdog.cpp(Timer:139)] } 903 No.5 : Event { send thread = 43679, send time = 2024-04-08 08:24:23.418, handle time = 2024-04-08 08:24:23.418, id = 1, caller = [watchdog.cpp(Timer:139)] } 904 No.6 : Event { send thread = 43679, send time = 2024-04-08 08:24:26.369, handle time = 2024-04-08 08:24:26.369, id = 1, caller = [watchdog.cpp(Timer:139)] } 905 No.7 : Event { send thread = 43679, send time = 2024-04-08 08:24:29.412, handle time = 2024-04-08 08:24:29.412, id = 1, caller = [watchdog.cpp(Timer:139)] } 906``` 907 908To sum up, the main thread of the application starts to run this task at **08:24:01.514**. The first **THREAD_BLOCK_3S** event occurs at **08:24:11.388**, and the application freezes at about **08:24:11**. 909 910View the main thread stack at **xxx_request_client.so -> libsamgr_proxy.z.so -> libipc_core.z.so(OHOS::BinderConnector::WriteBinder)**. 911 912The main thread initiates an IPC request, but the peer process does not respond. As a result, the process freezes, as shown in the following stack. 913 914``` 915Tid:43675, Name:xxx 916# 00 pc 0000000000168c44 /system/lib/ld-musl-aarch64.so.1(ioctl+176)(91b804d2409a13f27463debe9e19fb5d) 917# 01 pc 0000000000049268 /system/lib64/platformsdk/libipc_core.z.so(OHOS::BinderConnector::WriteBinder(unsigned long, void*)+112)(e59500a4ea66775388332f6e3cc12fe3) 918# 02 pc 0000000000054fd4 /system/lib64/platformsdk/libipc_core.z.so(OHOS::BinderInvoker::TransactWithDriver(bool)+296)(e59500a4ea66775388332f6e3cc12fe3) 919# 03 pc 00000000000544c8 /system/lib64/platformsdk/libipc_core.z.so(OHOS::BinderInvoker::WaitForCompletion(OHOS::MessageParcel*, int*)+304)(e59500a4ea66775388332f6e3cc12fe3) 920# 04 pc 0000000000053c84 /system/lib64/platformsdk/libipc_core.z.so(OHOS::BinderInvoker::SendRequest(int, unsigned int, OHOS::MessageParcel&, OHOS::MessageParcel&, OHOS::MessageOption&)+312)(e59500a4ea66775388332f6e3cc12fe3) 921# 05 pc 000000000002d6d8 /system/lib64/platformsdk/libipc_core.z.so(OHOS::IPCObjectProxy::SendRequestInner(bool, unsigned int, OHOS::MessageParcel&, OHOS::MessageParcel&, OHOS::MessageOption&)+128)(e59500a4ea66775388332f6e3cc12fe3) 922# 06 pc 0000000000030e00 /system/lib64/platformsdk/libipc_core.z.so(OHOS::IPCObjectProxy::GetProtoInfo()+396)(e59500a4ea66775388332f6e3cc12fe3) 923# 07 pc 000000000002e990 /system/lib64/platformsdk/libipc_core.z.so(OHOS::IPCObjectProxy::WaitForInit()+292)(e59500a4ea66775388332f6e3cc12fe3) 924# 08 pc 0000000000036cd0 /system/lib64/platformsdk/libipc_core.z.so(OHOS::IPCProcessSkeleton::FindOrNewObject(int)+116)(e59500a4ea66775388332f6e3cc12fe3) 925# 09 pc 00000000000571cc /system/lib64/platformsdk/libipc_core.z.so(OHOS::BinderInvoker::UnflattenObject(OHOS::Parcel&)+272)(e59500a4ea66775388332f6e3cc12fe3) 926# 10 pc 00000000000463a4 /system/lib64/platformsdk/libipc_core.z.so(OHOS::MessageParcel::ReadRemoteObject()+116)(e59500a4ea66775388332f6e3cc12fe3) 927# 11 pc 000000000001250c /system/lib64/chipset-pub-sdk/libsamgr_proxy.z.so(OHOS::SystemAbilityManagerProxy::CheckSystemAbility(int, bool&)+952)(6f113f37ac6ac882cfa16077ad5b406a) 928# 12 pc 0000000000010e7c /system/lib64/chipset-pub-sdk/libsamgr_proxy.z.so(OHOS::SystemAbilityManagerProxy::GetSystemAbilityWrapper(int, std::__h::basic_string<char, std::__h::char_traits<char>, std::__h::allocator<char>> const&)+232)(6f113f37ac6ac882cfa16077ad5b406a) 929# 13 pc 00000000000118b8 /system/lib64/chipset-pub-sdk/libsamgr_proxy.z.so(OHOS::SystemAbilityManagerProxy::Recompute(int, int)+132)(6f113f37ac6ac882cfa16077ad5b406a) 930# 14 pc 0000000000011170 /system/lib64/chipset-pub-sdk/libsamgr_proxy.z.so(OHOS::DynamicCache<int, OHOS::sptr<OHOS::IRemoteObject>>::QueryResult(int, int)+316)(6f113f37ac6ac882cfa16077ad5b406a) 931# 15 pc 0000000000007e0c xxx_request_client.so(xxx::RPCRequestClient::GetService()+540)(557450139184527807025a632613fd76) 932# 16 pc 0000000000008824 xxx_request_client.so(xxx::RPCRequestClient::Init()+16)(557450139184527807025a632613fd76) 933# 17 pc 0000000000008d60 xxx_request_client.so(CreateRpcRequestByServiceName+104)(557450139184527807025a632613fd76) 934# 18 pc 0000000000008f98 xxx_request_client.so(CreateRpcRequest+72)(557450139184527807025a632613fd76) 935# 19 pc 0000000000002944 xxx_rpc_client.so(xxx::xxx::RpcRequestClient::RpcRequestClient()+224)(02343ed2fff69759d408b23eaf69fcde) 936``` 937 938Check **BinderCatcher**. The main thread **43675** is communicating with process **979** and the **BinderCatcher** waits for 27s. 939 940``` 941PeerBinderCatcher -- pid==43675 layer_ == 1 942BinderCatcher -- 943 43675:43675 to 979:0 code 5f475249 wait:27.104545829 s frz_state:1 --> The binder communication waits for 27s. 944 57187:39147 to 28644:30753 code 0 wait:0.337894271 s frz_state:3 945 57187:39151 to 28644:28652 code 7 wait:0.531140625 s frz_state:3 946 57187:39150 to 28644:31297 code 0 wait:0.976419270 s frz_state:3 947 57187:38979 to 28644:32554 code 0 wait:0.22108334 s frz_state:3 948 57187:39149 to 28644:30754 code 0 wait:0.534261979 s frz_state:3 949 57187:38949 to 28644:31301 code 0 wait:0.977779166 s frz_state:3 950 57187:39172 to 28644:35667 code 0 wait:1.47387500 s frz_state:3 951 57187:39173 to 28644:28822 code 0 wait:0.565389063 s frz_state:3 952 1477:1676 to 1408:2026 code 17 wait:0.0 s frz_state:3 953 628:8136 to 979:0 code 2 wait:13166.722870859 s frz_state:1 954``` 955 956Check the main thread stack of process **979**, and it shows that **xxxserver** is waiting for lock release. This fault is caused by improper use of locks. 957 958``` 959PeerBinder Stacktrace -- 960PeerBinderCatcher start catcher stacktrace for pid : 979 961Result: 0 ( no error ) 962Timestamp:2024-04-08 08:24:29.000 963Pid:979 964Uid:3094 965Process name:xxxserver 966Process life time:60410s 967Tid:979, Name:xxxserver 968# 00 pc 00000000001aafc4 /system/lib/ld-musl-aarch64.so.1(__timedwait_cp+192)(91b804d2409a13f27463debe9e19fb5d) 969# 01 pc 00000000001b0d50 /system/lib/ld-musl-aarch64.so.1(__pthread_mutex_timedlock_inner+592)(91b804d2409a13f27463debe9e19fb5d) 970# 02 pc 00000000000c38e0 /system/lib64/libc++.so(std::__h::mutex::lock()+8)(0b61ba21a775725a1bd8802a393b133afbc503a5) --> The lock() function is called and the process waits for it. 971# 03 pc 00000000000086dc xxx_server.so(xxx::xxx::InitImpl(int, std::__h::vector<xxx::xxx::RpcHandle, std::__h::allocator<xxx::xxx::RpcHandle>> const&, std::__h::vector<xxx::xxx::RpcHandle, std::__h::allocator<xxx::xxx::RpcHandle>>&)+84)(f4bb275898d797b22eae35fe48db9009) 972# 04 pc 000000000000798c xxx_request_server.so(xxx::RPCRequestStub::SyncExecute(OHOS::MessageParcel&, OHOS::MessageParcel&)+164)(70cbb10c758902c1e3e179efc93ce0af) 973# 05 pc 0000000000008314 xxx_request_server.so(xxx::RPCRequestStub::OnRemoteRequest(unsigned int, OHOS::MessageParcel&, OHOS::MessageParcel&, OHOS::MessageOption&)+300)(70cbb10c758902c1e3e179efc93ce0af) 974# 06 pc 00000000000153e4 /system/lib64/chipset-pub-sdk/libipc_single.z.so(OHOS::IPCObjectStub::SendRequest(unsigned int, OHOS::MessageParcel&, OHOS::MessageParcel&, OHOS::MessageOption&)+604)(25b3d63905ef47289c096ea42ba2d86a) 975# 07 pc 000000000002b464 /system/lib64/chipset-pub-sdk/libipc_single.z.so(OHOS::IPC_SINGLE::BinderInvoker::OnTransaction(unsigned char const*)+1220)(25b3d63905ef47289c096ea42ba2d86a) 976# 08 pc 000000000002baec /system/lib64/chipset-pub-sdk/libipc_single.z.so(OHOS::IPC_SINGLE::BinderInvoker::HandleCommandsInner(unsigned int)+368)(25b3d63905ef47289c096ea42ba2d86a) 977# 09 pc 000000000002a6b0 /system/lib64/chipset-pub-sdk/libipc_single.z.so(OHOS::IPC_SINGLE::BinderInvoker::HandleCommands(unsigned int)+60)(25b3d63905ef47289c096ea42ba2d86a) 978# 10 pc 000000000002a4dc /system/lib64/chipset-pub-sdk/libipc_single.z.so(OHOS::IPC_SINGLE::BinderInvoker::StartWorkLoop()+120)(25b3d63905ef47289c096ea42ba2d86a) 979# 11 pc 000000000002bc2c /system/lib64/chipset-pub-sdk/libipc_single.z.so(OHOS::IPC_SINGLE::BinderInvoker::JoinThread(bool)+92)(25b3d63905ef47289c096ea42ba2d86a) 980# 12 pc 0000000000004bd4 xxxserver(02cff7e5dce05d6d28096601458b6f6d) 981# 13 pc 00000000000a3b58 /system/lib/ld-musl-aarch64.so.1(libc_start_main_stage2+64)(91b804d2409a13f27463debe9e19fb5d) 982``` 983 984Decompile the code to locate the error line and check the lock based on the context. 985 986#### Solution 987 988```cpp 989int xxx() 990{ 991 ... 992 mutex_.lock(); 993 AIContext aiContext; 994 if (ConvertRpcHandle2AIContext(inputs[0], aiContext) != aicp::SUCCESS) { 995 return FAILED; 996 } 997 ... 998} 999``` 1000 1001Modify the preceding codes as follows: 1002 1003```cpp 1004int xxx() 1005{ 1006 ... 1007 AIContext aiContext; 1008 if (ConvertRpcHandle2AIContext(inputs[0], aiContext) != aicp::SUCCESS) { 1009 return FAILED; 1010 } 1011 mutex_.lock(); 1012 ... 1013} 1014``` 1015 1016Adjust the lock properly based on the context. 1017 1018#### Suggestions 1019 10201. Pay special attention to the timing and deadlock issues during multi-thread interaction. 1021 1022### Typical Case of **APP_INPUT_BLOCK** - Full Component Update 1023 1024#### Background 1025 1026When the theme is switched, the system freezes, and the appfreeze problem of sceneboard is reported. 1027 1028This appfreeze problem occurs because the thread is too busy. 1029 1030#### Error Codes 1031 1032Component update and reuse are controlled by the **key** value of the component. When a page is updated, if the **key** value of the component remains unchanged, the original component is reused. If the **key** value changes, the component and its subcomponents are updated. 1033 1034This function is used to generate the **key** of the home screen component and is associated with **themeStyle**. When a user continuously switches the theme on the home screen, the component is repeatedly refreshed in full mode. As a result, the system stops responding. 1035 1036```ts 1037private getForeachKey(item: xxx): string { 1038 ... 1039 return `${item.xxx2}${item.xxx2}...${item.themeStyle}`; 1040} 1041``` 1042 1043#### Impact 1044 1045There is a high probability that the screen freezes when the theme is switched on the integrated home screen. When the user clicks, the screen does not respond and then returns to the lock screen, 1046 1047which severely affect user experience. 1048 1049#### Fault Locating 1050 1051Extract the key fault logs. 1052 1053``` 1054appfreeze: com.example.sceneboard APP_INPUT_BLOCK at 20240319022527 1055DisplayPowerInfo:powerState:AWAKE 1056``` 1057 1058The **APP_INPUT_BLOCK** event is reported at **14:40:59:440**. 1059 1060``` 1061DOMAIN:AAFWK 1062STRINGID:APP_INPUT_BLOCK 1063TIMESTAMP:2024/03/14-14:40:59:440 --> Fault report time. 1064PID:2918 1065UID:20020017 1066PACKAGE_NAME:com.example.sceneboard 1067PROCESS_NAME:com.example.sceneboard 1068``` 1069 1070The reported cause is "User input does not respond!". There is no response to the user input event. 1071The running task of the main thread (Thread ID == PID) starts at **14:40:53.499** and is not complete until the **Fault time** **14:40:58**. 1072 1073``` 1074MSG = 1075Fault time:2024/03/14-14:40:58 1076User input does not respond! 1077mainHandler dump is: 1078 EventHandler dump begin curTime: 2024-03-14 02:40:58.520 1079 Event runner (Thread name = , Thread ID = 2918) is running 1080 Current Running: start at 2024-03-14 02:40:53.499, Event { send thread = 2918, send time = 2024-03-14 02:40:53.499, handle time = 2024-03-14 02:40:53.499, task name = } 1081``` 1082 1083User input events need to be responded immediately. Therefore, they are in the high priority event queue, together with the watchdog tasks. 1084 1085In the following example, more than 200 input events are blocked in the queue. 1086 1087``` 1088 High priority event queue information: 1089 No.1 : Event { send thread = 3370, send time = 2024-03-14 02:40:53.690, handle time = 2024-03-14 02:40:53.690, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1090 No.2 : Event { send thread = 3370, send time = 2024-03-14 02:40:53.699, handle time = 2024-03-14 02:40:53.699, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1091 No.3 : Event { send thread = 3370, send time = 2024-03-14 02:40:53.708, handle time = 2024-03-14 02:40:53.708, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1092 No.4 : Event { send thread = 3370, send time = 2024-03-14 02:40:53.717, handle time = 2024-03-14 02:40:53.717, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1093 No.5 : Event { send thread = 3370, send time = 2024-03-14 02:40:53.726, handle time = 2024-03-14 02:40:53.726, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1094 No.6 : Event { send thread = 3370, send time = 2024-03-14 02:40:53.736, handle time = 2024-03-14 02:40:53.736, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1095 No.7 : Event { send thread = 3370, send time = 2024-03-14 02:40:53.745, handle time = 2024-03-14 02:40:53.745, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1096 No.8 : Event { send thread = 3370, send time = 2024-03-14 02:40:53.754, handle time = 2024-03-14 02:40:53.754, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1097 ... 1098 No.190 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.166, handle time = 2024-03-14 02:40:56.166, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1099 No.191 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.176, handle time = 2024-03-14 02:40:56.176, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1100 No.192 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.186, handle time = 2024-03-14 02:40:56.186, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1101 No.193 : Event { send thread = 2923, send time = 2024-03-14 02:40:56.196, handle time = 2024-03-14 02:40:56.196, id = 1, caller = [watchdog.cpp(Timer:140)] } 1102 No.194 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.196, handle time = 2024-03-14 02:40:56.196, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1103 No.195 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.206, handle time = 2024-03-14 02:40:56.206, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1104 No.196 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.216, handle time = 2024-03-14 02:40:56.216, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1105 No.197 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.226, handle time = 2024-03-14 02:40:56.226, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1106 No.198 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.236, handle time = 2024-03-14 02:40:56.236, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1107 No.199 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.245, handle time = 2024-03-14 02:40:56.245, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1108 No.200 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.254, handle time = 2024-03-14 02:40:56.254, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1109 No.201 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.265, handle time = 2024-03-14 02:40:56.265, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1110 No.202 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.275, handle time = 2024-03-14 02:40:56.274, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1111 No.203 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.284, handle time = 2024-03-14 02:40:56.284, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1112 No.204 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.294, handle time = 2024-03-14 02:40:56.294, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1113 No.205 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.305, handle time = 2024-03-14 02:40:56.305, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1114``` 1115 1116The input event triggers the main thread task of the application. However, the execution is not complete within 6 seconds and no response is returned. As a result, the ANR times out. 1117In this case, you only need to find out the task that the input triggers and why the task execution times out. 1118 1119In the running main thread stack, the **ark_jsruntime GetCurrentThreadId** function at the stack top does not hold a lock or is time-consuming. The captured stack is a transient stack that is useless for analysis. 1120 1121``` 1122Tid:2918, Name:example.sceneboard 1123# 00 pc 000000000009f73c /system/lib/ld-musl-aarch64.so.1(8fa55898166cd804dad43d909b5319cc) 1124# 01 pc 000000000054b7b4 /system/lib64/platformsdk/libark_jsruntime.so(panda::os::thread::GetCurrentThreadId()+12)(7715646e48f750f3dc31e660b056eb43) 1125# 02 pc 00000000002107a4 /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::EcmaVM::CheckThread() const+200)(7715646e48f750f3dc31e660b056eb43) 1126# 03 pc 0000000000432998 /system/lib64/platformsdk/libark_jsruntime.so(panda::JSNApi::GetHandleAddr(panda::ecmascript::EcmaVM const*, unsigned long)+64)(7715646e48f750f3dc31e660b056eb43) 1127# 04 pc 000000000003eeb8 /system/lib64/platformsdk/libace_napi.z.so(ArkNativeReference::Get()+32)(c3a760aff0c73a2e76accaf518321fc9) 1128# 05 pc 0000000000043cb4 /system/lib64/platformsdk/libace_napi.z.so(napi_get_reference_value+48)(c3a760aff0c73a2e76accaf518321fc9) 1129# 06 pc 0000000000007564 /system/lib64/module/events/libemitter.z.so(OHOS::AppExecFwk::SearchCallbackInfo(napi_env__*, std::__h::variant<unsigned int, std::__h::basic_string<char, std::__h::char_traits<char>, std::__h::allocator<char>>> const&, napi_value__*)+248)(8fe2937855aab3ea839419f952597511) 1130# 07 pc 0000000000007d8c /system/lib64/module/events/libemitter.z.so(OHOS::AppExecFwk::OnOrOnce(napi_env__*, napi_callback_info__*, bool)+568)(8fe2937855aab3ea839419f952597511) 1131# 08 pc 00000000000096d8 /system/lib64/module/events/libemitter.z.so(OHOS::AppExecFwk::JS_Once(napi_env__*, napi_callback_info__*) (.cfi)+84)(8fe2937855aab3ea839419f952597511) 1132# 09 pc 000000000002c8f0 /system/lib64/platformsdk/libace_napi.z.so(ArkNativeFunctionCallBack(panda::JsiRuntimeCallInfo*)+168)(c3a760aff0c73a2e76accaf518321fc9) 1133# 10 pc 0000000000187b48 /system/lib64/module/arkcompiler/stub.an(RTStub_PushCallArgsAndDispatchNative+40) 1134# 11 pc 00000000002da5fc /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::InterpreterAssembly::Execute(panda::ecmascript::EcmaRuntimeCallInfo*)+416)(7715646e48f750f3dc31e660b056eb43) 1135# 12 pc 00000000002da5fc /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::InterpreterAssembly::Execute(panda::ecmascript::EcmaRuntimeCallInfo*)+416)(7715646e48f750f3dc31e660b056eb43) 1136# 13 pc 00000000003954a0 /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::JSStableArray::HandleforEachOfStable(panda::ecmascript::JSThread*, panda::ecmascript::JSHandle<panda::ecmascript::JSObject>, panda::ecmascript::JSHandle<panda::ecmascript::JSTaggedValue>, panda::ecmascript::JSHandle<panda::ecmascript::JSTaggedValue>, unsigned int, unsigned int&)+596)(7715646e48f750f3dc31e660b056eb43) 1137# 14 pc 000000000018f4b0 /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::builtins::BuiltinsArray::ForEach(panda::ecmascript::EcmaRuntimeCallInfo*)+840)(7715646e48f750f3dc31e660b056eb43) 1138... 1139``` 1140 1141Check the HiLog logs. 1142 1143The **APP_INPUT_BLOCK** event is reported at about **13:40:59.448**, and then DFX kills the suspended SCB. 1144 1145 1146 11476 seconds before, a click event was sent to the SCB at about **14:40:53.498**. 1148 1149 1150 1151Within the 6 seconds, a large number of SCB logs are printed, showing that the SCB is re-rendered. 1152 1153 1154 1155Check the trace log within the 6 seconds. 1156 1157 1158 1159It shows that the SCB main thread is fully occupied. The **CustomNodeUpdate SwiperPage** task takes a longer time. Therefore, you need to check why this component keeps refreshing. 1160 1161It is found that **themeStyle** is added to the **key** on **swiperPage**. When the **key** value changes, a new component is created. 1162 1163When a user switches the theme or icon style, all components on the home screen are created. As a result, the main thread is busy and cannot respond the input event. 1164 1165#### Solution 1166 1167Trigger the home screen component refresh only when the home screen component style is switched, and narrow down the refresh scope. 1168 1169```ts 1170+ if (!CheckEmptyUtils.isEmpty(themeStyleInfo.iconResourcePath) && 1171+ themeStyleInfo.iconResourcePath !== this.themeStyle.iconResourcePath) { 1172+ this.isStyleChanged = true; 1173+ this.themeStyle.iconResourcePath = themeStyleInfo.iconResourcePath; --> themeStyle is associated with iconResourcePath. 1174+ } 1175``` 1176 1177#### Suggestions 1178 1179Minimize the scope of page refresh triggered by a click event. Avoid scenarios where a large number of components need to be refreshed or a page needs to be refreshed frequently. 1180 1181### Typical Case of **LIFECYCLE_TIMEOUT** - Loading a Cloud Image 1182 1183#### Background 1184 1185When a user opens a cloud note, the application freezes and then crashes. 1186 1187#### Error Codes 1188 1189The cloud image is obtained synchronously in a loop. 1190 1191```ts 1192public static xxxFunction(fileUris: string[]): void { 1193 ... 1194 for (const fileuril of fileUrils) { 1195 let file = fs.openSync(fileUri, fs.OpenMode.READ_ONLY); 1196 ... 1197 } 1198 ... 1199} 1200``` 1201 1202#### Impact 1203 1204The application freezes and crashes when it is started or switched to the foreground. 1205 1206#### Fault Locating 1207 1208The following example extracts the key fault logs of **LIFECYCLE_TIMEOUT** that occurs in notepad. 1209 1210``` 1211 sysfreeze: LIFECYCLE_TIMEOUT LIFECYCLE_TIMEOUT at 20240201100459 1212``` 1213 1214The **MSG** information indicates that the timeout occurs in the foreground, and the duration is 5s. 1215 1216``` 1217MSG = 1218Fault time:2024/02/01-10:04:57 1219ability:MainAbility foreground timeout. 1220server: 1221312522; AbilityRecord::ForegroundAbility; the ForegroundAbility lifecycle starts. 1222client: 1223312522; AbilityThread::ScheduleAbilityTransaction; the foreground lifecycle. 1224``` 1225 1226The **LIFECYCLE_HALF_TIMEOUT** event is reported at **10:04:57:538**. 1227The **LIFECYCLE_TIMEOUT** event is reported at **10:04:59:965**. The interval of the two events is about 2.5s, which is as expected. 1228 1229``` 1230>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1231DOMAIN:AAFWK 1232STRINGID:LIFECYCLE_TIMEOUT 1233TIMESTAMP:2024/02/01-10:04:59:965 1234PID:18083 1235UID:20020041 1236PACKAGE_NAME:com.example.notepad 1237PROCESS_NAME:com.example.notepad 1238******************************************* 1239start time: 2024/02/01-10:04:57:555 1240DOMAIN = AAFWK 1241EVENTNAME = LIFECYCLE_HALF_TIMEOUT 1242TIMESTAMP = 2024/02/01-10:04:57:538 1243PID = 18083 1244UID = 20020041 1245TID = 17286 1246PACKAGE_NAME = com.example.notepad 1247PROCESS_NAME = com.example.notepad 1248``` 1249 1250The task starts at **10:04:54.798**, and the interval between the start time and **LIFECYCLE_HALF_TIMEOUT** is about 2.5s, which is as expected. 1251 1252``` 1253mainHandler dump is: 1254 EventHandler dump begin curTime: 2024-02-01 10:04:57.306 1255 Event runner (Thread name = , Thread ID = 18083) is running 1256 Current Running: start at 2024-02-01 10:04:54.798, Event { send thread = 18132, send time = 2024-02-01 10:04:54.778, handle time = 2024-02-01 10:04:54.778, task name = UIAbilityThread:SendResult } 1257 History event queue information: 1258 No. 0 : Event { send thread = 18083, send time = 2024-02-01 10:04:46.481, handle time = 2024-02-01 10:04:46.981, trigger time = 2024-02-01 10:04:46.982, completeTime time = 2024-02-01 10:04:46.982, task name = } 1259 No. 1 : Event { send thread = 18132, send time = 2024-02-01 10:04:47.149, handle time = 2024-02-01 10:04:47.149, trigger time = 2024-02-01 10:04:47.149, completeTime time = 2024-02-01 10:04:47.197, task name = MainThread:BackgroundApplication } 1260 No. 2 : Event { send thread = 18083, send time = 2024-02-01 10:04:44.329, handle time = 2024-02-01 10:04:47.329, trigger time = 2024-02-01 10:04:47.329, completeTime time = 2024-02-01 10:04:47.329, task name = } 1261 No. 3 : Event { send thread = 18087, send time = 2024-02-01 10:04:48.091, handle time = 2024-02-01 10:04:48.091, trigger time = 2024-02-01 10:04:48.091, completeTime time = 2024-02-01 10:04:48.091, task name = } 1262 No. 4 : Event { send thread = 18087, send time = 2024-02-01 10:04:51.047, handle time = 2024-02-01 10:04:51.047, trigger time = 2024-02-01 10:04:51.048, completeTime time = 2024-02-01 10:04:51.048, task name = } 1263 No. 5 : Event { send thread = 18087, send time = 2024-02-01 10:04:54.067, handle time = 2024-02-01 10:04:54.067, trigger time = 2024-02-01 10:04:54.067, completeTime time = 2024-02-01 10:04:54.067, task name = } 1264 ... 1265``` 1266 1267Check the stack information at **libfs.z.so > libdatashare_consumer.z.so > libipc_core.z.so**. 1268 1269``` 1270Tid:18083, Name:ei.example.notepad 1271# 00 pc 00000000001617a4 /system/lib/ld-musl-aarch64.so.1(ioctl+180)(4ca73cff61bea7c4a687eb0f71c9df69) 1272# 01 pc 000000000003e8a0 /system/lib64/platformsdk/libipc_core.z.so(OHOS::BinderConnector::WriteBinder(unsigned long, void*)+72)(3248fceb1fa676994734e0437430ce37) 1273# 02 pc 0000000000049f38 /system/lib64/platformsdk/libipc_core.z.so(OHOS::BinderInvoker::TransactWithDriver(bool)+296)(3248fceb1fa676994734e0437430ce37) 1274# 03 pc 00000000000496f8 /system/lib64/platformsdk/libipc_core.z.so(OHOS::BinderInvoker::WaitForCompletion(OHOS::MessageParcel*, int*)+116)(3248fceb1fa676994734e0437430ce37) 1275# 04 pc 00000000000490bc /system/lib64/platformsdk/libipc_core.z.so(OHOS::BinderInvoker::SendRequest(int, unsigned int, OHOS::MessageParcel&, OHOS::MessageParcel&, OHOS::MessageOption&)+312)(3248fceb1fa676994734e0437430ce37) 1276# 05 pc 0000000000027700 /system/lib64/platformsdk/libipc_core.z.so(OHOS::IPCObjectProxy::SendRequestInner(bool, unsigned int, OHOS::MessageParcel&, OHOS::MessageParcel&, OHOS::MessageOption&)+132)(3248fceb1fa676994734e0437430ce37) 1277# 06 pc 000000000002799c /system/lib64/platformsdk/libipc_core.z.so(OHOS::IPCObjectProxy::SendRequest(unsigned int, OHOS::MessageParcel&, OHOS::MessageParcel&, OHOS::MessageOption&)+140)(3248fceb1fa676994734e0437430ce37) 1278# 07 pc 000000000002640c /system/lib64/platformsdk/libdatashare_consumer.z.so(OHOS::DataShare::DataShareProxy::OpenFile(OHOS::Uri const&, std::__h::basic_string<char, std::__h::char_traits<char>, std::__h::allocator<char>> const&)+440)(e93b5085235269d4b7218ea7de64b69a) 1279# 08 pc 0000000000014b2c /system/lib64/platformsdk/libdatashare_consumer.z.so(OHOS::DataShare::ExtSpecialController::OpenFile(OHOS::Uri const&, std::__h::basic_string<char, std::__h::char_traits<char>, std::__h::allocator<char>> const&)+160)(e93b5085235269d4b7218ea7de64b69a) 1280# 09 pc 0000000000022c54 /system/lib64/platformsdk/libdatashare_consumer.z.so(OHOS::DataShare::DataShareHelperImpl::OpenFile(OHOS::Uri&, std::__h::basic_string<char, std::__h::char_traits<char>, std::__h::allocator<char>> const&)+96)(e93b5085235269d4b7218ea7de64b69a) 1281# 10 pc 0000000000108b34 /system/lib64/module/file/libfs.z.so(OHOS::FileManagement::ModuleFileIO::OpenFileByDatashare(std::__h::basic_string<char, std::__h::char_traits<char>, std::__h::allocator<char>> const&, unsigned int)+468)(152580bf9c379f11f29fdded278541bd) 1282# 11 pc 0000000000108264 /system/lib64/module/file/libfs.z.so(OHOS::FileManagement::ModuleFileIO::OpenFileByUri(std::__h::basic_string<char, std::__h::char_traits<char>, std::__h::allocator<char>> const&, unsigned int)+1760)(152580bf9c379f11f29fdded278541bd) 1283# 12 pc 00000000001077fc /system/lib64/module/file/libfs.z.so(OHOS::FileManagement::ModuleFileIO::Open::Sync(napi_env__*, napi_callback_info__*) (.cfi)+1036)(152580bf9c379f11f29fdded278541bd) 1284# 13 pc 000000000002bbf8 /system/lib64/platformsdk/libace_napi.z.so(ArkNativeFunctionCallBack(panda::JsiRuntimeCallInfo*)+168)(f5b81db475835ee752235c606b1c5e33) 1285# 14 pc 0000000000132e48 /system/lib64/module/arkcompiler/stub.an 1286``` 1287 1288The **BinderCatcher** information shows that the communication with process **5235** takes more than 2.5s, which is as expected. 1289 1290``` 1291PeerBinderCatcher -- pid==18083 layer_ == 1 1292BinderCatcher -- 1293 18083:18083 to 5235:7437 code 2 wait:2.723147396 s 1294 3462:3840 to 4956:4958 code 8 wait:261.213830169 s 1295 3462:3621 to 4956:4981 code 8 wait:273.550283291 s 1296``` 1297 1298The **5235** process is a media library process and the stack information is not useful for analysis. 1299 1300``` 1301PeerBinder Stacktrace -- 1302PeerBinderCatcher start catcher stacktrace for pid : 5235 1303Result: 0 ( no error ) 1304Timestamp:2024-02-01 10:04:57.000 1305Pid:5235 1306Uid:20020079 1307Process name:com.medialibrary.medialibrarydata 1308Tid:5235, Name:edialibrarydata 1309# 00 pc 0000000000142d1c /system/lib/ld-musl-aarch64.so.1(epoll_wait+84)(4ca73cff61bea7c4a687eb0f71c9df69) 1310# 01 pc 000000000000fb74 /system/lib64/chipset-pub-sdk/libeventhandler.z.so(OHOS::AppExecFwk::EpollIoWaiter::WaitFor(std::__h::unique_lock<std::__h::mutex>&, long)+224)(a4d21072c08fd3ac639d5cf5b8fb8b51) 1311# 02 pc 0000000000019df8 /system/lib64/chipset-pub-sdk/libeventhandler.z.so(OHOS::AppExecFwk::EventQueue::WaitUntilLocked(std::__h::chrono::time_point<std::__h::chrono::steady_clock, std::__h::chrono::duration<long long, std::__h::ratio<1l, 1000000000l>>> const&, std::__h::unique_lock<std::__h::mutex>&)+180)(a4d21072c08fd3ac639d5cf5b8fb8b51) 1312# 03 pc 0000000000019c6c /system/lib64/chipset-pub-sdk/libeventhandler.z.so(OHOS::AppExecFwk::EventQueue::GetEvent()+128)(a4d21072c08fd3ac639d5cf5b8fb8b51) 1313# 04 pc 00000000000202b8 /system/lib64/chipset-pub-sdk/libeventhandler.z.so(OHOS::AppExecFwk::(anonymous namespace)::EventRunnerImpl::Run()+1164)(a4d21072c08fd3ac639d5cf5b8fb8b51) 1314# 05 pc 0000000000022388 /system/lib64/chipset-pub-sdk/libeventhandler.z.so(OHOS::AppExecFwk::EventRunner::Run()+120)(a4d21072c08fd3ac639d5cf5b8fb8b51) 1315# 06 pc 000000000007ea08 /system/lib64/platformsdk/libappkit_native.z.so(OHOS::AppExecFwk::MainThread::Start()+772)(183fe2babcfdd3e1ea4bca16a0e26a5d) 1316# 07 pc 0000000000011ac8 /system/bin/appspawn(RunChildProcessor+236)(7b715884c45cfe57b22df46fdaeeca88) 1317# 08 pc 0000000000034684 /system/bin/appspawn(AppSpawnChild+264)(7b715884c45cfe57b22df46fdaeeca88) 1318# 09 pc 00000000000344f4 /system/bin/appspawn(AppSpawnProcessMsg+380)(7b715884c45cfe57b22df46fdaeeca88) 1319# 10 pc 00000000000305a0 /system/bin/appspawn(OnReceiveRequest+1820)(7b715884c45cfe57b22df46fdaeeca88) 1320# 11 pc 0000000000017c58 /system/lib64/chipset-pub-sdk/libbegetutil.z.so(HandleRecvMsg_+260)(22f33d1b0218f31bad0dcc75cf348b90) 1321# 12 pc 00000000000178fc /system/lib64/chipset-pub-sdk/libbegetutil.z.so(HandleStreamEvent_+148)(22f33d1b0218f31bad0dcc75cf348b90) 1322# 13 pc 0000000000015478 /system/lib64/chipset-pub-sdk/libbegetutil.z.so(ProcessEvent+112)(22f33d1b0218f31bad0dcc75cf348b90) 1323# 14 pc 0000000000015090 /system/lib64/chipset-pub-sdk/libbegetutil.z.so(RunLoop_+308)(22f33d1b0218f31bad0dcc75cf348b90) 1324# 15 pc 000000000002eff4 /system/bin/appspawn(AppSpawnRun+116)(7b715884c45cfe57b22df46fdaeeca88) 1325# 16 pc 000000000001f438 /system/bin/appspawn(main+724)(7b715884c45cfe57b22df46fdaeeca88) 1326# 17 pc 00000000000a0974 /system/lib/ld-musl-aarch64.so.1(libc_start_main_stage2+64)(4ca73cff61bea7c4a687eb0f71c9df69) 1327# 18 pc 000000000001106c /system/bin/appspawn(_start_c+76)(7b715884c45cfe57b22df46fdaeeca88) 1328``` 1329 1330The preceding information indicates that the application loads files synchronously using the URI through **Open::Sync** and calls **datashare()** to obtain media library file data. 1331 1332The log information shows that the process freezes when calling **datashare()** to load the cloud image, which is consistent with the stack information. 1333 1334 1335 1336Check the code: 1337 1338It is unreasonable to load **fileUri** synchronously in a loop. When the network is weak or a large amount of data is loaded at the same time, the application tends to be suspended. In this case, the application need to be modified. 1339 1340#### Solution 1341 1342Change the synchronous loading to asynchronous loading, use a flag to indicate whether the loading is complete and display the loading effect on the GUI. 1343 1344```ts 1345public static xxxFunction(fileUris: string[]): void { 1346 ... 1347 for (const fileuril of fileUrils) { 1348 let file = fs.openSync(fileUri, fs.OpenMode.READ_ONLY); 1349 ... 1350 } 1351 ... 1352} 1353``` 1354 1355Modify the preceding codes as follows: 1356 1357```ts 1358public static async xxxFunction(fileUris: string[]): void { 1359 ... 1360 AppStorage.setOrCreate<boolean>('isLoadingPic', true); --> This function is used to display the page load effect. 1361 for (const fileuril of fileUrils) { 1362 let file = await fs.open(fileUri, fs.OpenMode.READ_ONLY); 1363 ... 1364 } 1365 ... 1366} 1367``` 1368 1369#### Suggestions 1370 13711. Verify the requested cloud data in scenarios where the network is available, weak, or unavailable. 1372 13732. Do not perform time-consuming operations in the application lifecycle function. 1374
