HarmonyOS 7/API 26 的工具链强化了 ArkTS 与 Native 内存问题定位。本文不讨论“跑一次工具就结束”，而是如何把它们纳入持续质量流程。
应用内存问题大致分成两类：ArkTS 对象仍被引用导致无法回收，以及 C/C++ Native 内存越界、释放后使用等错误。JsLeakWatcher 与 HWASan 分别覆盖这两条链路，二者互补而不是互相替代。
一、JsLeakWatcher 解决什么问题
ArkTS 有垃圾回收，但垃圾回收只能处理从根不可达的对象。如果页面已经退出，组件、回调、定时器或订阅仍通过引用链被持有，对象就无法释放。
官方最佳实践指出，持续泄漏会带来频繁 GC、主线程暂停、卡顿、内存碎片、功耗与发热，最终还可能触发 OOM 或状态错乱。JsLeakWatcher 可以对具有生命周期的 ArkTS 组件对象定期执行泄漏自检测，并生成诊断材料。
高风险位置通常包括：
- 页面退出后未取消的事件订阅；
- 定时器和异步回调闭包持有页面对象；
- 全局单例缓存 UI 状态；
- 列表复用项被业务 Map 长期保存；
- Web、媒体或相机对象没有按生命周期释放。
二、HWASan 关注 Native 内存安全
HWASan 面向地址踩踏等 Native 内存错误。官方月刊说明，它可以对编译后二进制在运行过程中注入地址校验逻辑，无需修改应用业务源码。
它适合定位越界读写、释放后使用和部分非法地址访问。代价通常是额外性能与内存开销，因此应放在开发和测试构建中，而不是直接把检测配置带到生产包。
三、建立可复现的检测场景
不要只打开首页观察一分钟。为每个高风险模块设计重复脚本，例如：进入详情—播放媒体—切后台—返回—退出，循环 20 次；打开相机—拍摄—取消—重新打开，循环 10 次。
每轮记录页面实例数、堆大小、GC 次数、Native 内存、句柄与线程数。真正的泄漏通常表现为多轮操作后基线无法恢复，而不是单次峰值升高。
四、定位时按证据链收敛
第一步确认增长是否可重复；第二步区分 ArkTS 堆、Native 堆还是资源句柄；第三步查看对象类型或错误栈；第四步缩小到最近一次生命周期变更；第五步修复后使用同一脚本复测。
修复不能只做“退出页面时清空全部缓存”。要找出错误所有权：谁创建、谁持有、谁取消、谁释放。否则可能暂时压低内存，却引入功能丢失或并发问题。
五、把工具接入质量门禁
建议在每日构建运行核心路径的 JsLeakWatcher 检测，在含 Native 模块的专项构建启用 HWASan。门禁指标可以包括：循环后存活页面对象数、内存回落比例、是否出现确定性 HWASan 报告、是否产生新增泄漏类型。
Beta SDK 与工具也可能变化，因此报告中要固定 SDK、设备、系统版本、构建类型和测试脚本版本，避免不同环境的数字直接比较。
结语
JsLeakWatcher 让 ArkTS 引用泄漏更可见，HWASan 让 Native 地址错误更容易复现。它们真正的价值，是把“偶现卡顿/崩溃”转换成可重复脚本、对象证据和回归门禁，从而建立长期稳定性能力。
官方参考
- JsLeakWatcher 开发实践：https://developer.huawei.com/consumer/cn/doc/best-practices/bpta-js-leak-watcher
- 2026 年 6 月开发者月刊：https://developer.huawei.com/consumer/cn/monthly/202606
- HarmonyOS 7 新能力一览：https://developer.huawei.com/consumer/cn/features/
 _视觉语言导航介绍)
