本原创文章帖发布在华为开发者联盟社区欢迎开发者前往访问评论交流更多与该内容相关讨论请点击原帖查看DevEco Studio Profiler 升级高效解决 ArkTS 与 Native 交互内存泄漏难题-华为开发者话题 | 华为开发者联盟在鸿蒙 ArkTS 与 NativeC/C交互的开发场景中ArkTS 对象被 Native 引用导致的内存泄漏问题是开发者的一大痛点。这类问题的传统定位方式高度依赖开发者具备深厚的技术积累不仅要求开发者要精通 ArkTS 引擎垃圾回收机制、在 NAPI 交互模型等基础理论还要深入理解应用代码的实现细节尤其在应用由多个模块组成、模块间依赖关系复杂的场景下问题定位复杂度倍增。这种高门槛导致许多开发者尤其是初学者在面对 ArkTS 对象被Native引用导致内存泄漏问题时往往无从下手只能通过参考典型案例、分析大量业务代码来进行问题定位效率较为低下。为了帮助开发者更高效地定位和解决此类内存泄漏问题DevEco Studio 的 Profiler 工具迎来了重大升级本次更新增强了 Allocation 内存分析能力新增了 ArkTS Snapshot 泳道支持 Local Handle 和 Global Handle 采样模式在跨语言调用场景中打通 ArkTS 和 C 语言边界内存泄漏大小和泄漏对象信息易观测问题定位效率倍增。本文中我们将结合 DevEco Studio Profiler 工具系统梳理 ArkTS 对象被Native 引用导致内存泄漏的定位思路、实操步骤与实践案例。为什么ArkTS对象会被Native“锁死”ArkTS 对象被 Native 引用导致内存泄漏的根因在于 Native 代码通过napi_ref 或不当使用 napi_value 导致长期持有 ArkTS 对象形成了“隐形强引用”阻断了 ArkTS 引擎的垃圾回收。在 NAPI 交互模型中Native 代码引用 ArkTS 对象主要依赖两种句柄Local Handle (napi_value): 通常指在 Native 代码执行上下文中创建的、作用域较短的引用由 handle scope 来管理。Global Handle (napi_ref): 这是一种由开发者自行管理生命周期的强引用。ArkTS 引擎的垃圾回收是基于“可达性分析”算法实现的当 ArkTS 侧所有引用变量、闭包等被清除后对象理论上应被回收。一旦 Native 代码通过 napi_ref 或 napi_value不当持有该对象这两种句柄会在 GC 图中成为一个“根节点”。 即使 ArkTS 侧已彻底断开引用GC 仍会判定该对象“可达”导致无法回收。久而久之未释放的句柄堆积演变为内存溢出问题。升级后的Allocation内存分析工具能做什么在定位 ArkTS 对象被 Native 引用引发的内存泄露问题时开发者常受限于工具或日志信息不足难以追溯具体是哪块 Native 代码在持有着它。这导致泄漏边界模糊、引用链断裂定界分析极为困难。升级后的 Allocation 工具实现了关键突破——支持 ArkTS 对象和 Native 引用分配调用栈 的双向关联可精准追溯持有权属快速还原跨语言引用关系链大幅降低定位门槛。ArkTS内存泄漏分析案例案例背景现象本案例中通过复现‘首页至消息页’的反复进出操作观察到应用内存占用呈现阶梯式持续增长趋势。在循环操作10次后应用出现显著卡顿现象。初步判断典型的“阶梯式内存增长”高度疑似内存泄漏。分析流程步骤1Memory泳道确认泄漏1、打开 DevEco Studio连接真机点击 Profiler 工具 Realtime Monitor也可使用 snapshot 模板的 Memory 录制观察以下是使用 Realtime Monitor 观察。2、启动应用选择设备与应用进程。3、点击录制按钮在设备上重复操作进入消息页面 → 停留 2 秒 → 返回首页重复多次。4、观察内存曲线• 正常预期每次退出后内存回落至基线附近整体呈锯齿状。• 实际现象曲线呈阶梯状上升多次操作后内存增长至 314.1 MB 且无明显回落。✅ 确认存在内存泄漏进入下一步。步骤2堆快照对比定位异常对象1、在 Profiler 中切换到 Snapshot 模板请参考使用 Snapshot 模板基本操作• Snapshot 模板基本操作文档中心选择 Profiler 工具 → 选择设备与应用进程 → 选择 Snapshot 模板 → 创建Session → 启动录制2、抓取快照1首次在进入消息页前点击“Take Heap Snapshot”。3、抓取快照2重复进出消息页面 7 次后回到首页点击 “Take Heap Snapshot”再抓取第二次快照并停止录制。4、在快照对比视图Comparison中选择CompareTo Snapshot 1。5、查看对象新增销毁情况优先关注• 操作次数的整数倍或整数倍1 export 出的对象本身也有一条引用链;• 业务对象即 Constructor 的结构为包名/模块名/文件路径#泄漏对象关键发现• 对比结果中Proxy 对象数量异常创建 70 个未销毁。✅ 确认 Test 对象实例泄漏。步骤3追踪引用链1、点击 “Shortest Paths” 获得如下 Proxy 对象实例的最短引用链发现该 Proxy 对象的 Distance 为 1 。说明其为 GC Root 直接持有的对象被 Native 侧直接持有未释放即 JS 对象被 Local Handle / Global Handle 引用导致内存泄漏。2、通过 Proxy 对象的 Distance 为 1 的 References 确认内存泄漏是由 JS 对象被 Global Handle 引用导致。步骤4分析Local Handle / Global Handle类型持有导致泄漏问题基于步骤3分析得到 Proxy 对象实例可能被 Local Handle / Global Handle 引用导致内存泄露我们可以通过以下步骤继续分析定位1、配置Allocation录制模板并捕获数据• 打开 DevEco Studio确保你的工程已加载并连接了目标设备或模拟器。• 进入 Profiler 模块在主界面下方菜单栏找到并点击 Profiler 选项卡。• 选择应用进程运行应用并在 “区域 2 ”选择目标设备和应用进程。• 创建 Allocation 录制模板选择 “Allocation” 并点击 Create Session 创建录制模板配置录制参数•配置模式选择详情模式即关闭 Statistics Mode 。当前仅详情模式支持进行 ArkTS 和 Native 的关联分析。•配置开关勾选“Local Handle”和“Global Handle”这是关键配置。这将使Allocation 专门捕获与 JS-NAPI 句柄相关的内存分配事件。如果底层镜像不支持该功能则会提示“当前镜像版本不支持请升级镜像”。配置泳道范围勾选 ArkTS Snapshot 泳道。这将使 Allocation 在录制结尾时自动抓取一份 Snapshot 快照用于关联分析。启动录制勾选了“Local Handle”开关后如果是在应用本生命周期内首次录制local handle 数据会触发弹窗请求重启应用以便录制对应信息此时点击 OK 允许重启即可。•运行应用程序运行目标应用执行相关被怀疑引入内存泄露的业务操作持续一段时间以增加内存压力和捕获更多数据。•停止录制自动触发抓取一份 Snapshot 快照用于关联分析。点击快照查找到疑似泄漏对象 Proxy 。2、泄漏对象关联分析定位可疑ArkTS对象选中一个怀疑被泄漏的 ArkTS 对象实例或对象类型查看扩展标签页。查看 Native List若某个 ArkTS 对象的 distance 值为 1则可以通过扩展标签页中的 Native List 标签页查看所有当前与该 JS 对象关联的 Native 句柄引用以确认该 JS 对象是被 Local Handle 或 Global Handle 引用的对象。关键信息(1)句柄类型调用栈底层的符号 ArkGlobalHandle 或 ArkLocalHandle 判断泄漏类型(2)调用栈通过调用栈可以定位到应用的 Native 代码可能是 ArkUI 框架代码或你自己代码中创建 napi_ref 的地方。(3)注意点• 如果该 JS 对象节点不是一个被 Local Handle 或者 Global Handle 引用的对象则会提示 No Detail• 如果该 JS 对象确实是一个被 Local Handle 或者 Global Handle 引用的对象但是对应的 native 内存的申请事件已经在此次录制之前完成内存分配本次录制结果则无法展示对应的内存申请调用栈需要重新录制录制时需要注意将录制时执行的业务逻辑范围调整的尽量更早一些。3、分析内存分配调用栈• 排查调用栈“Native List”标签页中的调用栈找到对应业务代码关键排查点• 检查是否在适当的时候调用了对应的句柄释放接口如 napi_delete_reference等。• 梳理这段 Native 代码需要引用 ArkTS 对象的合理性识别这个引用的生命周期是否过长是否应该在某个条件满足后被释放• 对于 napi_ref 其引用计数是关键。确保在不再需要引用时正确调用了 napi_delete_reference 。注意引用计数可能因其他代码路径的创建或删除操作而意外增减。检查句柄的作用域是否合理。local handle 是否应该只在 JS 执行上下文切换前使用global handle 是否真的需要在整个应用生命周期都有效修复验证1、重新运行应用再次使用 Memory 泳道监控。2、重复多次进出消息中心页。3、验证结果• 内存曲线恢复锯齿状每次退出后回落至基线。• 再次抓取快照对比多次操作后业务对象实例数量无明显增长。• 泄漏问题已修复。体验与推广DevEco Studio Profile 工具的跨语言交互内存泄漏定位能力已就绪欢迎开发者前往 DevEco Studio 体验最新内存分析功能助力开发者提高内存问题定位效率。----------------------------------------------------------------------------------------------------------官网开发者学堂视频华为开发者学堂社区DFX专题文章华为开发者问答 | 华为开发者联盟【扫码加入 HarmonyOS DFX 技术交流群】