## 简介

用户在使用应用时，如果出现点击无反应或应用无响应等情况，并且持续时间超过一定限制，就会被定义为应用冻屏（AppFreeze），即应用无响应。系统会检测应用无响应，并生成AppFreeze日志，供应用开发者分析。

说明

本文仅适用于Stage模型下的应用。在根据本文分析日志前，开发者需要具备JS在系统中运行情况、C++程序堆栈信息的相关基础知识，并对应用相关的子系统有一定了解。

## 检测原理

目前应用冻屏检测从以下维度检测，了解其原理有助于应用开发者定位和分析AppFreeze故障。

注意

AppFreeze检测仅对[release版本应用](https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/performance-analysis-kit-terminology#release版本应用)生效，对[debug版本应用](https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/performance-analysis-kit-terminology#debug版本应用)不生效。

展开

| 故障类型 | 说明 |
| --- | --- |
| THREAD\_BLOCK\_6S | 应用主线程卡死超时 |
| APP\_INPUT\_BLOCK | 用户输入响应超时 |

当应用发生上述故障时，为了保证可恢复，会杀死应用。并上报应用冻屏事件，可通过HiAppEvent订阅[应用冻屏事件](https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/hiappevent-watcher-freeze-events)。

### THREAD\_BLOCK\_6S 应用主线程卡死超时

**概述**：发生该故障，表示当前应用主线程有卡死或者执行任务过多的情况，影响应用的流畅度和体验。

**检测原理**：应用的watchdog线程定期向主线程插入判活检测任务。如果判活检测超过3s未被执行，将上报THREAD\_BLOCK\_3S告警事件；如果超过6s仍未被执行，将上报THREAD\_BLOCK\_6S主线程卡死事件。两个事件匹配生成THREAD\_BLOCK的应用无响应日志。

检测原理如下图：

**图1**

![](https://contentcenter-vali-drcn.dbankcdn.cn/pvt_2/DeveloperAlliance_scene_100_1/6a/v3/sKczQF-1RBOnoBpvkpadEw/zh-cn_image_0000002571171979.png?HW-CC-KV=V1&HW-CC-Date=20260414T050329Z&HW-CC-Expire=86400&HW-CC-Sign=D96C31E61BBEF75058823572EC643A97AC9B3BDBEA295E6C80FBA3C4A3C929E1)

### APP\_INPUT\_BLOCK 用户输入响应超时

**概述**：该故障是指点击事件超过5s未得到响应。

**检测原理**：用户点击应用时，输入系统会向应用侧发送点击事件；应用侧的响应反馈回执超时，则上报该故障。

检测原理如下图：

**图2**

![](https://contentcenter-vali-drcn.dbankcdn.cn/pvt_2/DeveloperAlliance_scene_100_1/ba/v3/ufeQMRh-Qh6N8iQkE0SiOg/zh-cn_image_0000002540771638.png?HW-CC-KV=V1&HW-CC-Date=20260414T050329Z&HW-CC-Expire=86400&HW-CC-Sign=0661CE7C98FEC67FFA1EC335CBC18FEC548F03A04B72D7E3C3C310AB8D5A03C9)

## 日志获取

应用冻屏日志和进程崩溃日志一致，都是由Faultlogger模块进行管理，可通过以下方式获取：

**方式一：通过DevEco Studio获取日志**

DevEco Studio会收集设备/data/log/faultlog/faultlogger/路径下的进程崩溃故障日志到FaultLog下，根据进程名和故障时间分类显示。获取日志的方法参见：[DevEco Studio使用指南-FaultLog](https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/ide-fault-log)。

**方式二：通过HiAppEvent接口订阅**

HiAppEvent给开发者提供了故障订阅接口，详见[HiAppEvent介绍](https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/hiappevent-intro)。参考[订阅应用冻屏事件（ArkTS）](https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/hiappevent-watcher-freeze-events-arkts)或[订阅应用冻屏事件（C/C++）](https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/hiappevent-watcher-freeze-events-ndk)完成应用冻屏事件订阅，并通过事件的[external\_log](https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/hiappevent-watcher-freeze-events#事件字段说明)字段读取故障日志文件内容。

**方式三：通过hdc获取日志，需打开开发者选项**

在开发者选项打开的情况下，开发者可以通过hdc file recv /data/log/faultlog/faultlogger D:\命令导出故障日志到本地，故障日志文件名格式为appfreeze-进程名-进程UID-毫秒级时间.log。

## 日志规格

应用冻屏（AppFreeze）问题需要结合应用冻屏日志和hilog流水日志进行分析。

当前提供一个故障分析示例，请开发者根据具体问题具体分析。

应用冻屏日志主要分以下几个模块信息：

### 日志头部信息

收起

自动换行

深色代码主题

复制

```
1. Generated by HiviewDFX@HarmonyOS
2. ================================================================
3. Device info:HUAWEI Mate 60 Pro
4. Build info:ALN-AL00 6.0.0.328(C00E1R4P3DEVDUlog)
5. Fingerprint:e18a33c12e1361173ec9ac1c93f2bd0c2daa88f03c7f76b228cca14bdc6a21b1
6. Module name:com.samples.freezedebug
7. Version:1.0.0
8. VersionCode:1000000
9. PreInstalled:No
10. Foreground:Yes
11. Pid:13680
12. Uid:20020177
13. Process life time:18s
14. Process Memory(kB):163819(Rss)
15. Device Memory(kB):Total 11679272, Free 3697424, Available 5814272
16. Reason:THREAD_BLOCK_6S
17. appfreeze: com.samples.freezedebug THREAD_BLOCK_6S at 20250628140837
18. DisplayPowerInfo:powerState:UNKNOWN
19. HitraceIdInfo: hitrace_id: a92ab27238f409a, span_id: 1cd61c9, parent_span_id: 3072e, trace_flag: 0
20. Page switch history:
21. 14:08:30:327 /ets/pages/Index:Appfreeze
22. 14:08:28:986 /ets/pages/Index
23. 14:08:26:502 :enters foreground
24. 14:08:07:606 :leaves foreground
25. 14:08:06:246 /ets/pages/Index:Appfreeze
26. 14:08:01:955 :enters foreground
27. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
28. DOMAIN:AAFWK
29. STRINGID:THREAD_BLOCK_6S
30. TIMESTAMP:2025/06/28-14:08:37:360
31. PID:13680
32. UID:20020177
33. PACKAGE_NAME:com.samples.freezedebug
34. PROCESS_NAME:com.samples.freezedebug
35. NOTE: Current fault may be caused by the system's low memory or thermal throttling, you may ignore it and analysis other faults.
36. ***
```

从API version 20开始，当整机资源告警（如整机低内存或热限频）时，会输出NOTE行。出现此行时，开发者可以忽略应用冻屏故障。在之前的API版本中，无论整机资源状态如何，均无此行输出。

从API version 20开始，发生THREAD\_BLOCK\_6S故障时，日志中新增[HiTraceId](https://developer.huawei.com/consumer/cn/doc/harmonyos-references/js-apis-hitracechain#hitraceid)信息打印。HitraceId是HiTraceChain提供的唯一跟踪标识，用于跟踪业务流程调用链。可以协助开发者查看故障时间段内，故障流程的hilog日志，分析日志查看应用的执行状态。

AppFreeze事件（THREAD\_BLOCK\_6S、 APP\_INPUT\_BLOCK）都包含以下几部分信息，具体解释如下：

展开

| 字段 | 说明 |
| --- | --- |
| Reason | 应用无响应原因，与应用无响应检测能力点对应。 |
| PID | 发生故障时的pid。 |
| PACKAGE\_NAME | 应用进程包名。 |
| [Page switch history](https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/cppcrash-guidelines#有页面切换轨迹的故障场景日志规格) | 从API 20开始，维测进程会记录应用切换历史。应用发生故障后，生成的故障文件将包含页面切换历史轨迹。如果维测服务进程出现故障或未缓存切换轨迹，则不包含此字段。 |
| Process life time | 故障进程存活时间。单位：s。  **说明**：从API 22开始支持。 |
| Process Memory(kB) | 故障进程内存占用。  **说明**：从API 22开始支持。 |
| Device Memory(kB) | 整机内存状态。  **说明**：从API 22开始支持。 |

### 日志主干通用信息

收起

自动换行

深色代码主题

复制

```
1. start time: 2025/06/28-14:08:34:318
2. DOMAIN = AAFWK
3. EVENTNAME = THREAD_BLOCK_3S
4. TIMESTAMP = 2025/06/28-14:08:34:310
5. PID = 13680
6. UID = 20020177
7. TID = 13680
8. PACKAGE_NAME = com.samples.freezedebug
9. PROCESS_NAME = com.samples.freezedebug
10. eventLog_action = ffrt,t,GpuStack,cmd:m,hot
11. eventLog_interval = 10
12. MSG =
13. Fault time:2025/06/28-14:08:34
14. App main thread is not response!
15. Main handler dump start time: 2025-06-28 14:08:34.067
16. mainHandler dump is:
17. EventHandler dump begin curTime: 2025-06-28 14:08:34.067
18. Event runner (Thread name = , Thread ID = 13680) is running
19. Current Running: start at 2025-06-28 14:08:27.354, Event { send thread = 13680, send time = 2025-06-28 14:08:22.353, handle time = 2025-06-28 14:08:27.353, trigger time = 2025-06-28 14:08:27.354, task name = uv_timer_task, caller = [ohos_loop_handler.cpp(OnTriggered:72)] }
20. History event queue information:
21. No. 0 : Event { send thread = 13856, send time = 2025-06-28 14:08:22.336, handle time = 2025-06-28 14:08:22.336, trigger time = 2025-06-28 14:08:22.336, completeTime time = 2025-06-28 14:08:22.337, priority = VIP, task name = MMITask, caller = [deamon_io_waiter.cpp(HandleFileDescriptorEvent:225)] }
22. ...
23. No. 31 : Event { send thread = 13856, send time = 2025-06-28 14:08:22.330, handle time = 2025-06-28 14:08:22.380, trigger time = 2025-06-28 14:08:22.330, completeTime time = 2025-06-28 14:08:22.331, priority = VIP, task name = vSyncTask, caller = [deamon_io_waiter.cpp(PostTaskForVsync:159)] }
24. VIP priority event queue information:
25. No.1 : Event { send thread = 13843, send time = 2025-06-28 14:08:31.066, handle time = 2025-06-28 14:08:31.066, id = 1, caller = [watchdog.cpp(Timer:233)] }
26. No.2 : Event { send thread = 13843, send time = 2025-06-28 14:08:34.067, handle time = 2025-06-28 14:08:34.067, id = 1, caller = [watchdog.cpp(Timer:233)] }
27. Total size of VIP events : 2
28. Immediate priority event queue information:
29. Total size of Immediate events : 0
30. High priority event queue information:
31. Total size of High events : 0
32. Low priority event queue information:
33. Total size of Low events : 0
34. Idle priority event queue information:
35. Total size of Idle events : 0
36. Total event size : 2
```

AppFreeze事件（THREAD\_BLOCK\_6S、 APP\_INPUT\_BLOCK）都包含以下几部分信息，具体解释如下：

展开

| 主要信息字段 | 说明 |
| --- | --- |
| EVENTNAME | 组成卡死检测事件。 |
| TIMESTAMP | 发生故障时上报事件的时刻，可以根据应用无响应检测能力点中说明的超时时间，在相应hilog流水日志中缩小查看日志的时间范围。 |
| PID | 发生故障时候的pid。 |
| UID | 发生故障时候的uid。 |
| TID | 发生故障时候的tid。 |
| PACKAGE\_NAME | 应用进程包名。 |
| PROCESS\_NAME | 应用进程名。 |
| MSG | 发生故障时间及EventHandler信息。 |

EventHandler信息，具体解释如下：

dump信息组成结构：

展开

| 主要信息字段 | 说明 |
| --- | --- |
| EventHandler dump begin curTime | 获取dump信息时间。 |
| Event runner | EventHandler对应的线程名和线程号。 |
| Current Running | 当前正在执行的完整任务信息。 |
| History event queue information | 历史执行任务信息。 |
| VIP priority event queue information | VIP级任务队列信息。 |
| Immediate priority event queue information | 立即执行任务队列信息。 |
| High priority event queue information | 高优先级任务队列信息。 |
| Low priority event queue information | 低优先级任务队列信息。 |
| Idle priority event queue information | 挂起任务队列信息。 |

任务组成部分：

展开

| 主要信息字段 | 说明 |
| --- | --- |
| send thread | 提交任务线程号。 |
| send time | 提交任务时间。 |
| task name | 任务队列中的任务名。 |
| priority | 任务优先级。 |
| caller | 任务提交方法。 |
| handle time | 任务预期执行时间。与实际的任务执行时间（trigger time）可能存在偏差 |
| trigger time | 任务执行时间。 |
| completeTime time | 任务执行完成时间（如果没有打印则表示该任务未执行完成）。 |

说明

EventHandler信息中，开发者只需重点关注EventHandler dump begin curTime，trigger time和completeTime time时间即可。

EventHandler信息详细指导可参考：[查看eventHandler信息](https://developer.huawei.com/consumer/cn/doc/best-practices/bpta-stability-app-freeze-way#section190014865618)

### 堆栈信息

显示故障进程堆栈信息。

收起

自动换行

深色代码主题

复制

```
1. Tid:13680, Name:les.freezedebug
2. #00 pc 000000000000186c [shmm](__kernel_gettimeofday+72)
3. #01 pc 00000000001d887c /system/lib/ld-musl-aarch64.so.1(gettimeofday+40)(f1a940981720250b920ee26d2d76af5b)
4. #02 pc 000000000058fb5c /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::builtins::BuiltinsDate::Now(panda::ecmascript::EcmaRuntimeCallInfo*)+48)(0f1928b77d36d27edb5512bd89806a6f)
5. #03 pc 0000000000cff5dc /system/lib64/module/arkcompiler/stub.an(RTStub_PushCallArgsAndDispatchNative+40)
6. #04 pc 000000000036aaf4 /system/lib64/module/arkcompiler/stub.an(BCStub_HandleCallthis0Imm8V8StwCopy+380)
7. #05 at wait15s (entry/src/main/ets/pages/Index.ets:16:10)
8. #06 pc 000000000026b1dc /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::InterpreterAssembly::Execute(panda::ecmascript::EcmaRuntimeCallInfo*)+536)(0f1928b77d36d27edb5512bd89806a6f)
9. #07 pc 000000000096b188 /system/lib64/platformsdk/libark_jsruntime.so(panda::FunctionRef::CallForNapi(panda::ecmascript::EcmaVM const*, panda::JSValueRef*, panda::JSValueRef* const*, int)+1432)(0f1928b77d36d27edb5512bd89806a6f)
10. #08 pc 000000000006b7a4 /system/lib64/platformsdk/libace_napi.z.so(napi_call_function+212)(eaa639519e67e8495ca596293a0d33cd)
11. #09 pc 000000000000b17c /system/lib64/platformsdk/libtimer.z.so(OHOS::JsSysModule::Timer::TimerCallback(uv_timer_s*) (.cfi)+528)(764291289e89523cdbe9c3c78c1cca35)
12. #10 pc 0000000000013ea8 /system/lib64/platformsdk/libuv.so(uv__run_timers+68)(9e7eb59ca1a45f4230b641a7c940a20b)
13. #11 pc 000000000001a344 /system/lib64/platformsdk/libuv.so(uv_run+376)(9e7eb59ca1a45f4230b641a7c940a20b)
14. #12 pc 00000000000895a8 /system/lib64/platformsdk/libruntime.z.so(OHOS::AbilityRuntime::OHOSLoopHandler::OnTriggered()+140)(daf29e377c47e3e26282e745dd1b3488)
15. #13 pc 0000000000089b4c /system/lib64/platformsdk/libruntime.z.so(std::__h::__function::__func<OHOS::AbilityRuntime::OHOSLoopHandler::OnTriggered()::$_0, std::__h::allocator<OHOS::AbilityRuntime::OHOSLoopHandler::OnTriggered()::$_0>, void ()>::operator()() (.9efded9864dc55830f61b3b92d59beab)+52)(daf29e377c47e3e26282e745dd1b3488)
16. #14 pc 000000000001ff6c /system/lib64/chipset-sdk-sp/libeventhandler.z.so(OHOS::AppExecFwk::(anonymous namespace)::EventRunnerImpl::ExecuteEventHandler(std::__h::unique_ptr<OHOS::AppExecFwk::InnerEvent, void (*)(OHOS::AppExecFwk::InnerEvent*)>&)+2228)(475713336c2720d372d5aeb99dda5f9f)
17. #15 pc 000000000001a7d8 /system/lib64/chipset-sdk-sp/libeventhandler.z.so(OHOS::AppExecFwk::(anonymous namespace)::EventRunnerImpl::Run()+648)(475713336c2720d372d5aeb99dda5f9f)
18. #16 pc 000000000003f5f4 /system/lib64/chipset-sdk-sp/libeventhandler.z.so(OHOS::AppExecFwk::EventRunner::Run()+404)(475713336c2720d372d5aeb99dda5f9f)
19. #17 pc 00000000000a50f0 /system/lib64/platformsdk/libappkit_native.z.so(OHOS::AppExecFwk::MainThread::Start()+504)(e794b687fdf46631ae5144eba250f8c0)
20. #18 pc 0000000000005278 /system/lib64/appspawn/appspawn/libappspawn_ace.z.so(RunChildProcessor(AppSpawnContent*, AppSpawnClient*)+568)(143c05087e9460f0fd794b9dce5dec29)
21. #19 pc 000000000000baa8 /system/bin/appspawn(AppSpawnChild+648)(25ab88f6e04b1d2c8feb5d3eebfb4664)
22. #20 pc 0000000000016478 /system/bin/appspawn(ProcessSpawnReqMsg+3260)(25ab88f6e04b1d2c8feb5d3eebfb4664)
23. #21 pc 0000000000013aac /system/bin/appspawn(OnReceiveRequest+724)(25ab88f6e04b1d2c8feb5d3eebfb4664)
24. #22 pc 0000000000017844 /system/lib64/chipset-sdk-sp/libbegetutil.z.so(HandleRecvMsg_+384)(a9ddb8b84cc09183cc6bd2e5bb875f30)
25. #23 pc 000000000001715c /system/lib64/chipset-sdk-sp/libbegetutil.z.so(HandleStreamEvent_+152)(a9ddb8b84cc09183cc6bd2e5bb875f30)
26. #24 pc 000000000001444c /system/lib64/chipset-sdk-sp/libbegetutil.z.so(ProcessEvent+380)(a9ddb8b84cc09183cc6bd2e5bb875f30)
27. #25 pc 0000000000013edc /system/lib64/chipset-sdk-sp/libbegetutil.z.so(RunLoop_.llvm.16927440879641410339+656)(a9ddb8b84cc09183cc6bd2e5bb875f30)
28. #26 pc 0000000000010dcc /system/bin/appspawn(AppSpawnRun+212)(25ab88f6e04b1d2c8feb5d3eebfb4664)
29. #27 pc 000000000000eb90 /system/bin/appspawn(main+728)(25ab88f6e04b1d2c8feb5d3eebfb4664)
30. #28 pc 00000000000a9804 /system/lib/ld-musl-aarch64.so.1(libc_start_main_stage2+84)(f1a940981720250b920ee26d2d76af5b)
```

大部分情况下，THREAD\_BLOCK\_6S、APP\_INPUT\_BLOCK故障的堆栈信息，可以协助开发者定位到异常代码。

其他情况下（比如瞬时栈场景），由于主线程繁忙等问题，导致获取堆栈信息延迟，无法及时捕获到异常代码段，堆栈的栈顶信息并非开发者期望获取的结果。

为解决上述问题，从API version 21开始，支持获取AppFreeze的增强日志。协助开发者定位问题，详见[AppFreeze（应用冻屏）增强日志实现原理](/consumer/cn/doc/harmonyos-guides/appfreeze-guidelines#实现原理)。

说明

在整机高负载情况（如CPU高负载）下，采用低开销方式获取调用栈时，可能损失函数名信息。

从API version 21开始，出现'Failed to dump normal stacktrace'字样时，系统采取轻量化的frame pointer回溯模式。栈回溯可能中断在非使能frame pointer的库（在GCC编译使用 -fomit-frame-pointer 选项时，编译产物不使能frame pointer），以及受轻量化的限制，单个线程的回栈层数不会超过50层。

### 对端信息（与当前故障进程通信的进程信息）

（1）BinderCatcher：显示进程间通信的调用信息及等待时间过长的情况。

收起

自动换行

深色代码主题

复制

```
1. PeerBinderCatcher -- pid==13680
2. BinderCatcher --
3. 13840:14102 to 901:4079 code 16 wait:0.25653125 s frz_state:3,  ns:-1:-1 to -1:-1, debug:13840:14102 to 901:4079, active_code:0, active_thread=0, pending_async_proc=0
4. 3712:3712 to 13967:14076 code d2 wait:0.703385417 s frz_state:3,  ns:-1:-1 to -1:-1, debug:3712:3712 to 13967:14076, active_code:0, active_thread=0, pending_async_proc=0
5. 1733:2285 to 3712:3712 code b wait:1.365925521 s frz_state:3,  ns:-1:-1 to -1:-1, debug:1733:2285 to 3712:3712, active_code:0, active_thread=0, pending_async_proc=0
6. ...
7. pid context     request started max ready   free_async_space
8. 14072   binder  0   2   16  3   520192
9. 14103   binder  0   4   16  6   520192
10. 13967   binder  0   3   16  3   520192
11. 13878   binder  0   2   16  3   520192
12. 13840   binder  0   2   16  3   520192
13. 13863   binder  0   1   16  3   520192
14. 13680   binder  0   2   16  3   520192
15. 13770   binder  0   3   16  5   520192
16. 13749   binder  0   3   16  5   520192
17. ...
```

进程间通信调用信息解释如下：

展开

| 主要信息字段 | 说明 |
| --- | --- |
| xxx:xxx to xxx:xxx | 客户端进程号、线程号 to 服务端进程号、线程号。其中async表示异步，无async表示同步。 |
| code | 客户端和服务端达成一致约束的业务码。 |
| wait | 通信等待时长。 |
| frz\_state | 进程冻结状态。  -1 未知；  1 默认；  2 正在向用户态发送binder状态信息；  3 走到了binder接收线程。 |
| ns | 客户端进程号、线程号 to 服务端进程号、线程号（非卓易通内进程显示-1）。 |
| debug | IPC通信双方的信息补充。 |
| active\_code | 正在处理的异步消息code。 |
| active\_thread | 处理这个异步消息的线程。 |
| pending\_async\_proc | 被这个异步消息阻塞的进程。 |
| pid | 进程PID。 |
| context | 通信方式。 |
| request | 请求申请的IPC线程数量。 |
| started | 已经申请启动的IPC线程数量。 |
| max | 可以申请的最大IPC线程数量。 |
| ready | 空闲IPC线程。 |
| free\_async\_space | 空闲异步空间，用于观测异步信息阻塞。 |

（2）PeerBinder Stacktrace：故障进程相关的对端进程有卡死，会抓取对端的进程堆栈，即与当前进程通信的进程堆栈

收起

自动换行

深色代码主题

复制

```
1. Tid:48841, Name:xxx
2. #00 pc 000000000016adf4 /system/lib/ld-musl-aarch64.so.1
3. #01 pc 000000000001c0d4 /system/lib64/chipset-sdk-sp/libeventhandler.z.so
4. #02 pc 000000000001a7f4 /system/lib64/chipset-sdk-sp/libeventhandler.z.so
5. #03 pc 000000000003f5f4 /system/lib64/chipset-sdk-sp/libeventhandler.z.so
6. #04 pc 00000000000a50f0 /system/lib64/platformsdk/libappkit_native.z.so
7. #05 pc 0000000000005278 /system/lib64/appspawn/appspawn/libappspawn_ace.z.so
8. #06 pc 000000000000baa8 /system/bin/appspawn
9. #07 pc 0000000000016478 /system/bin/appspawn
10. #08 pc 0000000000013aac /system/bin/appspawn
11. #09 pc 0000000000017844 /system/lib64/chipset-sdk-sp/libbegetutil.z.so
12. #10 pc 000000000001715c /system/lib64/chipset-sdk-sp/libbegetutil.z.so
13. #11 pc 000000000001444c /system/lib64/chipset-sdk-sp/libbegetutil.z.so
14. #12 pc 0000000000013edc /system/lib64/chipset-sdk-sp/libbegetutil.z.so
15. #13 pc 0000000000010dcc /system/bin/appspawn
16. #14 pc 000000000000eb90 /system/bin/appspawn
17. #15 pc 00000000000a9804 /system/lib/ld-musl-aarch64.so.1
18. #16 pc 000000000000b754 /system/bin/appspawn
```

### CPU信息

整机CPU信息及解释如下：

收起

自动换行

深色代码主题

复制

```
1. Load average: 14.3 / 12.9 / 11.4; the cpu load average in 1 min, 5 min and 15 min
2. CPU usage from 2025-06-28 14:08:36 to 2025-06-28 14:08:37
3. Total: 22.45%; User Space: 13.64%; Kernel Space: 8.81%; iowait: 0.33%; irq: 0.07%; idle: 77.15%
4. Details of Processes:
5. PID   Total Usage      User Space    Kernel Space    Page Fault Minor    Page Fault Major    Name
6. 13680      8.86%           8.31%          0.55%            4711                6637            com.samples.freezedebug
7. 644        2.55%           1.40%          1.15%          210104                7391            hiview
8. 600        0.89%           0.78%          0.10%           60192                 514            hilogd
9. 1685       0.53%           0.31%          0.22%          879838               59636            foundation
```

展开

| 主要信息字段 | 说明 |
| --- | --- |
| PID | 进程PID。 |
| Total Usage | CPU使用率，Total Usage = User Space+Kernel Space。 |
| User Space | 用户态使用率。 |
| Kernel Space | 内核态使用率。 |
| Page Fault Minor | 次要缺页错误。 |
| Page Fault Major | 主要缺页错误。 |
| Name | 进程名。 |

### 内存信息

收起

自动换行

深色代码主题

复制

```
1. Get freeze memory start time: 2025-06-28 14:08:37.112
2. some avg10=56.81 avg60=56.81 avg300=56.81 total=56
3. full avg10=56.81 avg60=56.81 avg300=56.81 total=56
4. ...
5. ReclaimAvailBuffer:                    4676608 kB
6. ...
```

整机内存信息如上所示，其中ReclaimAvailBuffer为整机剩余可用内存，主要用于确认是否是低内存问题。

## 日志差异性信息

**APP\_INPUT\_BLOCK 用户输入响应超时**

收起

自动换行

深色代码主题

复制

```
1. Generated by HiviewDFX@HarmonyOS
2. ================================================================
3. ...
4. Reason:APP_INPUT_BLOCK
5. appfreeze: com.samples.freezedebug APP_INPUT_BLOCK at 20251129123745
6. Wait Event(430) to be marked exceed 8000ms, lastDispatchEvent(430), lastProcessEvent(429), lastMarkedEvent(428)
7. DisplayPowerInfo:powerState:AWAKE
8. ...
```

从API version 22开始，发生APP\_INPUT\_BLOCK故障时，日志中会同步输出多模点击输入（包含鼠标、键盘、触控板及触屏等输入方式）超时事件（Wait Event）。该事件信息中包含事件id，事件检测超时阈值，及前置事件id。

事件检测超时阈值：log版本为8000毫秒，nolog版本为5000毫秒。

前置事件中包含：lastDispatchEvent为上次分发的事件；lastProcessEvent为上次处理的事件；lastMarkedEvent为上次标记的事件。

在上述示例中，上次分发的事件是430，上次处理的事件是429，上次标记的事件是428，表明430事件已分发完毕，在处理环节，已超时8000毫秒。此日志可以用于APP\_INPUT\_BLOCK事件的简单定界，帮助问题分析。

## AppFreeze（应用冻屏）增强日志信息

从API version 21开始，支持获取AppFreeze的增强日志。该日志通过采集整机及主线程的运行负载，并抓取多份主线程调用栈，帮助开发者分析问题根源。相比原有日志，AppFreeze的增强日志主要解决了以下两个不足：

1. 难以定位故障期间的主线程热点。
2. 缺乏对主线程繁忙或阻塞的资源层面分析。

### 实现原理

生成AppFreeze增强日志的流程分为以下两个阶段，具体如下：

1. 应用进程在运行时发生THREAD\_BLOCK\_3S时，会开启采集主线程调用栈流程，记录当前时刻的一些CPU信息。
2. 应用进程在运行时发生THREAD\_BLOCK\_6S或APP\_INPUT\_BLOCK时，会停止上述流程的采集主线程调用栈流程，并计算周期内的CPU信息。一般情况下，会抓取1~10次堆栈日志。

   说明

   由于应用冻屏事件的采样栈会与[MAIN\_THREAD\_JANK](https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/hiappevent-watcher-mainthreadjank-events)冲突，如果应用接入MAIN\_THREAD\_JANK的setEventConfig接口自定义配置采集堆栈的个数，应用冻屏事件的采集堆栈的会与应用当前配置的采集堆栈的个数一致。

   APP\_INPUT\_BLOCK故障有增强日志的前提是：先发生THREAD\_BLOCK\_3S。

### 日志获取

开发者可通过以下方式获取Appfreeze增强日志路径：

**方式一：通过HiAppEvent接口订阅**

应用需要在AppScope/app.json5文件中配置如下环境变量：

收起

自动换行

深色代码主题

复制

```
1. "appEnvironments": [
2. {
3. "name": "DFX_APPFREEZE_LOG_OPTIONS",
4. "value": "mainthread_sampling:enable"
5. }
6. ]
```

HiAppEvent给开发者提供了故障订阅接口，开发者可以使用HiAppEvent监听应用冻屏事件，获取文件内容，详见[应用冻屏事件介绍](https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/hiappevent-watcher-freeze-events)。参考[订阅应用冻屏事件（ArkTS）](https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/hiappevent-watcher-freeze-events-arkts)或[订阅应用冻屏事件（C/C++）](https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/hiappevent-watcher-freeze-events-ndk)完成应用冻屏事件订阅。

开发者可以通过事件的[external\_log](https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/hiappevent-watcher-freeze-events#事件字段说明)字段读取应用冻屏事件生成的故障文件和应用冻屏事件的增强日志文件。增强日志文件的命名与应用冻屏事件生成的故障文件名称格式相同。

external\_log是字符串数组，第一个元素为应用冻屏事件生成的故障文件路径；第二个元素为应用冻屏事件生成的增强日志文件路径。

**方式二：通过hdc获取日志，需打开开发者选项**

在开发者选项打开的情况下，开发者可以通过“hdc file recv /data/log/faultlog/freeze\_ext D:\”命令导出故障日志到本地，故障日志文件名格式为：freeze-cpuinfo-ext-进程名-进程UID-毫秒级时间。

### 日志规格

增强日志的信息头字段如下：

展开

| 字段 | 描述 | 起始API版本 |
| --- | --- | --- |
| TimeStamp | 日志生成时间。 | 21 |
| Module name | 故障模块名。 | 21 |

增强日志的CPU总体耗时信息字段如下：

展开

| 字段 | 描述 | 起始API版本 |
| --- | --- | --- |
| ProcessCpuTime | 统计周期内，进程运行时间。 | 21 |
| DeviceRuntime | 统计周期内，设备所有CPU的运行时间。 | 21 |
| Tid | 线程号。 | 21 |
| StartTime | 统计开始时间。 | 21 |
| EndTime | 统计结束时间。 | 21 |
| StaticsDuration | 统计持续时间。 | 21 |
| CpuTime | 统计周期内，主线程运行时间。 | 21 |
| SyncWaitTime | 主线程等待时间。 | 21 |
| OptimalCpuTime | 统计周期内，主线程最优负载运行时间（使用最大核的最高算力运行）。 | 21 |
| SupplyAvailableTime | 调度可优化时间。如果值较小，说明主线程繁忙，需要开发者考虑优化主线程的任务。 | 21 |

增强日志的堆栈信息字段如下：

展开

| 字段 | 描述 | 起始API版本 |
| --- | --- | --- |
| SnapshotTime | 本次抓取主线程堆栈的时间。 | 21 |
| ThreadInfos Tid | 线程号。 | 21 |
| Name | 线程名。 | 21 |
| Stack | 主线程调用栈。 | 21 |
| SubmitterStacktrace | 任务提交者调用栈。 | 21 |

### 增强日志规格

本节主要介绍增强日志的一般日志规格，以下是一份Appfreeze增强日志的核心内容。可以使用[聚类脚本](/consumer/cn/doc/harmonyos-guides/appfreeze-guidelines#聚类脚本说明)提取主线程堆栈关键信息，提高问题定位效率及准确性。

收起

自动换行

深色代码主题

复制

```
1. Generated by HiviewDFX @HarmonyOS
2. ===============================================================
3. TimeStamp: 2021-01-01 20:06:01.175  <- 日志生成时间
4. Module name: com.example.freeze   <- 模块名

6. #Basic Concepts   <- CPU时间注释
7. T1:  StaticsDuration, EndTime - StartTime.
8. T2:  CpuTime              --Time that spend on CPU.
9. T3:  SyncWaitTime         --SleepingTime + Runnable Time, etc.
10. T4:  OptimalCpuTime       --run the thread at the max Core's max cpu capacity.
11. T5:  SupplyAvailableTime  --T2 - T4. Time can be optimized by scheduling.
12. Equation:  T1 = T2 + T3. T2 = T4 + T5.
13. |-----------------------------------StaticsDuration-----------------------------------|.
14. |-------------------------CpuTime----------------------|--------SyncWaitTime----------|.
15. |----OptimalCpuTime----|------SupplyAvailableTime------|--------SyncWaitTime----------|.

17. #Basic Statistical Infomation  <- CPU基本统计信息
18. ProcessCpuTime: 0 ms  <- 统计周期内，进程运行时间
19. DeviceRuntime: 0 ms  <- 统计周期内，设备所有CPU的运行时间
20. Tid: 2320  <- 故障主线程号
21. StartTime: 2021-01-01 20:05:58:177  <- 统计开始时间
22. EndTime: 2021-01-01 20:06:01:172  <- 统计结束时间
23. StaticsDuration: 2995 ms  <- 统计持续时间
24. CpuTime: 0 ms  <- 统计周期内，主线程运行时间
25. SyncWaitTime: 2995 ms  <- 主线程等待时间
26. OptimalCpuTime: 0 ms  <- 统计周期内，主线程最优负载运行时间（使用最大核的最高算力运行）
27. SupplyAvailableTime: 0 ms  <- 调度可优化时间

29. #CpuFreq Usage (usage >=1%)  <- 当CPU单个频点使用率>=1%时，这些频点及频点的使用率就会被列出来。
30. start time: 2021-01-01 20:06:00:888  <- 计算CPU使用率开始时间
31. cpu0 Usage 23.5%, 1430MHZ 21.04%  <- cpu0的总使用率，cpu0单个频点的使用率（在1430MHZ频点下的使用率）
32. cpu1 Usage 23.5%, 1430MHZ 21.04%
33. cpu2 Usage 23.5%, 1430MHZ 21.04%
34. cpu3 Usage 23.5%, 1430MHZ 21.04%
35. .......
36. end time: 2021-01-01 20:06:00:888  <- 计算CPU使用率结束时间
37. #ThreadInfos Tid: 2204, Name: com.example.freeze  <- 故障线程号，线程名
38. SnapshotTime:2021-01-01-20-05-58.292875  <- 获取主线程的时间
39. #00 pc 00000000000015b8 [shmm](__kernel_gettimeofday+72) <- 主线程调用栈
40. #01 pc 00000000001d7e44 /system/lib64/ld-musl-aarck64.so.1(clock_gettime+48)(f8a0616c89b184992d0e8883cc78f638)
41. #02 pc 00000000001d9f20 /system/lib64/ld-musl-aarck64.so.1(time+32)(f8a0616c89b184992d0e8883cc78f638)
42. #03 pc 0000000000007e2c /data/storage/el1/bundle/libs/arm64/libsample.so(WaitSomeTime()+76)(8b74cdc906ea6b2eba95d891bc91c72a)
43. #04 pc 0000000000009b2c /data/storage/el1/bundle/libs/arm64/libsample.so(8b74cdc906ea6b2eba95d891bc91c72a)
44. #05 pc 00000000000a0500 /system/lib64/platformsdk/libruntime.z.so(c2f75213ee12fdf08da323fe546923ff)
45. #06 pc 0000000000017b04 /system/lib64/chipset-sdk-sp/libeventhandler.z.so(366b4d7f2eba693ad06f14469b08943b)
46. #07 pc 0000000000016f38 /system/lib64/chipset-sdk-sp/libeventhandler.z.so(366b4d7f2eba693ad06f14469b08943b)
47. #08 pc 000000000003e160 /system/lib64/chipset-sdk-sp/libeventhandler.z.so(OHOS::AppExecFwk::EventRunner::Run()+396)(366b4d7f2eba693ad06f14469b08943b)
48. .......
49. ========SubmitterStacktrace======== <- 任务提交者调用栈(最多抓取16层调用栈)
50. #00 pc 0000000000013108 /system/lib64/platformsdk/libuv.so(uv_queue_work+292)(366b4d7f2eba693ad06f14469b08943b)
51. #01 pc 0000000000008cdc /data/storage/el1bundle/libs/arm64/libsample.so(8b74cdc906ea6b2eba95d891bc91c72a)
52. #02 pc 000000000005ae00 /system/lib64/platformsdk/libace_napi.z.so(panda::JSValueRef ArkNativeFunctionCallBack<true>(panda::JsiRuntimeCallInfo*)+272)(bc1c64aabbe5c7d4db2282a6137443e1)
53. #03 pc 0000000000de3efc /system/lib64/module/arkcompiler/stub.an(RTStub_PushCallArgsAndDispatchNative+44)
54. #04 pc 0000000000448dd4 /system/lib64/module/arkcompiler/stub.an(BCStub_HandleCallthis0Imm8V8StwCopy+372)
55. #05 at anonymous (sample|sample|1.0.0|src/main/ets/pages/Index.ts:381:36)
56. #06 pc 00000000001e5c8c /system/lib64/platformsdk/libark_jsruntime.so(ce0b05d90b9fae02e7abf8e9f1e5a0f3)
57. .......

59. SnapshotTime:2021-01-01-20-05-58.549685
60. #00 pc 00000000000015b8 [shmm](__kernel_gettimeofday+72)
61. #01 pc 00000000001d7e44 /system/lib64/ld-musl-aarck64.so.1(clock_gettime+48)(f8a0616c89b184992d0e8883cc78f638)
62. #02 pc 00000000001d9f20 /system/lib64/ld-musl-aarck64.so.1(time+32)(f8a0616c89b184992d0e8883cc78f638)
63. #03 pc 0000000000007e2c /data/storage/el1/bundle/libs/arm64/libsample.so(WaitSomeTime()+76)(8b74cdc906ea6b2eba95d891bc91c72a)
64. #04 pc 0000000000009b2c /data/storage/el1/bundle/libs/arm64/libsample.so(8b74cdc906ea6b2eba95d891bc91c72a)
65. #05 pc 00000000000a0500 /system/lib64/platformsdk/libruntime.z.so(c2f75213ee12fdf08da323fe546923ff)
66. .......
67. ========SubmitterStacktrace========
68. #00 pc 0000000000013108 /system/lib64/platformsdk/libuv.so(uv_queue_work+292)(366b4d7f2eba693ad06f14469b08943b)
69. #01 pc 0000000000008cdc /data/storage/el1bundle/libs/arm64/libsample.so(8b74cdc906ea6b2eba95d891bc91c72a)
70. #02 pc 000000000005ae00 /system/lib64/platformsdk/libace_napi.z.so(panda::JSValueRef ArkNativeFunctionCallBack<true>(panda::JsiRuntimeCallInfo*)+272)(bc1c64aabbe5c7d4db2282a6137443e1)
71. #03 pc 0000000000de3efc /system/lib64/module/arkcompiler/stub.an(RTStub_PushCallArgsAndDispatchNative+44)
72. #04 pc 0000000000448dd4 /system/lib64/module/arkcompiler/stub.an(BCStub_HandleCallthis0Imm8V8StwCopy+372)
73. #05 at anonymous (sample|sample|1.0.0|src/main/ets/pages/Index.ts:381:36)
74. .......
```

**Native栈帧内容说明**

详细说明见[Cpp Crash一般故障场景日志规格](https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/cppcrash-guidelines#一般故障场景日志规格)中的调用栈帧内容说明。

**JS混合栈帧内容说明**

详细说明见[JS Crash异常代码调用栈格式](https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/jscrash-guidelines#异常代码调用栈格式)。

### 增强日志聚类规则

**聚类规则说明**

在一份包含多个应用主线程堆栈（如10份）的日志中，对每份采样栈执行以下操作。

1.过滤系统栈

如需过滤掉系统栈帧（如 /system/lib/...、ld-musl 等）。系统栈帧格式示例：

收起

自动换行

深色代码主题

复制

```
1. # 00 pc 000e8400 /system/lib/ld-musl-arm.so.1(raise+176)(a40044d0acb68107cfc4adb5049c0725)
```

2.保留业务栈

如需保留业务栈帧（以“at”为起始字符，或包含“/data/storage”子串，JS 栈帧默认视为业务栈帧（来自应用代码））。业务栈帧格式示例：

收起

自动换行

深色代码主题

复制

```
1. at onPageShow har1 (har1/src/main/ets/pages/Index.ets:7:13)
```

3.标准化栈帧

定义标准化栈帧的内容，自行去除易变信息（如行号、字节偏移、BuildID），根据实际聚类需求保留聚类的关键信息。

对每一帧业务栈帧，执行以下清洗操作：

（1）Native栈帧标准化

展开

| 原始栈帧内容 | 标准化后栈帧内容 |
| --- | --- |
| # 01 pc 00006e95 /data/crasher\_cpp(DfxCrasher::RaiseSegmentFaultException()+92)(d6cead5be17c9bb7eee2a9b4df4b7626) | /data/crasher\_cpp(DfxCrasher::RaiseSegmentFaultException()+92) |

按以下步骤处理：

a. 提取函数签名部分（括号内的内容，含类名、函数名、参数）；

b. 忽略PC偏移和BuildID；

c. 保留函数完整签名（包括 const、参数类型等，若日志中已解析）。

（2）JS栈帧标准化

展开

| 原始栈帧内容 | 标准化后栈帧内容 |
| --- | --- |
| # 00 at onPageShow (entry|har1|1.0.0|src/main/ets/pages/Index.ts:7:13) | onPageShow (entry|har1|1.0.0|src/main/ets/pages/Index.ts:7:13) |

按以下步骤处理：

a. 去除行号；

b. 保留函数名（如 onPageShow）；

c. 保留文件路径（如 src/main/ets/pages/Index.ts）；

d. 最终生成一个标准化的业务调用栈序列，用于后续聚类分析。

4.生成聚类特征

展开

| 原始采样栈 | 最终聚类特征（调用顺序从上到下） |
| --- | --- |
| # 00 pc 000e8400 /system/lib/ld-musl-arm.so.1(raise+176)(a40044d0...)  # 01 pc 00006e95 /data/crasher\_cpp(DfxCrasher::RaiseSegmentFaultException()+92)(d6ce...)  # 02 pc 00008909 /data/crasher\_cpp(DfxCrasher::ParseAndDoCrash(char const\*) const+612)(d6ce...)  # 03 at onPageShow (entry|har1|1.0.0|src/main/ets/pages/Index.ts:7:13) | /data/crasher\_cpp(DfxCrasher::RaiseSegmentFaultException()+92)  /data/crasher\_cpp(DfxCrasher::ParseAndDoCrash(char const\*) const+612)  at onPageShow (entry|har1|1.0.0|src/main/ets/pages/Index.ts:7:13) |

根据聚类特征直接聚类所有采样栈。

### 聚类脚本说明

该脚本的使用仅限于[AppFreeze增强日志](/consumer/cn/doc/harmonyos-guides/appfreeze-guidelines#增强日志规格)。当日志内容过长、主线程堆栈存在多次重复时，用于提取业务栈聚类信息（业务栈内容、总出现次数及代表性完整堆栈等），更快定位问题。

1.脚本功能

该脚本用于批量处理指定文件夹中的.zip日志文件。按以下步骤处理：

（1）从输入文件夹中读取所有.zip文件中采样栈文件；

（2）自动逐一解压，解析及转换；

（3）将处理结果输出到指定文件夹中。

2.运行方式

收起

自动换行

深色代码主题

复制

```
1. get_all_result(input_dir: str, output_dir: str)
```

展开

| 参数名 | 是否必填 | 类型 | 说明 |
| --- | --- | --- | --- |
| input\_dir | 必填 | 字符串 | 输入文件夹路径，需包含若干.zip日志文件。 |
| output\_dir | 必填 | 字符串 | 输出文件夹路径，脚本会将处理后的结果写入该目录。 |

示例：

收起

自动换行

深色代码主题

复制

```
1. get_all_result(r"D:\log\input", r"D:\log\output")
```

3.输入要求

input\_dir目录下应为若干.zip文件。

不限制文件名，可为嵌套结构（脚本可拓展支持.zip内还有.zip）。

zip文件中必须带采样栈日志文件。

4.输出说明

脚本会在output\_dir中生成处理结果（例如）：

收起

自动换行

深色代码主题

复制

```
1. output_dir/
2. ├─stack_summary.txt
3. ├─ 业务栈聚类.txt
4. └─ 业务栈聚类.xlsx
```

实际输出类型依脚本逻辑而定（解压文件/转换文件/汇总文本/JSON/CSV等）。

5.运行前准备

确保本机或部署环境满足以下条件:

（1）已安装Python 3.x。

（2）已安装脚本依赖（如 os/zipfile/pandas 等）。

（3）output\_dir不存在时脚本会自动创建（若脚本未实现自动创建，请提前建好目录）。

（4）该脚本不支持在DevEco Studio中执行，请在已安装的Python环境下运行该脚本。

6.聚类脚本源码

收起

自动换行

深色代码主题

复制

```
1. import re
2. from collections import Counter, defaultdict
3. import os
4. import pandas as pd
5. import zipfile
6. import glob
7. from pathlib import Path

9. # 日志目录
10. log_dir = r"D:\log\input"  # 改成你日志目录
11. # 输出结果
12. output_file = r"D:\log\stack_summary.txt"
13. # 匹配堆栈行
14. stack_line_pattern = re.compile(r'^\s*(#\d+\s+pc\s+[0-9a-f]+.*|#?\d*\s*at .+)$')


17. # 判断是否是业务栈
18. def is_business_stack(line):
19. line = line.strip()
20. return re.match(r'^(#\d+\s+)?at .+\(.+\)$', line) is not None


23. def process_log_file(path):
24. with open(path, "r", encoding="utf-8", errors='ignore') as f:
25. lines = f.readlines()

27. all_stacks = []
28. current_stack = []
29. for line in lines:
30. if line.startswith("SnapshotTime:"):
31. if current_stack:
32. all_stacks.append(current_stack)
33. current_stack = []
34. elif stack_line_pattern.match(line):
35. # 忽略无关紧要的系统行
36. if re.match(r'#\d+\s+pc\s+[0-9a-f]+$', line.strip()):
37. continue
38. current_stack.append(line.strip())
39. if current_stack:
40. all_stacks.append(current_stack)

42. # 对同一日志的堆栈进行计数
43. stack_counter = Counter()
44. for stack in all_stacks:
45. business_lines = [line for line in stack if is_business_stack(line)]
46. if business_lines:
47. key = "\n".join(business_lines[0:5])
48. else:
49. key = "\n".join(stack)
50. stack_counter[key] += 1

52. # 只保留出现次数大于5的
53. result = {k: v for k, v in stack_counter.items() if v >= 1}
54. return result


57. def remove_lineno(line):
58. return re.sub(r'^#\d+\s+', '', line.strip())


61. def normalize_frame(line: str) -> str:
62. """
63. 去掉无关信息，提取业务栈的关键部分
64. """
65. line = line.strip()
66. # 去掉 "#数字 pc 地址" 或 "#数字 at"
67. line = re.sub(r'^#\d+\s+(pc\s+[0-9a-f]+\s+)?', '', line)
68. # 去掉行号 (:123:1)
69. line = re.sub(r':\d+(:\d+)?', '', line)
70. return line


73. def is_business_frame(line: str) -> bool:
74. """
75. 判断是否是业务栈
76. """
77. return (
78. line.startswith("at ") or
79. "/data/storage/" in line
80. )


83. def unzip_all(src_dir, dest_dir):
84. # 确保目标目录存在
85. os.makedirs(dest_dir, exist_ok=True)

87. # 找到所有 zip 文件
88. zip_files = glob.glob(os.path.join(src_dir, "*.zip"))

90. for zip_path in zip_files:
91. # 以 zip 文件名（去掉扩展名）作为子目录
92. base_name = os.path.splitext(os.path.basename(zip_path))[0]
93. extract_path = os.path.join(dest_dir, base_name)

95. os.makedirs(extract_path, exist_ok=True)

97. # 解压
98. with zipfile.ZipFile(zip_path, "r") as zip_ref:
99. zip_ref.extractall(extract_path)

101. print(f"✅ 解压完成: {zip_path} → {extract_path}")

103. print(f"\n全部解压完成，共 {len(zip_files)} 个 zip 文件。")


106. def get_cluster(input_dir):
107. input_file = os.path.join(input_dir, 'stack_summary.txt')
108. # 统计次数和代表性堆栈
109. cluster_count = defaultdict(int)
110. cluster_sample = {}  # 片段 key -> 代表性完整堆栈

112. current_stack = []
113. current_count = 0

115. with open(input_file, "r", encoding="utf-8") as f:
116. for line in f:
117. line = line.rstrip()
118. if line.startswith("出现次数:"):
119. current_count = int(re.search(r'\d+', line).group())
120. current_stack = []
121. elif line.startswith("=" * 10) or line == "":
122. if current_stack:
123. # 找第一个业务栈
124. business_frame = None
125. for frame in current_stack:
126. norm = normalize_frame(frame)
127. if is_business_frame(norm):
128. business_frame = norm
129. break
130. if business_frame:
131. cluster_count[business_frame] += 1
132. if business_frame not in cluster_sample:  # 保存代表性堆栈
133. cluster_sample[business_frame] = "\n".join(current_stack)
134. current_stack = []
135. else:
136. current_stack.append(line)
137. output_file = os.path.join(input_dir, '业务栈聚类.txt')
138. # 输出到txt
139. with open(output_file, "w", encoding="utf-8") as f:
140. for top_line, total_count in sorted(cluster_count.items(), key=lambda x: x[1], reverse=True):
141. f.write(f"业务栈: {top_line}\n")
142. f.write(f"总出现次数: {total_count}\n")
143. f.write("代表性完整堆栈:\n")
144. f.write(cluster_sample[top_line] + "\n")
145. f.write("-" * 80 + "\n")

147. print(f"业务栈聚类完成，结果输出到 {output_file}")

149. # 输出到excel
150. rows = []
151. for key, count in sorted(cluster_count.items(), key=lambda x: x[1], reverse=True):
152. rows.append({
153. "业务栈片段": key,
154. "总出现次数": count,
155. "代表性完整堆栈": cluster_sample[key]
156. })
157. output_excel = os.path.join(input_dir, '业务栈聚类.xlsx')
158. df = pd.DataFrame(rows)
159. df.to_excel(output_excel, index=False)
160. print(f"业务栈聚类已导出到 {output_excel}")


163. def get_stack_summary(log_dir, output_dir):
164. all_results = {}
165. for root, dirs, files in os.walk(log_dir):
166. for filename in files:
167. if "freeze-cpuinfo-ext" in filename:
168. path = os.path.join(root, filename)
169. result = process_log_file(path)
170. if result:
171. all_results[path] = result
172. folder = Path(output_dir)  #统一转成 Path
173. output_file = folder / 'stack_summary.txt'  #自动拼路径
174. folder.mkdir(parents=True, exist_ok=True)
175. # 输出结果
176. with open(output_file, "w", encoding="utf-8") as f:
177. for log_file, stacks in all_results.items():
178. f.write(f"日志文件: {log_file}\n")
179. for stack_text, count in stacks.items():
180. f.write(f"出现次数: {count}\n")
181. f.write(stack_text + "\n")
182. f.write("=" * 80 + "\n")
183. print(f"处理完成，结果输出到 {output_file}")


186. def get_all_result(log_dir, output_dir):
187. unzip_all(log_dir, log_dir)
188. get_stack_summary(log_dir, output_dir)
189. get_cluster(output_dir)


192. if __name__ == "__main__":
193. get_all_result(r"D:\log\input", r"D:\log\output")
```

[cluster\_script.py](https://gitcode.com/HarmonyOS_Samples/guide-snippets/blob/HarmonyOS-feature-20251117/PerformanceAnalysisKit/Tools/SampleStack/cluster_script.py#L1-L195)