是拍快照不是拿引用。一次文本变化只拍一次，能拿回调参数就别拍。定位手段：hilog -T C0391A | grep -E "BeforeSSChange|GetStyledString|AfterSSChange"，看 Before 和 After 之间的调用数，>5 就是高风险。

主线程零阻塞：任何涉及文件 IO、网络请求、复杂计算的同步操作，必须使用 taskpool、worker 或异步 API。单例初始化保护：涉及系统底层句柄（如 uv_async_t、pthread_mutex 等）的单例，务必使用 std::call_once 或互斥锁保护，防止多线程竞态条件。句柄生命周期管理：uv_async_t 等句柄与 uv_loop_t 强关联。切勿在多个不同的 uv_l

本原创文章帖发布在点了一下按钮，页面不动了。等打开 Profiler 准备录制，它又恢复了。再点一次，一切正常。排查偶发卡死时，最容易错过的就是这几秒。写代码、操作应用时，如果有监控任务持续监听卡死信号，触发后自动采集日志，就可以事后再查看主线程到底忙在哪儿。appfreeze-dev-analysis 提供了这样的功能：在 CodeAgent 中启动一个持续观察的子任务，检测到卡死信号后抓取 t

jsleak-analysis 的多版本快照对比聚类，本质上是一套排查方法，而不是“跑一下工具”那么简单：• 单快照先聚类，算强引用链，先把弱引用造成的误报排除；• 组内多快照合并，过滤偶发波动，抓住持续存在的问题；• 跨版本“新增 / 增长 / 公共”对比，锁定回归点；• 读懂引用链，找到“断开即释放”的关键一跳；• 看 distance=1 根节点，分清 ArkTS 还是 Native 的责任

它不是孤立脚本，而是为 AI Agent 框架量身打造的「工作流大脑」——每个技能由 SKILL.md（工作流）、scripts/（量化脚本）和 references/（故障模式库）三件套构成，让大语言模型在拿到日志后能像资深 DFX 工程师一样：先解析、再匹配、后归因，最终输出「三级根因 + 证据链 + 修复建议」。内存持续上涨，但问题不在 JS 层。它会先读取日志摘要，再按资源、队列、故障栈、

DFX Skills 是面向 HarmonyOS / OpenHarmony 生态的故障自动化分析技能集，将DFX专家经验沉淀为可被 AI Agent 调用的 Skill。本文从 5 个实战问题场景出发，结合 cppcrash-analysis、jscrash-analysis、jsleak-analysis、appfreeze-analysis、perf-analysis 等技能，拆解"遇到问题

当前 Freeze 由主线程（UI 线程）卡死引起。主线程调用了 FFRT 的 wait 接口（ffrt_wait_deps或ffrt::wait），同步等待某个 FFRT 任务完成。但该任务迟迟无法执行完毕，导致主线程长时间阻塞，最终触发应用冻屏（AppFreeze）。1. 避免在 UI 线程同步等待耗时任务。主线程调用 ffrt_wait_deps 会完全阻塞 UI 线程，应优先使用异步回调机

freeze 栈顶在方舟运行时，去掉 jsruntime 栈帧后看 3S 和 6S 的应用代码行：相同 = 主线程被这段代码卡住（不是死锁）。找到那段代码，加超时保护 / 优化算法 / 挪到 TaskPool。判别三条线索：① 栈顶在方舟运行时；② 3S 与 6S 指向同一行应用代码；③ 栈中无持锁/等待帧。三条齐备 = 主线程繁忙型冻屏，沿"主线程在忙什么"定位即可。

在分析 trace 前，需要统一以下指标的定义和测量方法。

单帧预算（ms） = 1000 / 目标刷新率（Hz）60 Hz、90 Hz、120 Hz 对应的理论预算约为 16.7 ms、11.1 ms、8.3 ms。设备可能动态切换刷新率，定位时应从 Display、H:PreferredFrameRate 或等价系统信息读取实际目标刷新率，不能固定按 60 Hz 判断。