JsLeakWatcher 报对象未释放就一定泄漏？HarmonyOS 7 用生命周期证据排除误报

事故现场

页面退出后工具仍显示对象存活，团队立刻把它标成泄漏；几秒后对象又被回收。另一次对象一直存在，却因为没有持续增长被忽略。内存诊断不能只看某一时刻的“对象还在”，需要生命周期终点、GC 观察窗和引用来源。

验证边界：本文依据文末列出的华为开发者官方页面整理，并用可执行的 TypeScript 状态模型检查应用侧分支。当前本机只有 API 24 工具链且没有连接 HarmonyOS 7 真机，因此文中的 API 26 接入片段属于按官方资料整理的接入骨架，不声称已经完成 API 26 编译、真机性能测试或设备兼容认证。正式上线前必须在目标 API 26 SDK 与真实设备上补齐编译、权限、异常码和性能证据。

根因不是表面现象

页面对象可能被动画、Promise、定时器、事件监听或缓存暂时持有。先定义“按业务应该释放”的时间点，再停止可控任务、触发稳定复现并观察多个周期。如果对象数量在重复进入退出后单调增长，再结合持有链定位谁没有解绑；单个对象短期存活只是线索。

可执行的应用侧模型

type Sample={round:number;alive:number};
function trend(rows:Sample[]){return rows.every((x,i)=>i===0||x.alive>=rows[i-1].alive)&&rows.at(-1)!.alive>rows[0].alive;}
if(!trend([{round:1,alive:1},{round:5,alive:3},{round:10,alive:6}]))throw new Error('增长趋势未识别');

两个复现场景

案例一：事件总线忘记取消监听

连续进入退出十次，页面实例数递增。移除监听后重复同样脚本，实例回到稳定基线；证据包含复现次数、时间线和修改前后对象数。

案例二：退出动画导致延迟释放

页面退出后 300ms 动画持有节点，观察窗太短会误判。等待动画结束和一个合理回收窗口后对象消失，不需要为了“立即归零”破坏动画。

为什么这样修

以重复场景趋势和持有链作为证据，比一次快照可靠。只强制 GC 后看是否归零可能受运行时调度影响；只看总内存又无法定位对象。工具结果应与业务生命周期互相验证。

回归验证

验证项	通过标准
固定脚本进入退出10次	有可重复步骤、日志或可见结果
记录页面销毁与异步任务结束时间	有可重复步骤、日志或可见结果
比较修改前后同样观察窗	有可重复步骤、日志或可见结果
检查监听/定时器/缓存持有链	有可重复步骤、日志或可见结果
前后台切换单独建场景	有可重复步骤、日志或可见结果

官方资料与证据边界

JsLeakWatcher 的具体入口、支持范围和工具版本以当前 DevEco Studio 26 文档为准。本文状态模型不模拟 ArkTS GC，也不宣称一次宿主测试能证明无泄漏。

1. 2026 年 6 月开发者月刊

2. 2026 年 9 月开发者月刊

最后留下一个可复用结论

这篇文章不把“接口能调用”当成完成。真正可复用的是：先确定输入契约和生命周期，再把失败路径写进状态模型；平台能力负责提供机制，应用负责把机制变成可观察、可回退、可验证的工程链路。下一次遇到同类问题，先复现和记录证据，再调整实现，不靠重复重试掩盖根因。