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