HarmonyOS 7 新特性（七）｜JsLeakWatcher 与 HWASan 内存治理

HarmonyOS 7/API 26 的工具链强化了 ArkTS 与 Native 内存问题定位。本文不讨论"跑一次工具就结束"，而是如何把它们纳入持续质量流程。

应用内存问题大致分成两类：ArkTS 对象仍被引用导致无法回收，以及 C/C++ Native 内存越界、释放后使用等错误。JsLeakWatcher 与 HWASan 分别覆盖这两条链路，二者互补而不是互相替代。

ArkTS 有垃圾回收，但垃圾回收只能处理从根不可达的对象。如果页面已经退出，组件、回调、定时器或订阅仍通过引用链被持有，对象就无法释放。

官方最佳实践指出，持续泄漏会带来频繁 GC、主线程暂停、卡顿、内存碎片、功耗与发热，最终还可能触发 OOM 或状态错乱。JsLeakWatcher 可以对具有生命周期的 ArkTS 组件对象定期执行泄漏自检测，并生成诊断材料。

高风险位置通常包括：

HWASan 面向地址踩踏等 Native 内存错误。官方月刊说明，它可以对编译后二进制在运行过程中注入地址校验逻辑，无需修改应用业务源码。

它适合定位越界读写、释放后使用和部分非法地址访问。代价通常是额外性能与内存开销，因此应放在开发和测试构建中，而不是直接把检测配置带到生产包。

不要只打开首页观察一分钟。为每个高风险模块设计重复脚本，例如：进入详情---播放媒体---切后台---返回---退出，循环 20 次；打开相机---拍摄---取消---重新打开，循环 10 次。

每轮记录页面实例数、堆大小、GC 次数、Native 内存、句柄与线程数。真正的泄漏通常表现为多轮操作后基线无法恢复，而不是单次峰值升高。

第一步确认增长是否可重复；第二步区分 ArkTS 堆、Native 堆还是资源句柄；第三步查看对象类型或错误栈；第四步缩小到最近一次生命周期变更；第五步修复后使用同一脚本复测。

修复不能只做"退出页面时清空全部缓存"。要找出错误所有权：谁创建、谁持有、谁取消、谁释放。否则可能暂时压低内存，却引入功能丢失或并发问题。

建议在每日构建运行核心路径的 JsLeakWatcher 检测，在含 Native 模块的专项构建启用 HWASan。门禁指标可以包括：循环后存活页面对象数、内存回落比例、是否出现确定性 HWASan 报告、是否产生新增泄漏类型。

Beta SDK 与工具也可能变化，因此报告中要固定 SDK、设备、系统版本、构建类型和测试脚本版本，避免不同环境的数字直接比较。

JsLeakWatcher 让 ArkTS 引用泄漏更可见，HWASan 让 Native 地址错误更容易复现。它们真正的价值，是把"偶现卡顿/崩溃"转换成可重复脚本、对象证据和回归门禁，从而建立长期稳定性能力。