用途：分析 OpenHarmony 图形相关模块的 Sysfreeze/Appfreeze 日志，确认故障类型（SERVICE_BLOCK 或 THREAD_BLOCK），追踪阻塞链，定位进程冻结与线程阻塞的根本原因，输出故障总结、阻塞路径、根因与优化建议。
输入包括 Sysfreeze/Appfreeze 日志、相关源码（code/ 目录）、带符号表的 so 文件（lib.unstripped/ 目录），可选 hilog 与 hilog_kmsg 日志。前置条件为用户环境提供 llvm 工具（llvm-readelf/llvm-addr2line/llvm-objdump 等），并确认日志含两次抓栈信息与 TIMESTAMP、TID 等关键字段。
主要能力：先做基本信息分析，查看 Reason 字段、TIMESTAMP、TID，以及 ReclaimAvailBuffer、ThermalLevel info 等整机资源状态；再进行任务队列分析，比较两次检测的 Current Running 任务与各优先级队列（VIP、Immediate、High、Low、Idle）的提交、执行时间；随后依据两次调用栈做阻塞链跟踪，从 Tid 指定线程开始解栈，识别等锁、信号量、IPC 调用等阻塞模式，递归追溯阻塞源头，IPC 阻塞时结合 BinderCatcher 查找对端线程；如有 hilog 则在故障时间点附近分析异常日志，最后综合生成报告并保存到文档。
解栈命令示例：llvm-addr2line -Cfpie path/to/so offset；注意 ld-musl-xxx.so 即 libc.so。
限制与回退：不适用于纯性能优化问题、无系统级阻塞的应用层逻辑错误、非图形模块调用栈的 freeze 问题，以及日志严重缺失的情形。符号表缺失时无法精确定位代码行号；仅一次抓栈无法判断是否同一任务阻塞；hilog 缺失则仅依赖堆栈与任务队列并在报告中标注；BinderCatcher 缺失时 IPC 分析受限。解栈失败需检查 so 路径、偏移格式并用 llvm-readelf 验证符号表。阻塞链无法闭合时需考虑 IPC 跨进程或内核态阻塞，并说明中断节点与下一步排查方向。禁止跳过解栈、忽略整机资源状态、孤立分析单个线程、信息不足时强行下结论或忽略时间信息。