一、引言

1.1 研究背景与意义

随着鸿蒙生态的快速发展，越来越多的开发者加入到 HarmonyOS 应用开发的行列。然而，内存泄漏作为移动开发中的常见问题，在鸿蒙平台上同样存在且具有其特殊性。内存泄漏不仅影响应用性能，严重时会导致应用崩溃、系统卡顿，直接影响用户体验。

本文基于实际开发经验，系统性地梳理鸿蒙平台内存泄漏的常见场景、分析方法和解决方案，为开发者提供实用的参考指南。

二、内存泄漏基础概念

2.1 什么是内存泄漏

内存泄漏（Memory Leak）是指程序在运行过程中动态分配了内存，但在使用完毕后未能正确释放，导致这部分内存无法被重新利用。随着程序运行时间的增长，未释放的内存会不断累积，最终可能导致：

可用内存耗尽
系统性能下降
应用被系统强制终止

2.2 内存泄漏的常见类型

堆内存泄漏

最常见的泄漏类型，指通过 malloc、new 或语言层面的对象创建分配的内存未被释放。


// ArkTS 示例：对象引用未清理

class DataProcessor {

  private cache: string[] = [];



  processData(data: string) {

    this.cache.push(data); // 持续增长，从未清理

  }

}

资源未释放

包括文件句柄、网络连接、数据库连接、图形资源等系统资源未正确关闭。


// 文件句柄未关闭

let file = fs.openSync('data.txt', fs.OpenMode.READ_ONLY);

let content = fs.readSync(file);

// 忘记调用 fs.closeSync(file)

循环引用

两个或多个对象相互引用，导致垃圾回收器无法识别它们已不再使用。


// 循环引用示例

class Node {

  parent: Node | null = null;

  children: Node[] = [];



  addChild(child: Node) {

    child.parent = this;  // 子节点引用父节点

    this.children.push(child); // 父节点引用子节点

  }

}

2.3 内存泄漏的危害

性能下降

可用内存减少，触发更频繁的 GC
GC 停顿时间增加，界面卡顿
系统需要更多时间进行内存管理

应用崩溃

OOM（Out Of Memory）错误
系统强制终止应用
关键功能异常

系统不稳定

影响其他应用运行
设备整体响应变慢
可能触发系统级问题

三、鸿蒙系统内存管理架构

3.1 HarmonyOS 内存管理机制概述

HarmonyOS 采用分层内存管理架构：


┌─────────────────────────────────────┐

│         应用层 (Application)         │

│    ArkTS / JS / Native Code         │

├─────────────────────────────────────┤

│         框架层 (Framework)           │

│    Ability / UI / Service           │

├─────────────────────────────────────┤

│         系统层 (System)              │

│    Kernel / Memory Manager          │

└─────────────────────────────────────┘

3.2 ArkTS/JavaScript 内存模型

ArkTS 是鸿蒙主推的开发语言，基于 TypeScript 扩展。其内存管理特点：

自动垃圾回收：采用分代 GC 算法
引用计数辅助：部分场景使用引用计数
对象生命周期：由运行时自动管理


// 对象生命周期示例

class MyComponent {

  data: string[] = [];



  onCreate() {

    this.data = new Array(1000); // 分配内存

  }



  onDestroy() {

    this.data = null; // 帮助 GC 识别可回收

  }

}

3.3 原生代码（C/C++）内存管理

对于性能敏感场景，鸿蒙支持 NDK 开发。原生代码需要手动管理内存：


// C++ 内存管理示例

void processData() {

    int* buffer = new int[1024]; // 分配

    // ... 使用 buffer

    delete[] buffer; // 必须手动释放

}

3.4 垃圾回收（GC）机制

HarmonyOS 的 GC 机制特点：

分代回收：新生代（Minor GC）和老年代（Major GC）
并发标记：减少 STW（Stop-The-World）时间
增量回收：将 GC 工作分散到多个时间点

GC 触发条件：

内存分配达到阈值
系统内存压力
应用进入后台

3.5 鸿蒙特有的内存管理特性

分布式内存管理

跨设备内存共享机制
远程对象引用的内存跟踪
分布式任务间的资源协调

原子化服务内存隔离

每个原子化服务独立内存空间
服务间通信的内存拷贝优化
服务生命周期与内存释放绑定

四、鸿蒙应用常见内存泄漏场景

4.1 ArkTS/JavaScript 层泄漏

全局变量未清理


// ❌ 错误示例：全局变量持续增长

let globalCache: string[] = [];



export function addToCache(item: string) {

  globalCache.push(item); // 永不清理

}



// ✅ 正确做法：限制缓存大小或使用 WeakMap

const cache = new WeakMap<object, string>();

定时器/回调未注销


// ❌ 错误示例

class MyPage {

  timer: number;



  onStart() {

    this.timer = setInterval(() => {

      this.updateData();

    }, 1000);

  }



  // 忘记在 onStop 中清除定时器

}



// ✅ 正确做法

class MyPage {

  timer: number;



  onStart() {

    this.timer = setInterval(() => {

      this.updateData();

    }, 1000);

  }



  onStop() {

    if (this.timer) {

      clearInterval(this.timer);

      this.timer = 0;

    }

  }

}

事件监听器未移除


// ❌ 错误示例

class DataViewer {

  constructor() {

    EventBus.on('dataUpdate', this.handleUpdate);

    // 组件销毁时未移除监听

  }

}



// ✅ 正确做法

class DataViewer {

  private listener: (data: any) => void;



  constructor() {

    this.listener = this.handleUpdate.bind(this);

    EventBus.on('dataUpdate', this.listener);

  }



  destroy() {

    EventBus.off('dataUpdate', this.listener);

  }

}

闭包引用问题


// ❌ 错误示例：闭包持有大对象引用

function createHandler(largeData: ArrayBuffer) {

  return function() {

    console.log(largeData.length); // largeData 无法被 GC

  };

}



// ✅ 正确做法：只引用必要数据

function createHandler(dataSize: number) {

  return function() {

    console.log(dataSize);

  };

}

4.2 UI 组件相关泄漏

组件引用未释放


// ❌ 错误示例

class Page {

  private components: Component[] = [];



  buildUI() {

    for (let i = 0; i < 100; i++) {

      this.components.push(new MyComponent());

    }

  }



  // 页面销毁时未清理 components 数组

}



// ✅ 正确做法

class Page {

  private components: Component[] = [];



  buildUI() {

    for (let i = 0; i < 100; i++) {

      this.components.push(new MyComponent());

    }

  }



  onDestroy() {

    this.components.forEach(c => c.destroy());

    this.components = [];

  }

}

页面导航状态残留


// ❌ 错误示例：导航栈中页面引用未清理

router.pushUrl({

  url: 'pages/DetailPage',

  params: { largeData: this.data } // 传递大对象

});



// ✅ 正确做法：传递引用或 ID

router.pushUrl({

  url: 'pages/DetailPage',

  params: { dataId: this.data.id }

});

4.3 原生层（Native）泄漏

malloc/new 未配对 free/delete


// ❌ 错误示例

void processImage() {

    uint8_t* buffer = (uint8_t*)malloc(1024 * 1024);

    // ... 处理图像

    // 忘记 free(buffer)

}



// ✅ 正确做法

void processImage() {

    uint8_t* buffer = (uint8_t*)malloc(1024 * 1024);

    if (buffer == nullptr) return;

   

    // ... 处理图像

   

    free(buffer);

    buffer = nullptr;

}

JNI 引用未释放


// ❌ 错误示例

JNIEXPORT void JNICALL Java_com_example_Main_process

  (JNIEnv* env, jobject thiz, jobject obj) {

    jobject globalRef = env->NewGlobalRef(obj);

    // 忘记调用 DeleteGlobalRef

}



// ✅ 正确做法

JNIEXPORT void JNICALL Java_com_example_Main_process

  (JNIEnv* env, jobject thiz, jobject obj) {

    jobject globalRef = env->NewGlobalRef(obj);

    // ... 使用 globalRef

   

    env->DeleteGlobalRef(globalRef);

}

4.4 资源类泄漏

文件句柄未关闭


// ❌ 错误示例

function readFile(path: string): string {

  let file = fs.openSync(path, fs.OpenMode.READ_ONLY);

  let content = fs.readSync(file);

  // 忘记关闭文件

  return content;

}



// ✅ 正确做法：使用 try-finally

function readFile(path: string): string {

  let file = null;

  try {

    file = fs.openSync(path, fs.OpenMode.READ_ONLY);

    return fs.readSync(file);

  } finally {

    if (file) {

      fs.closeSync(file);

    }

  }

}

网络连接未断开


// ❌ 错误示例

class NetworkManager {

  private socket: socket.Socket;



  connect() {

    this.socket = socket.create();

    this.socket.connect(...);

  }



  // 忘记实现 disconnect 方法

}



// ✅ 正确做法

class NetworkManager {

  private socket: socket.Socket | null = null;



  connect() {

    this.socket = socket.create();

    this.socket.connect(...);

  }



  disconnect() {

    if (this.socket) {

      this.socket.close();

      this.socket = null;

    }

  }

}

数据库连接未释放


// ❌ 错误示例

function queryData(sql: string) {

  let db = relationalStore.getStore('mydb');

  let result = db.querySql(sql);

  // 未关闭数据库连接

  return result;

}



// ✅ 正确做法

async function queryData(sql: string) {

  let db = await relationalStore.getStore('mydb');

  try {

    return await db.querySql(sql);

  } finally {

    await db.close();

  }

}

五、内存泄漏分析工具与方法

5.1 DevEco Studio 内置工具

Profiler 内存分析

DevEco Studio 提供强大的 Profiler 工具：

打开方式：View → Tool Windows → Profiler
选择设备：连接真机或模拟器
选择进程：选择目标应用
开始监控：点击 Memory 面板的 Record 按钮

关键指标：

Heap Size：堆内存大小
Allocated：已分配内存
GC Count：GC 次数
GC Time：GC 耗时

Heap Snapshot

堆快照功能可以捕获某一时刻的内存状态：

捕获快照：在 Profiler 中点击 "Capture Heap Snapshot"
分析对象：查看对象分布、引用链
对比快照：对比不同时间点的快照，找出增长的对象

分析技巧：

按大小排序：找出占用内存最大的对象
按数量排序：找出实例数量最多的对象
查看引用树：理解对象为何未被回收

内存时间线

内存时间线显示内存使用随时间的变化：

绿色区域：正常内存波动
阶梯式上升：可能存在泄漏
持续不下降：确认泄漏嫌疑

5.2 命令行工具

hprof 分析


# 导出堆转储文件

hdc shell am dumpheap <pid> /data/local/tmp/heap.hprof



# 拉取到本地

hdc file recv /data/local/tmp/heap.hprof ./heap.hprof



# 使用 MAT 或 jhat 分析

jhat -J-Xmx2g heap.hprof

系统日志查看


# 查看内存相关日志

hdc shell hilog | grep -i "memory\|heap\|gc"



# 查看应用内存使用

hdc shell bm dump -n <bundle_name>

5.3 第三方工具集成

Android Studio Profiler：部分兼容
MAT (Memory Analyzer Tool)：分析 hprof 文件
LeakCanary：需适配鸿蒙版本

5.4 分析方法论

基线对比法

应用启动后捕获基准快照
执行特定操作序列
捕获操作后快照
对比差异，找出新增对象

增量分析法

重复执行可疑操作 N 次
观察内存增长趋势
定位增长最快的对象类型

压力测试法

长时间运行应用
高频执行各种操作
监控内存是否持续增长
结合快照定位泄漏点

六、实战案例分析

6.1 案例一：定时器导致的内存泄漏

问题现象

应用运行 30 分钟后明显卡顿
内存从 200MB 增长到 800MB
GC 频率从每分钟 2 次增加到 10 次

定位过程

开启 Profiler 监控：发现内存呈阶梯式增长
捕获堆快照：发现大量 TimerTask 对象
查看引用链：TimerTask → MyPage → 大对象
检查代码：发现定时器未在页面销毁时清除


// 问题代码

class MyPage {

  private timer: number;



  onPageShow() {

    this.timer = setInterval(() => {

      this.fetchData(); // 持有页面引用

    }, 5000);

  }



  // 缺少 onPageHide 清理

}

解决方案


class MyPage {

  private timer: number | null = null;



  onPageShow() {

    this.timer = setInterval(() => {

      this.fetchData();

    }, 5000);

  }



  onPageHide() {

    if (this.timer) {

      clearInterval(this.timer);

      this.timer = null;

    }

  }

}

6.2 案例二：事件监听器未清理

问题现象

页面反复进出后内存持续增长
同一事件被多次触发
控制台出现重复日志

定位过程

添加日志：在事件回调中打印页面实例 ID
发现异常：同一事件有多个不同实例的回调
检查注册代码：发现每次页面创建都注册监听
确认问题：缺少注销逻辑


// 问题代码

class DataPage {

  constructor() {

    EventBus.on('dataChange', (data) => {

      this.update(data); // 闭包持有 this 引用

    });

  }

}

解决方案


class DataPage {

  private eventListener: (data: any) => void;



  constructor() {

    this.eventListener = this.handleDataChange.bind(this);

    EventBus.on('dataChange', this.eventListener);

  }



  onDestroy() {

    EventBus.off('dataChange', this.eventListener);

  }



  private handleDataChange(data: any) {

    this.update(data);

  }

}

6.3 案例三：Native 层内存泄漏

问题现象

ArkTS 层内存正常，但整体内存增长
原生库调用后内存不释放
长时间运行后崩溃

定位过程

使用 Native Profiler：监控 native heap
发现增长点：图像处理模块
审查 NDK 代码：发现 malloc 无对应 free
确认路径：异常分支未释放内存


// 问题代码

JNIEXPORT jbyteArray JNICALL processImage(...) {

    jsize size = env->GetArrayLength(input);

    uint8_t* buffer = (uint8_t*)malloc(size);

   

    if (error_condition) {

        return NULL; // 忘记 free(buffer)

    }

   

    // ... 处理

   

    free(buffer);

    return result;

}

解决方案


JNIEXPORT jbyteArray JNICALL processImage(...) {

    jsize size = env->GetArrayLength(input);

    uint8_t* buffer = (uint8_t*)malloc(size);

    if (buffer == nullptr) {

        return NULL;

    }

   

    jbyteArray result = NULL;

   

    if (error_condition) {

        goto cleanup;

    }

   

    // ... 处理

    result = createResult(...);

   

cleanup:

    free(buffer);

    return result;

}

6.4 案例四：循环引用问题

问题现象

特定操作后内存不释放
GC 后内存下降不明显
对象图显示复杂引用关系

定位过程

捕获堆快照：使用 Profiler
分析引用图：发现 A→B→C→A 的循环
定位代码：父子组件双向引用
确认问题：子组件持有父组件强引用


// 问题代码

class Parent {

  children: Child[] = [];

}



class Child {

  parent: Parent; // 强引用父节点



  constructor(parent: Parent) {

    this.parent = parent;

  }

}

解决方案


// 方案一：使用弱引用

class Child {

  parent: WeakRef<Parent>;



  constructor(parent: Parent) {

    this.parent = new WeakRef(parent);

  }



  getParent(): Parent | undefined {

    return this.parent.deref();

  }

}



// 方案二：手动断开引用

class Parent {

  children: Child[] = [];



  destroy() {

    this.children.forEach(c => c.parent = null);

    this.children = [];

  }

}

七、内存泄漏预防与最佳实践

7.1 编码规范建议

资源管理原则

谁申请，谁释放：明确资源管理责任
成对出现：open/close、malloc/free、on/off
异常安全：确保异常路径也释放资源

代码审查清单

[ ] 所有定时器都有对应的清除逻辑
[ ] 所有事件监听都有注销代码
[ ] 所有资源打开都有关闭保证
[ ] 闭包中只引用必要数据
[ ] 长生命周期对象不持有短生命周期对象引用

7.2 资源管理最佳实践

使用 RAII 模式


class AutoCloseFile {

  private file: fs.File | null = null;



  constructor(path: string) {

    this.file = fs.openSync(path, fs.OpenMode.READ_ONLY);

  }



  read(): string {

    if (!this.file) throw new Error('File not open');

    return fs.readSync(this.file);

  }



  [Symbol.dispose]() {

    if (this.file) {

      fs.closeSync(this.file);

      this.file = null;

    }

  }

}



// 使用

using file = new AutoCloseFile('data.txt');

let content = file.read();

// 自动关闭

统一资源管理


class ResourceManager {

  private resources: Array<() => void> = [];



  register(cleanup: () => void) {

    this.resources.push(cleanup);

  }



  releaseAll() {

    this.resources.forEach(fn => fn());

    this.resources = [];

  }

}

7.3 代码审查要点

重点审查区域

生命周期方法：onCreate/onDestroy、onShow/onHide
异步回调：Promise、async/await、回调函数
全局状态：单例、全局变量、事件总线
原生交互：NDK 调用、JNI 代码

审查问题示例


// ❌ 审查时发现的问题

class Problematic {

  data: any;



  init() {

    this.data = loadLargeData();

    EventBus.on('update', this.handle);

    setInterval(this.tick, 1000);

  }



  // 没有对应的 cleanup 方法！

}

7.4 自动化检测方案

静态分析工具


# 使用 ArkTS 分析工具

arkts-analyzer --check-leaks ./src



# 集成到 CI/CD

npm run lint -- --memory-check

运行时检测


// 开发环境启用泄漏检测

if (__DEV__) {

  enableLeakDetection({

    threshold: 100 * 1024 * 1024, // 100MB

    onLeak: (info) => {

      console.warn('Potential leak:', info);

    }

  });

}

7.5 性能测试策略

测试场景设计

长时间运行测试：连续运行 8-24 小时
压力测试：高频执行各种操作
边界测试：内存极限情况
场景测试：典型用户操作路径

监控指标

内存使用趋势
GC 频率和耗时
帧率稳定性
崩溃率

八、总结

8 核心要点回顾

理解机制：掌握鸿蒙内存管理基本原理
识别场景：熟悉常见泄漏模式和代码特征
善用工具：熟练使用 Profiler 等分析工具
预防为主：建立编码规范和审查机制

附录

A. 常用命令速查


# 查看应用内存

hdc shell bm dump -n <bundle_name>



# 导出堆快照

hdc shell am dumpheap <pid> /data/local/tmp/heap.hprof

hdc file recv /data/local/tmp/heap.hprof ./



# 查看内存日志

hdc shell hilog | grep -i memory



# 查看进程信息

hdc shell ps -ef | grep <process_name>

ITPub博客

鸿蒙（HarmonyOS）内存泄漏问题分析

一、引言

1.1 研究背景与意义

二、内存泄漏基础概念

2.1 什么是内存泄漏

2.2 内存泄漏的常见类型

堆内存泄漏

资源未释放

循环引用

2.3 内存泄漏的危害

性能下降

应用崩溃

系统不稳定

三、鸿蒙系统内存管理架构

3.1 HarmonyOS 内存管理机制概述

3.2 ArkTS/JavaScript 内存模型

3.3 原生代码（C/C++）内存管理

3.4 垃圾回收（GC）机制

3.5 鸿蒙特有的内存管理特性

分布式内存管理

原子化服务内存隔离

四、鸿蒙应用常见内存泄漏场景

4.1 ArkTS/JavaScript 层泄漏

全局变量未清理

定时器/回调未注销

事件监听器未移除

闭包引用问题

4.2 UI 组件相关泄漏

组件引用未释放

页面导航状态残留

4.3 原生层（Native）泄漏

malloc/new 未配对 free/delete

JNI 引用未释放

4.4 资源类泄漏

文件句柄未关闭

网络连接未断开

数据库连接未释放

五、内存泄漏分析工具与方法

5.1 DevEco Studio 内置工具

Profiler 内存分析

Heap Snapshot

内存时间线

5.2 命令行工具

hprof 分析

系统日志查看

5.3 第三方工具集成

5.4 分析方法论

基线对比法

增量分析法

压力测试法

六、实战案例分析

6.1 案例一：定时器导致的内存泄漏

问题现象

定位过程

解决方案

6.2 案例二：事件监听器未清理

问题现象

定位过程

解决方案

6.3 案例三：Native 层内存泄漏

问题现象

定位过程

解决方案

6.4 案例四：循环引用问题

问题现象

定位过程

解决方案

七、内存泄漏预防与最佳实践

7.1 编码规范建议

资源管理原则

代码审查清单

7.2 资源管理最佳实践

使用 RAII 模式

统一资源管理

7.3 代码审查要点

重点审查区域

审查问题示例

7.4 自动化检测方案

静态分析工具