鸿蒙 / KMP开发经验：使用hidumper实现内存泄漏定界
在鸿蒙平台进行KMP相关业务开发时，内存问题排查一直是个棘手的难点。不同于传统单技术栈应用，KMP业务需横跨 kotlin/native runtime、napi、arkts runtime 三大模块，而这三者有着完全不同的内存模型、内存管理方案，对应的内存分析工具也存在差异。这种多技术栈交织的特性，让内存泄漏排查的第一步——“找对方向”，变得尤为关键。本文将重点分享如何利用鸿蒙自带的 hdc 工具集下的 hidumper，快速实现内存泄漏的定界，为后续精准排查打下基础。
一、核心痛点：多内存模型下的泄漏排查困境
在KMP开发场景中，三个核心模块的内存管理逻辑相互独立，一旦出现内存泄漏，我们首先要解决的问题是：泄漏的内存到底属于哪个 runtime ？
kotlin/native runtime：采用基于GC的内存管理机制，同时包含native层的内存分配逻辑；napi：作为JS与native交互的桥梁，需兼顾两端内存模型，存在跨层内存引用的风险；arkts runtime：鸿蒙ArkTS应用的核心运行时，有其独立的内存分配与回收机制。
如果无法先明确泄漏内存的归属范围，盲目使用某一模块的内存分析工具（如仅用ArkTS的内存profile工具），大概率会做无用功。因此， “定界”是多内存模型下泄漏排查的第一要务，而 hidumper --mem 正是实现这一目标的高效工具。
二、关键工具：hidumper 内存快照获取
鸿蒙的 hdc（HarmonyOS Device Connector）是设备与开发机交互的核心工具，而 hidumper 是 hdc 提供的系统信息dump工具，其中--mem [pid] 选项可精准获取指定进程的内存区域快照，为泄漏定界提供数据支撑。
2.1 基础使用方法
首先确保开发机已通过 hdc 连接鸿蒙设备（或模拟器），然后执行以下命令获取目标进程的内存快照：
# 1. 先通过以下命令获取目标进程的pid（以包名com.example.xkmpdemo为例）
hdc shell ps -ef | grep com.example.kmpdemo
# 2. 执行hidumper获取内存快照，替换[pid]为实际进程ID
hdc shell hidumper --mem [pid] > mem_snapshot_$(date +%Y%m%d%H%M%S).txt
命令执行后，会将内存快照输出到指定的文本文件中（文件名含时间戳，方便后续对比）。通过定时执行该命令，可获取多个时间点的内存快照，为分析内存变化趋势提供数据基础。
2.2 内存快照核心字段解读
hidumper输出的内存快照包含多个内存区域的详细数据，核心字段及含义如下（结合实际快照示例说明）：
| 字段名称 | 单位 | 含义说明 |
|---|---|---|
| Pss Total | kB | 比例设置大小，即进程实际占用的物理内存（考虑共享内存的分摊），是评估进程内存占用的核心指标 |
| Shared Clean | kB | 共享的干净内存（未被修改的共享内存），多个进程可共享，不会被计入单个进程的独占内存 |
| Shared Dirty | kB | 共享的脏内存（被修改过的共享内存），同样可被多个进程共享，但修改后的数据仅当前进程可见 |
| Private Clean | kB | 进程独占的干净内存，未被修改，仅当前进程可访问 |
| Private Dirty | kB | 进程独占的脏内存，被修改过，是进程内存泄漏的核心关注对象（泄漏的内存多为未释放的独占脏内存） |
| Heap Size | kB | 堆内存总大小 |
| Heap Alloc | kB | 已分配的堆内存大小 |
| Heap Free | kB | 空闲的堆内存大小 |
2.3 核心内存区域含义（结合快照示例）
以下是实际的内存快照片段，重点解读与XKMP开发相关的核心内存区域：
对KMP开发而言，需重点关注以下3个核心内存区域：
1. ark ts heap（ArkTS堆）
对应ArkTS runtime的内存区域，所有ArkTS层的对象（如页面组件、业务数据对象）均分配在此区域。若快照中该区域的 Private Dirty 字段随时间持续增长，且无法通过GC释放，则说明泄漏点大概率在ArkTS层。
2. native heap（原生堆）
这是KMP业务的核心关注区域！因为当前鸿蒙平台下，KMP相关内存均分配在native heap中。该区域进一步细分了多种堆类型：
- jemalloc heap：主要用于KMP相关的内存分配，是KMP业务内存的核心载体；
- brk heap/mmap heap：传统native层内存分配区域，可能包含napi交互过程中的内存分配。
若native heap的 Heap Alloc 持续增长，且 Private Dirty 占比过高，则需重点排查KMP业务或napi交互中的内存泄漏。
3. 其他辅助区域
.hap：HAP包相关的内存区域，一般不会出现泄漏；.so：动态库相关内存，若动态库加载释放逻辑异常可能导致泄漏；stack：栈内存，通常不会出现持续性泄漏。
三、内存泄漏定界实操：从快照对比到范围锁定
定界的核心思路是：通过对比多个时间点的内存快照，观察各内存区域的变化趋势，锁定泄漏内存所属的 runtime/区域。具体步骤如下：
3.1 获取多时间点快照
在复现内存泄漏的场景下（如反复进入退出某页面、循环执行某业务逻辑），定时执行hidumper命令，获取至少3个时间点的快照（如初始状态、执行10次操作后、执行20次操作后）。
3.2 快照对比：用Python脚本可视化趋势
手动对比快照数据效率低，可通过Python脚本提取核心字段（如各区域Pss Total、Heap Alloc），绘制折线图，直观观察变化趋势。以下是简单的脚本思路：
通过折线图可快速判断：若仅Native Heap Alloc持续增长，则泄漏点锁定在KMP或napi层；若仅ArkTS Heap Alloc增长，则泄漏点在ArkTS层。
3.3 进一步定界：KMP堆大小验证
若已确定Native Heap存在泄漏，需进一步判断是否为KMP业务导致。当前可通过技术手段获取KMP堆大小（Kperf工具团队在开发相关支持功能），若KMP堆大小随业务执行持续增长，则可明确泄漏点在KMP业务逻辑中；若KMP堆大小稳定，则需排查napi交互或其他native层代码。
四、后续排查：定界后的精准突破
完成定界后，可针对不同区域的泄漏进行精准排查：
4.1 Native层泄漏（含KMP）
- 鸿蒙支持Native Heap的Allocation录制，复现泄漏场景时，开启Allocation录制，通过分析创建与销毁的对象差异、调用树（calltree），可定位到泄漏的内存分配堆栈；
- 若确定是KMP泄漏：由于Kotlin/Native基于GC机制，需查看泄漏对象到GC Root的引用路径。当前可通过dump KMP堆内存，使用Java的MAT工具分析引用链，找到未释放的引用后，参考Android开发经验断开引用链即可（此方案暂无大规模场景实践，需平台同学支持，感兴趣的同学可尝试验证）。
4.2 ArkTS层泄漏
可使用鸿蒙DevEco Studio自带的ArkTS内存分析工具，查看对象引用链，定位未释放的对象（如页面栈未销毁、全局变量持有对象引用等）。
五、总结
在鸿蒙 + KMP开发的多内存模型场景下，内存泄漏排查的关键是 “先定界，再精准排查” 。hidumper工具通过获取进程内存区域快照，结合多时间点对比与可视化分析，可快速锁定泄漏内存所属的runtime/区域，大幅降低排查难度。后续只需针对定界后的区域，选用对应的工具与方法，即可高效定位并解决泄漏问题。希望本文的经验分享能为各位KMP开发者提供帮助，也期待鸿蒙生态的内存分析工具能进一步完善，简化多栈场景下的排查流程。
