HarmonyOS 鸿蒙Next应用开发中常见的API误用导致的内存泄漏，帮助大家避坑，持续更新（2025/10/31）

HarmonyOS 鸿蒙Next应用开发中常见的API误用导致的内存泄漏，帮助大家避坑，持续更新（2025/10/31）

整理鸿蒙应用开发中常见的API误用导致的内存泄漏，帮助大家避坑，持续更新（2025/11/1）

目前鸿蒙开发中有很多的开发约束，稍有不慎就会导致内存泄露，这里开一个帖子整理场景的内存泄露的API误用代码、场景，及一些内存泄露的代码分析手段。

也希望大家在评论区分享自己应用开发中内存泄露的一些案例，或者指正其中问题， 欢迎大家收藏，此贴持续更新

changelog

2025/10/29 https://developer.huawei.com/consumer/cn/forum/topicpost 草稿

2025/10/30 初始化OH_Drawing_CreateFontCollection 、OH_NativeWindow_ReadFromParcel 、OH_NativeWindow_CreateNativeWindowBufferFromNativeBuffer、OH_IPCParcel_Create、rpc.MessageSequence.create、OH_JSVM_CreateReference、napi_create_reference、napi_open_handle_scope 使用注意

2025/10/31 新增利用clang-tidy进行IDE基础内存泄露

2025/11/1 感谢@段晓冬提供，OH_NativeWindow_nativeObjectReference、OH_NativeWindow_nativeWindowFromSurfaceId内存泄露注意

目录

[TOC]

1. 内存泄露案例

1.1 图形相关

1.1.1 OH_Drawing_CreateFontCollection

语言类型: C-API

使用约束: 使用API OH_Drawing_FontCollection* OH_Drawing_CreateFontCollection(void) 创建的字体集必须通过调用API *void OH_Drawing_DestroyFontCollection(OH_Drawing_FontCollection fontCollection)**释放，否则会造成内存泄露

参考:

OH_Drawing_CreateFontCollection官方API OH_Drawing_DestroyFontCollection官方API

1.2 窗口相关

1.2.1 OH_NativeWindow_ReadFromParcel

语言类型: C-API

使用约束:

int32_t OH_NativeWindow_ReadFromParcel(OHIPCParcel *parcel, OHNativeWindow **window) 会创建一个OHNativeWindow ，当窗口对象使用完，开发者需与void OH_NativeWindow_DestroyNativeWindow(OHNativeWindow* window) 接口配合使用，否则会存在内存泄漏

参考:

OH_NativeWindow_ReadFromParcel API

OH_NativeWindow_DestroyNativeWindow API

1.2.2 OH_NativeWindow_CreateNativeWindowBufferFromNativeBuffer

语言类型: C-API

使用约束:

OHNativeWindowBuffer* OH_NativeWindow_CreateNativeWindowBufferFromNativeBuffer(OH_NativeBuffer* nativeBuffer) 会新创建的OHNativeWindowBuffer，需要主动 OH_NativeWindow_DestroyNativeWindowBuffer进行内存释放，否则导致内存泄露

参考:

OH_NativeWindow_CreateNativeWindowBufferFromNativeBuffer API

1.2.3 OH_NativeWindow_nativeObjectReference

语言类型: C-API

使用约束:

增加一个NativeObject的引用计数，int32_t OH_NativeWindow_NativeObjectReference(void *obj) 本接口需要与OH_NativeWindow_NativeObjectUnreference接口配合使用，否则会存在内存泄露。

参考:

OH_NativeWindow_NativeObjectReference API NativeWindow开发指导 (C/C++)

1.2.4 OH_NativeWindow_CreateNativeWindowFromSurfaceId

语言类型: C-API

使用约束: 通过surfaceId创建对应的OHNativeWindow，int32_t OH_NativeWindow_CreateNativeWindowFromSurfaceId(uint64_t surfaceId, OHNativeWindow **window) 本接口需要与OH_NativeWindow_DestroyNativeWindow接口配合使用，否则会存在内存泄露。

参考:

OH_NativeWindow_CreateNativeWindowFromSurfaceId API

1.3 IPC相关

1.3.2 OH_IPCParcel_Create

语言类型: C-API

使用约束:

OHIPCParcel* OH_IPCParcel_Create(void) 会创建一个OHIPCParcel对象，此对象使用完毕后需要主动调用 OH_IPCParcel_Destroy去释放,否则会导致内存泄露

参考:

oh_ipcparcel_create API文档

ipc cpi 开发指导

1.3.1 rpc.MessageSequence.create

语言类型: ArkTS-API

使用约束:

在RPC或IPC过程中，发送方可以使用MessageSequence提供rpc.MessageSequence.create();的方法，将待发送的数据以特定格式写入该对象。接收方可以使用MessageSequence提供的读方法从该对象中读取特定格式的数据. 在使用完毕后，需要主动调用 **reclaim **释放，否则导致内存泄露, 应用做IPC开发时容易常犯此问题

示例：

import { rpc } from '@kit.IPCKit';
import { hilog } from '@kit.PerformanceAnalysisKit';
import { BusinessError } from '@kit.BasicServicesKit';

try {
 let data = rpc.MessageSequence.create();
 hilog.info(0x0000, 'testTag', 'data is ' + data);

 // 当MessageSequence对象不再使用，由业务主动调用reclaim方法去释放资源。
 data.reclaim();
} catch (error) {
 let e: BusinessError = error as BusinessError;
 hilog.error(0x0000, 'testTag', 'errorCode ' + e.code);
 hilog.error(0x0000, 'testTag', 'errorMessage ' + e.message);
}

参考:

messagesequence API文档

1.4 JSVM相关

1.4.1 OH_JSVM_CreateReference

语言类型: C-API

使用约束:

JSVM_EXTERN JSVM_Status OH_JSVM_CreateReference(JSVM_Env env,JSVM_Value value,uint32_t initialRefcount,JSVM_Ref* result)和 **OH_JSVM_DeleteReference ** 接口没有成对调用，如果没有主动Delete造成Reference内存泄露。

参考:

oh_jsvm_createreference API

JSVM-API 内存泄露问题定位指导

1.5 Node-API相关

Node-API这块生命周期比较复杂，很容易导致内存泄露，希望大家重点关注

1.5.1 napi_create_reference

语言类型: C-API

使用约束:

napi_create_reference 为Object创建一个napi_ref,调用者需要自己管理napi_ref生命周期，在使用完毕后需要主动调用 napi_status napi_delete_reference(napi_env env, napi_ref ref); ， napi_create_reference与 napi_delete_reference 必须成对调用。

参考:

使用Node-API接口进行生命周期相关开发

NAPI 内存泄漏相关问题汇总

1.5.2 napi_open_handle_scope

语言类型: C-API

使用约束：

  1. napi_value 未包裹在独立handle_scope，导致napi_value的生命周期管理不当，造成napi_value内存泄露

  2. napi_open_handle_scope 需要使用 napi_close_handle_scope 关闭

参考:

NODE-API 原生scope管理说明

使用Node-API接口进行生命周期相关开发

NAPI 内存泄漏相关问题汇总

1.6 ArkUI组件相关

https://developer.huawei.com/consumer/cn/doc/harmonyos-references/js-apis-arkui-buildernode

@todo 待补充 BuilderNode\ ComponentContent\FrameNode\Graphics\NodeController\RenderNode\AttributeUpdater\Content\NodeContent

内存泄露

2. IDE代码工程拦截手段

2.1 基础内存泄露检测（clang-tidy）

目前IDE中对C-API的使用默认是不使能内存泄露检测，需要开发者主动开启，以下是基于 DevEco Studio 6.0.0 Release 版本的，内存泄露开启方式

  1. IDE 操作 Code->Analyze Code->Run Inspection By Name , 输入clang-tidy 运行

  2. 在checks 中的 -*下面增加 clang-analyzer-unix.Malloc

-*
clang-analyzer-unix.Malloc
clang-analyzer-unix.MismatchedDeallocator
clang-analyzer-huawei.InfiniteRecursiveChecker
clang-analyzer-huawei.InfiniteGotoChecker
clang-analyzer-huawei.InfiniteLoopChecker
clang-analyzer-core.StackAddressEscape
clang-analyzer-core.ArrayBoundV2
clang-analyzer-core.CallAndMessage
clang-analyzer-core.uninitialized.ArraySubscript
clang-analyzer-core.uninitialized.Assign
clang-analyzer-core.uninitialized.Branch
clang-analyzer-core.uninitialized.UndefReturn
clang-analyzer-core.UndefinedBinaryOperatorResult
modernize-use-noexcept
cert-err58-cpp
bugprone-macro-repeated-side-effects
clang-analyzer-core.NullDereference
clang-analyzer-core.UndefinedUnaryOperatorResult
clang-analyzer-core.uninitialized.CapturedBlockVariable
huawei-switch-has-default
huawei-default-at-last
huawei-macro-parentheses
huawei-lambda-localref-escape
whitebox-5g-5gl3customize-iterator-loop-stop-with-end-check
huawei-exception-caught-by-earlier-handler
huawei-use-member-in-ctor-catch-block
huawei-not-rely-on-init-seq
huawei-local-variable-hides-global
huawei-non-const-references-parameter
huawei-non-const-parameter
huawei-throw-by-value
huawei-catch-by-reference
  1. 点击 OK 运行，可以检测基础的内存泄露

2.1 增强内存泄露检测（clang-tidy）

在2.1的基础上增强对鸿蒙自定义内存申请分配释放的检测能力，@todo

3. 其他参考


更多关于HarmonyOS 鸿蒙Next应用开发中常见的API误用导致的内存泄漏，帮助大家避坑，持续更新（2025/10/31）的实战教程也可以访问 https://www.itying.com/category-93-b0.html

3 回复

加油，

更多关于HarmonyOS 鸿蒙Next应用开发中常见的API误用导致的内存泄漏，帮助大家避坑，持续更新（2025/10/31）的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


在鸿蒙Next应用开发中，常见API误用导致内存泄漏的情况包括：未正确释放UI组件引用、事件监听器未及时注销、异步任务未取消、资源句柄未关闭。需注意生命周期回调中及时清理资源，避免持有Context导致Activity无法回收。使用ArkTS开发时应严格管理对象引用关系，特别是全局变量和静态字段的引用。

感谢整理这份详细的HarmonyOS Next API内存泄漏避坑指南，内容非常实用。以下是对部分关键点的补充和强调：

  1. 图形与窗口资源管理：OH_Drawing_CreateFontCollection、OH_NativeWindow系列接口必须配对使用销毁接口，建议在代码中采用RAII模式或显式资源管理清单。

  2. IPC对象生命周期：OH_IPCParcel_Create和rpc.MessageSequence.create需注意跨进程场景下的释放时机，建议在finally块或析构逻辑中统一处理。

  3. JSVM/Node-API引用控制：

    • OH_JSVM_CreateReference与napi_create_reference需严格匹配删除操作，建议通过封装类自动管理引用计数。
    • napi_open_handle_scope必须通过napi_close_handle_scope闭合，避免局部对象堆积。

  4. ArkUI组件：BuilderNode等组件需关注节点树解耦，防止循环引用导致GC失效。

  5. 检测工具：clang-tidy配置中可补充clang-analyzer-cplusplus.NewDeleteLeaks检测C++内存操作，同时建议结合DevEco Profiler实时监控内存曲线。

期待后续ArkUI组件案例的更新，这类问题在实际开发中出现频率较高。建议开发者建立资源创建-释放的检查清单，在代码审查阶段重点核查。

回到顶部