前言一次长视频导出卡死我怎样用 DFX Skills 把问题缩到文件复制从 THREAD_BLOCK_6S 到有界异步 I/O证据、修复与复测视频导出最让人误判的一类问题是编码已经做了很多工作界面却在保存阶段不再响应。看起来像媒体引擎卡住日志顶部也可能停在系统内存函数里如果顺着最显眼的那一行往下猜很容易越查越远。这次案例的故障类型是 AppFreeze记录中的原因是 THREAD_BLOCK_6S。它不是 JS Crash也不能因为栈里出现 Native 函数就改按 CppCrash 分析。DFX Skills 对我的帮助是把原始故障记录里的概览、资源、事件队列和线程栈整理到一起方便交叉核对。真正需要开发者完成的是把这些证据接回当时的业务代码。下面使用脱敏后的旧版故障案例。旧问题已经有后续修复本文讨论的是如何从历史证据定位并复查修复工具的再次分析不等于当前版本又复现了一次。函数名只保留说明职责所需的通用含义路径、用户文件和设备标识不进入公开材料。先确认读的是哪一份现场我在看堆栈前会先记录四件事故障类型、发生场景、当时的应用版本以及代码对应的版本。这里的场景是长视频导出后的本地保存不能直接拿今天的代码解释旧日志更不能因为当前函数已经改成异步就判定旧堆栈不可信。DFX Skills 的 AppFreeze 分析脚本可以分区输出。下面的路径用 skill-root 表示实际工具根目录不绑定本机安装位置命令中的 case.log 应替换为自己的原始 AppFreeze 日志。​ python skill-root/scripts/freeze/main.py -p case.log --section overview python skill-root/scripts/freeze/main.py -p case.log --section resources python skill-root/scripts/freeze/main.py -p case.log --section event-queue python skill-root/scripts/freeze/main.py -p case.log --section fault-stack ​我的阅读顺序是先看 overview 判断事件类别再看 event-queue 判断主线程上的任务是否推进然后用 fault-stack 找业务职责最后结合 resources 排查资源压力。四份输出回答的是不同问题不能把某一个“异常”标签直接当成根因。如果工具输出比原始日志少要回到原始字段确认是不是采集缺失如果堆栈采集超时也要把这个事实写进结论。没有采到不等于对应工作没有发生。两次快照里的同一个任务比一个栈顶更有说服力这个案例中两次事件队列快照显示同一个任务的开始时间保持不变执行时长从约 3.521 秒增长到 6.686 秒后面等待处理的工作也在累积。它给出的线索是主线程正在一个长任务里停留新的事件无法及时被处理。证据对本案的意义不应扩大的结论THREAD_BLOCK_6S系统记录了主线程阻塞故障不能单凭原因名定位具体函数同一任务持续 3.521s → 6.686s长任务没有及时让出执行不是精确的函数耗时统计导出 → 文件修复 → 整体写回业务责任落到保存阶段不代表编码耗时为零栈中出现 memset / 内存处理当时可能正分配或填充内存不能直接认定系统库有缺陷堆栈采集有退化或超时必须保留证据边界不能编出热点占比这里最关键的交叉验证是事件队列证明“卡在哪一类执行状态”业务栈告诉我“为什么这一阶段会做大量工作”旧代码再说明“工作规模如何随视频大小增长”。三者能对上修复才有明确落点。图 1两次快照指向同一长任务再由业务栈与旧代码确认保存阶段的同步工作。资源区里的高 RSS 需要看但它单独不能证明泄漏或 OOM。这个案例也没有足够的完整采样去写“某函数占用了多少百分比 CPU”。我会把结论停在证据能支持的位置主线程执行了与大文件体量相关的同步内存和文件操作足以解释当前阻塞。async 函数为什么仍然会卡住页面旧保存链路会读取较大的文件内容、构造新字节数组再整体写回。调用者虽然 await 了导出函数但被调函数内部仍可能在主线程同步执行这些步骤。async function saveVideo(path) { const wholeFile readAllSync(path); const repaired rebuildBytes(wholeFile); writeAllSync(path, repaired); }这段是旧问题模式的缩写不是可直接运行的文件 API。async 只描述返回值和异步暂停能力不会自动把函数体搬到工作线程把同步调用套在 Promise 里同样不能改变它在哪个线程执行。即使在整段工作之前加一个 await后面连续的计算与同步 I/O 仍然可能长时间占住主线程。因此我没有把修复目标写成“加几个 await”。目标应该是两个可以检查的条件复制使用的缓冲区有固定上限长文件的读写通过异步接口推进避免整文件同步搬运。对于必须连续计算的重活另行判断是否要进入 Worker 或任务池而不是用循环中的空 Promise 假装迁移线程。修复的核心是把文件大小从内存需求里拿掉后续实现里有界复制函数复用一个 1 MiB 缓冲区显式传递源偏移和目标偏移并处理提前结束、短写与取消。文件描述符由调用方管理复制函数不关闭传入的 FD。这几条约定比“用了异步 API”更重要因为它们决定错误时数据和资源会处于什么状态。1 MiB 是这份实现的块大小不是所有设备都应照抄的最佳参数。更准确的内存说法是“复制环节的应用缓冲为 O(块大小)”而不是“整个导出只用 1 MiB”。媒体编解码器、其他任务和短写时的临时切片仍然占内存。短写尤其容易漏掉一次 write 返回 n只能说明本次写入 n 字节。剩余数据要继续写返回 0 或负数必须终止不能让循环一直转。let written 0; while (written readBytes) { const view buffer.subarray(written, readBytes); const n await writeAt(view, destinationOffset written); if (!Number.isInteger(n) || n 0 || n view.length) { throw new Error(write made no valid progress); } written n; }这段使用注入的 writeAt 接口配套 bounded-copy.mjs 将读、写、取消和长度检查组合成完整示例。它能在 Node 中通过模拟短读、短写和错误来复测迁入 ArkTS 时应按目标文件 API 适配参数而不是把 Node 示例说成鸿蒙真机实现。另外文件偏移不能只校验初始值。若要面向超大文件还要检查 offset copied 是否仍为安全整数目标写入范围有没有越界。复制固定长度时源文件提前 EOF 应报错复制到 EOF 时正常读到结尾才结束。这两种语义需要在函数参数里说清楚。文件修复只处理自己理解的范围长视频保存链路里还有 MP4 首样本修复。这里更不适合为了“通用”而把整个文件读进内存先有界读取头部识别自己明确支持的盒结构与字段能定位到必要修改再处理遇到不支持的布局就按既定策略退出不能靠猜偏移去改用户文件。建议把“无须修复”“完成修复”“不支持此格式布局”“处理失败”分成明确结果。前两种可以继续后两种由上层决定保留原件、提示失败或走替代路径。把所有异常都吞掉并返回成功会让后面的图库或上传阶段背上一个难定位的损坏文件。本案后续代码还增加了长视频导出策略。流式复制解决的是一段操作的内存与响应性并不能取消总磁盘空间、编解码器实例数和并发任务的上限。临时产物与最终产物并存时要按真实存储开销判断是否能启动失败时只删除当前任务拥有的临时文件不能顺手删除源视频。用故障注入验证修复比只换一个大视频更快配套示例专门让读写返回比请求更少的字节并在指定位置取消或报错。小数据就能暴露“只写了一部分仍报成功”“无进展无限循环”“取消后继续写”等问题没必要每次都复制十几 GB 才验证控制逻辑。真机验收则看另一层导出期间页面能否交互、取消多久被观察到、峰值内存是否随文件大小明显增长、保存产物是否存在视频轨且可播放以及反复进入退出后资源是否释放。不同层的测试各管自己的结论。已有历史记录包含 18 项真机用例通过超长 4K 素材也有压力路径记录。但对某个超大素材现有记录并没有完整覆盖“最终导出完成并落盘”的自动化证据所以不能把它写成超大文件全链路全部通过DFX Skills 最值得复用的用法我会保留一份很短的案件笔记故障发生在哪个版本哪两条独立证据支持判断对应哪段代码修改了哪个复杂度或执行位置用什么用例验证还有什么没有验证。这样下次换一个 Skills 版本重新分析结果也有参照而不是重新相信一段更流畅的文字。这次案例里工具帮助我更快读完现场旧代码解释了阻塞机制短写和取消测试把修复要求固定下来。最有用的经验是这三步能够互相核对。缺少其中任何一步笔记都容易停在“日志分析了一遍代码改了一处”遇到相关问题仍然不知道类似卡点该怎么做。实现来源与配套内容分析工具来自 OpenHarmony-SIG / developtools_dfx_skills 的 AppFreeze 分析模块本文不把工具本身算作个人原创。故障数据来自实际历史案例公开表格保留时长关系与职责链移除了真实身份、设备和业务路径。*写在最后感谢终端BG软件部的鸿蒙DFX团队研发与开源相关skills把排障专家请到了每位开发者的身边让稳定性问题不再是基层普通开发者的大难题。笔者已经通过该skill修复了一个大量很久补丁的链路并且基于相关建议进行了完全重构得到了非常好的结果。也再次提醒希望使用者可以结合现场日志分析避免出现分析定位不准的情况。