uniapp小程序内存泄漏定位与解决全攻略

一、引言

当一个小程序运行时间较长或多次进入/退出某些页面后，如果遇到界面卡顿、加载缓慢、渐渐占用越来越多内存甚至崩溃等情况，很可能是存在内存泄漏（Memory Leak）。内存泄漏不仅影响用户体验，还会导致 App 被系统回收或关闭，从而影响业务稳定性。

作为基于 Vue 框架的跨端开发框架，uniapp 在小程序环境下运行时，其 JavaScript 层和原生层（native 层）都有可能出现内存泄漏问题。本文将从内存模型、常见泄漏场景、定位工具、典型示例到解决方案，逐步剖析 uniapp 小程序中的内存泄漏问题，并给出详尽的图解与代码示例，帮助你快速上手、精准排查与修复。

二、uniapp 小程序内存模型概述

2.1 JS 层与原生层内存

在小程序环境下，内存使用主要分为两层：

JavaScript 层（JS Heap）
- 运行在 V8（或基于 JSCore）的 JavaScript 引擎中，用于存放 JS 对象、闭包、函数上下文等。
- 当对象或闭包不再被引用时，V8 的垃圾回收（GC）机制会回收其占用的内存。
原生层（Native Heap）
- 主要指小程序底层框架、原生组件（如 map、video、canvas 等）以及图片、音视频等资源在 native 端的内存占用。
- 某些原生资源（例如大型图片、Canvas 绘制的 bitmap）需要手动销毁，否则会一直占用 native 内存。

在调试时，我们主要关注 JS 层的内存泄漏（常见于闭包、未解除事件绑定等）和原生层的内存泄漏（常见于 WebView、Canvas、Media、地图组件等没有正确销毁）。微信开发者工具（及其它平台的调试工具）都提供了JS Heap和Native Heap的快照与曲线，方便开发者定位哪一层存在问题。

图解示意（ASCII）

┌───────────────────────────────┐
│      uniapp 小程序运行时        │
│ ┌───────────────┐  ┌─────────┐ │
│ │  JavaScript   │  │ 原生层  │ │
│ │   (V8/JSCore)  │  │  (C++   │ │
│ │  - JS Heap    │  │  + Native│ │
│ │  - 闭包/对象   │  │  资源   │ │
│ └───────────────┘  └─────────┘ │
└───────────────────────────────┘

图1：uniapp 小程序内存结构示意

左侧为 JS 层，包括各种 JS 对象、闭包、定时器引用等。
右侧为原生层，包括图片缓冲、Canvas Bitmap、Media、WebView 内存等。

三、常见内存泄漏场景与成因

在 uniapp 小程序开发中，以下几种场景是最容易导致内存泄漏的。理解这些场景，有助于在编码阶段进行预防，也便于事后快速定位。

3.1 定时器（setInterval / setTimeout）未清除

问题描述
在页面 onLoad 或 onShow 中调用了 setInterval（或 setTimeout），但在 onUnload（或页面销毁）时未调用 clearInterval（或 clearTimeout），导致定时器一直存在，闭包持有页面上下文，无法被 GC 回收。

示例代码（易漏场景）

<template>
  <view>
    <text>{{ timerCount }}</text>
  </view>
</template>

<script>
export default {
  data() {
    return {
      timerCount: 0,
      timerId: null
    };
  },
  onLoad() {
    // 页面加载时开启定时器，每秒更新 timerCount
    this.timerId = setInterval(() => {
      this.timerCount++;
    }, 1000);
  },
  onUnload() {
    // 如果忘记清除定时器，页面销毁后仍会继续执行
    // clearInterval(this.timerId);
  }
};
</script>

后果

页面已经进入 onUnload，但定时器回调依旧持有 this 引用（页面实例），无法被销毁；
若用户反复进出该页面，会产生多个定时器，闭包不断累积，JS Heap 空间水涨船高，最终触发内存告警或崩溃。

3.2 事件监听（$on / $once / $off）未解绑

问题描述
使用 uniapp 的事件总线（uni.$on）或第三方库的全局事件监听（如 EventBus），在页面或组件卸载时未调用 uni.$off（或相应解绑方法），导致闭包对回调函数的引用始终存在。

示例代码（易漏场景）

// globalEventBus.js
import Vue from 'vue';
export const EventBus = new Vue();

// HomePage.vue
<script>
import { EventBus } from '@/utils/globalEventBus';

export default {
  created() {
    // 监听全局事件，如用户登录状态更新
    EventBus.$on('user:login', this.handleUserLogin);
  },
  methods: {
    handleUserLogin(userInfo) {
      console.log('用户登录：', userInfo);
    }
  },
  // 如果没有 beforeDestroy / onUnload 解绑
  // beforeDestroy() {
  //   EventBus.$off('user:login', this.handleUserLogin);
  // }
};
</script>

后果

当页面销毁后，事件总线中依旧保存着 handleUserLogin 的回调引用；
若该页面多次创建、销毁，会不断累积监听函数，GC 无法回收页面实例，导致内存泄漏。

3.3 组件闭包、箭头函数、回调中引用外部变量

问题描述
在方法内定义了大量闭包或箭头函数，并在回调中将页面/组件 data、computed、methods 等上下文直接引用，若不及时移除或置空，GC 无法收集，从而导致泄漏。

示例代码（易漏场景）

<script>
export default {
  data() {
    return {
      largeData: new Array(1000000).fill('x'), // 大量数据
      intervalId: null
    };
  },
  methods: {
    startProcessing() {
      // 使用箭头函数闭包引用 largeData
      this.intervalId = setInterval(() => {
        // 此处闭包持有 this.largeData
        console.log(this.largeData.length);
      }, 2000);
    }
  },
  onLoad() {
    this.startProcessing();
  },
  onUnload() {
    // 如果这里忘记 clearInterval，那么 largeData 一直被引用
    // clearInterval(this.intervalId);
    this.largeData = null; // 即使尝试置空，闭包依旧持有引用，只有在定时器清除后才释放
  }
};
</script>

后果

largeData 数组本意在页面卸载时设置为 null，但闭包中仍有对其引用，导致内存不能真正释放；
用户多次进入该页面，largeData 累计大量数据常驻内存。

3.4 全局变量或单例缓存过度使用

问题描述
一些工具类、单例模式或全局变量将大量数据缓存到内存中，但未设置合理的过期/清理策略，随着业务执行量增多，内存会不断膨胀。

示例代码（易漏场景）

// cache.js
let globalCache = {};

export function setCache(key, value) {
  globalCache[key] = value;
}

export function getCache(key) {
  return globalCache[key];
}

// 某页面
<script>
import { setCache } from '@/utils/cache';

export default {
  onLoad() {
    // 将大文件内容缓存到全局
    setCache('largeJson', new Array(500000).fill('abc'));
  }
};
</script>

后果

缓存中没有任何清理逻辑，导致缓存一直存在；
如果缓存对象非常庞大，native layer 和 JS Heap 都被耗尽。

3.5 原生组件（Map / Canvas / Video）未销毁

问题描述
例如在页面上创建了 <map> 组件或 <canvas>，但在页面卸载时没有销毁或清空其上下文；某些情况下，虽然页面销毁，但原生组件仍然持有一些资源。

示例代码（易漏场景）

<template>
  <view>
    <map id="myMap" :latitude="lat" :longitude="lng"></map>
  </view>
</template>

<script>
export default {
  data() {
    return {
      lat: 23.099994,
      lng: 113.32452
    };
  },
  onUnload() {
    // 如果需要手动清理，可以调用相关 API（部分原生组件会在 onUnload 自动清理）
    // this.$refs.myMap = null; // 只是置空 JS 引用，可能不足以销毁 native 层
  }
};
</script>

后果

地图组件内部会创建原生地理图层缓存等，如果多次打开页面且地图组件多次创建/销毁，native 内存会逐渐增加；
某些平台对 Canvas 需要主动调用 canvasContext.destroy()，否则画布数据长期驻留。

四、内存泄漏定位工具与方法

要准确地定位内存泄漏，需要借助小程序官方或第三方的调试与分析工具。下面介绍几种常用的方法与工具。

4.1 微信开发者工具 Performance 面板

微信开发者工具提供了一套性能（Performance）分析面板，包括Timeline、Memory、**Heap Snapshot（JS 堆快照）**等功能。

Timeline 录制
- 打开开发者工具，点击右上角三个点，选择「调试→调试工具」，在打开的调试窗口中切换到「Performance」选项卡。
- 点击「开始录制」，在小程序中模拟多次打开/关闭页面、交互操作，录制 10\~30 秒；然后点击「停止」。
- 在录制面板中可以看到函数调用堆栈、内存曲线（JS Heap 和 Native Heap）随时间变化。若发现 JS Heap 持续上涨不回落，说明存在内存泄漏。
Heap Snapshot（堆快照）获取
- 在「Memory」选项卡下，可点击「Take Heap Snapshot」获取当前 JS 堆快照。
- 快照会列出所有内存中保留的对象及其数量、大小等，可以对比多次快照，定位哪些对象数量不断增加、占用内存不断膨胀。

图解示意（ASCII）

┌────────────────────────────┐
│  Performance 面板         │
│ ┌───────┬───────────────┐ │
│ │Timeline│ Memory         │ │
│ │  (1)   │  (2)           │ │
│ └───────┴───────────────┘ │
└────────────────────────────┘

在「Timeline」中可直观看到内存曲线随时间变化；
在「Memory」中可生成多次快照并对比各对象引用情况。

4.2 HBuilderX + Chrome DevTools

对于通过 HBuilderX 编译到微信小程序的 uniapp 项目，也可使用 Chrome DevTools 远程调试实现内存分析。

启动调试
- 在 HBuilderX 中，打开项目，选择「运行→运行到小程序模拟器-微信」，打开微信开发者工具。
- 在微信开发者工具右上角开启「调试模式」，会自动弹出 Chrome DevTools。
- 在 Chrome DevTools 中，切换到 “Memory” 标签，可进行堆快照（Heap snapshot）和时间分配分析。
对比堆快照
- 在不同操作阶段（页面首次加载、重复打开/关闭、页面交互后）分别点击快照，并观察特定对象（如页面实例、组件实例、定时器回调函数等）数量是否在持续增加。

4.3 `console.memory`（仅部分平台支持）

部分小程序平台（如支付宝小程序）支持在 Console 中打印 console.memory，可以获取当前 JS 内存使用情况（仅作参考，不十分准确）。

4.4 第三方内存监控插件

对于更深入的内存监控，一些开发者会引入第三方监控 SDK（如阿里云监控、友盟+、腾讯云 TMonitor 等），利用它们上报内存指标到云端，可在生产环境实时监控内存情况。不过，本文重点聚焦在本地开发时的定位与解决。

五、典型内存泄漏示例与修复方案

下面结合具体示例，演示常见内存泄漏场景的定位思路与修复方案。每个示例都包含“故障代码→定位思路→修复代码→图解说明”的步骤。

5.1 示例一：定时器未清除导致内存泄漏

故障代码

<template>
  <view>
    <text>当前计数：{{ count }}</text>
  </view>
</template>

<script>
export default {
  data() {
    return {
      count: 0,
      timer: null
    };
  },
  onLoad() {
    // 页面加载时启动定时器
    this.timer = setInterval(() => {
      // 每秒增加 count
      this.count++;
    }, 1000);
  },
  onUnload() {
    // 忘记清除定时器
    // clearInterval(this.timer);
  }
};
</script>

定位思路

进入该页面 ⇒ JS Heap 大幅上涨
在 Performance 面板中，点击「Timeline」录制后，可以看到刚进入页面时 JS Heap 有一定峰值，随后 1 秒 1 次的定时器不断执行，内存使用持续增加。
多次进入/关闭页面后 ⇒ Heap 快照对比
- 在不同阶段（第一次进入、关闭；第二次进入、关闭；第三次进入、关闭）各拍一次堆快照；
- 发现页面实例对象（Page 或者组件 VueComponent）数量不断攀升，未被 GC 回收；
- 在堆快照中，找到 Closure（闭包）相关的回调函数，查看引用栈可发现该闭包一直持有 this。

图解示意（定时器泄漏）
┌───────────────────────────────┐
│ 第一次进入页面                │
│  ┌───────────┐                │
│  │ Page 实例 │                │
│  └───────────┘                │
│  ┌────────────┐               │
│  │ setInterval │               │
│  └────────────┘               │
└───────────────────────────────┘
用户操作：关闭页面
┌───────────────────────────────┐
│ 页面 onUnload （定时器未清除）│
│ ┌───────────┐ │
│ │ Page 实例 │ ← 持续存在 │
│ └───────────┘ │
│ ┌────────────┐ │
│ │ setInterval │ │
│ └────────────┘ │
└───────────────────────────────┘
用户再次进入页面，重复上面过程，Page 实例与定时器累积

修复方案

在 onUnload 钩子中清除定时器，确保闭包被释放。

<template>
  <view>
    <text>当前计数：{{ count }}</text>
  </view>
</template>

<script>
export default {
  data() {
    return {
      count: 0,
      timer: null
    };
  },
  onLoad() {
    this.timer = setInterval(() => {
      this.count++;
    }, 1000);
  },
  onUnload() {
    // 正确清除定时器
    clearInterval(this.timer);
    this.timer = null; // 置空引用，帮助 GC
  }
};
</script>

修复后效验
在 onUnload 中执行 clearInterval，定时器被销毁；
前后快照对比可见，页面实例及闭包数量正常释放，JS Heap 回落到初始值。

5.2 示例二：事件监听未解绑导致内存泄漏

故障代码

全局事件总线定义

// utils/globalBus.js
import Vue from 'vue';
export const GlobalBus = new Vue();

在页面中注册监听，却未解绑

<script>
import { GlobalBus } from '@/utils/globalBus';

export default {
  data() {
    return {
      userInfo: null
    };
  },
  created() {
    // 监听登录事件
    GlobalBus.$on('user:login', this.onUserLogin);
  },
  methods: {
    onUserLogin(user) {
      this.userInfo = user;
    },
    login() {
      // 模拟用户登录后触发
      GlobalBus.$emit('user:login', { name: '张三', id: 1001 });
    }
  },
  onUnload() {
    // 忘记解绑
    // GlobalBus.$off('user:login', this.onUserLogin);
  }
};
</script>

定位思路

触发事件后 JS Heap 略增
- 在 GlobalBus.$emit('user:login') 后会触发回调，闭包 onUserLogin 被挂载到事件列表；
- 如果不解绑，当页面销毁后，user:login 事件列表中仍保留该回调函数；与页面实例关联的 data、methods 都无法释放。
Heap 快照对比
- 在创建页面（created）后拍一次堆快照，记录 GlobalBus.$on 注册的回调；
- 多次进入/退出后，对比快照，发现对应回调函数数量在不断增加，且与页面实例关联的对象引用链未被断开。

图解示意（事件监听泄漏）
GlobalBus.$on('user:login', onUserLogin)

↑

  闭包 onUserLogin 持有 this (Page 实例)

页面 onUnload（未解绑）
↑
GlobalBus 仍持有 onUserLogin
页面实例无法回收


#### 修复方案

在页面卸载钩子中调用 `$off` 解绑事件，切断引用。

```vue
<script>
import { GlobalBus } from '@/utils/globalBus';

export default {
 data() {
   return {
     userInfo: null
   };
 },
 created() {
   GlobalBus.$on('user:login', this.onUserLogin);
 },
 methods: {
   onUserLogin(user) {
     this.userInfo = user;
   },
   login() {
     GlobalBus.$emit('user:login', { name: '张三', id: 1001 });
   }
 },
 onUnload() {
   // 正确解绑事件
   GlobalBus.$off('user:login', this.onUserLogin);
 }
};
</script>

修复后效验
解绑后，GlobalBus 的事件回调列表中不再包含 onUserLogin；
页面实例与回调函数的引用链被切断，GC 可正常回收页面实例。

5.3 示例三：长列表不停加载导致大对象驻留

故障代码

<template>
  <view>
    <scroll-view :scroll-y="true" style="height: 100vh;" @scrolltolower="loadMore">
      <view v-for="item in dataList" :key="item.id" class="item-card">
        <text>{{ item.text }}</text>
      </view>
    </scroll-view>
  </view>
</template>

<script>
export default {
  data() {
    return {
      dataList: [], // 存放大量数据
      page: 0,
      pageSize: 20,
      loading: false
    };
  },
  onLoad() {
    this.loadMore();
  },
  methods: {
    async loadMore() {
      if (this.loading) return;
      this.loading = true;
      // 模拟接口返回大量数据
      const newData = [];
      for (let i = 0; i < this.pageSize; i++) {
        newData.push({ id: this.page * this.pageSize + i, text: '项目 ' + (this.page * this.pageSize + i) });
      }
      // 人为延迟
      await new Promise(res => setTimeout(res, 500));
      this.dataList = [...this.dataList, ...newData];
      this.page++;
      this.loading = false;
    }
  }
};
</script>

<style>
.item-card {
  padding: 10px;
  border-bottom: 1px solid #ddd;
}
</style>

问题分析

当用户不断滑动触底，多次触发 loadMore()，dataList 持续增长，JS Heap 被大量字符串对象占用。
如果存在分页或缓存场景，例如在组件之间来回切换，并不清理已经加载的数据，导致内存不断膨胀。
尤其当每条数据体积较大时，短时间内 JS Heap 大量上涨，容易 OOM。

定位思路

Profile 视图下观察内存占用
- 在开发者工具中查看 Memory 曲线，发现随着滑动次数增多，JS Heap 不断爬升；
- 快照对比可发现 dataList 中对象不断增加。
检查 dataList 是否及时清理
- 若是页面生命周期短暂，但 dataList 未在离开页面时置空或重新初始化，则造成数据残留。

图解示意（长列表泄漏）

第一次 loadMore: dataList 长度 = 20 → JS Heap ↑
第二次 loadMore: dataList 长度 = 40 → JS Heap ↑
... 
第 n 次 loadMore: dataList 长度 = n*20 → JS Heap ↑↑↑
页面退出后，若 dataList 未置空，内存无法释放

修复方案

分页与清理策略
- 如果页面生命周期内需要保留历史数据，可在 onUnload 或组件销毁时清空 dataList。
- 若业务允许，可限制最大缓存长度，例如只保留最近 100 条。
示例修复代码

<template>
  <view>
    <scroll-view :scroll-y="true" style="height: 100vh;" @scrolltolower="loadMore">
      <view v-for="item in dataList" :key="item.id" class="item-card">
        <text>{{ item.text }}</text>
      </view>
    </scroll-view>
  </view>
</template>

<script>
export default {
  data() {
    return {
      dataList: [],
      page: 0,
      pageSize: 20,
      loading: false,
      maxCacheSize: 100 // 最多保留 100 条数据
    };
  },
  onLoad() {
    this.loadMore();
  },
  onUnload() {
    // 页面卸载时清空 dataList，帮助释放内存
    this.dataList = [];
  },
  methods: {
    async loadMore() {
      if (this.loading) return;
      this.loading = true;
      const newData = [];
      for (let i = 0; i < this.pageSize; i++) {
        newData.push({ id: this.page * this.pageSize + i, text: '项目 ' + (this.page * this.pageSize + i) });
      }
      await new Promise(res => setTimeout(res, 500));
      
      // 如果超过 maxCacheSize，则截断最旧数据
      const combined = [...this.dataList, ...newData];
      if (combined.length > this.maxCacheSize) {
        this.dataList = combined.slice(combined.length - this.maxCacheSize);
      } else {
        this.dataList = combined;
      }
      this.page++;
      this.loading = false;
    }
  }
};
</script>

修复后效验
对比快照可见，dataList 被清理或限制长度后，JS Heap 不再无限上涨；
页面退出时主动 this.dataList = []，打断对象引用链，垃圾回收能正常工作。

5.4 示例四：原生组件（Canvas）未销毁导致 Native 内存泄漏

故障代码

<template>
  <view>
    <canvas canvas-id="myCanvas" style="width: 300px; height: 150px;"></canvas>
  </view>
</template>

<script>
export default {
  onLoad() {
    // 获取 Canvas 上下文并绘制大量图形
    const ctx = uni.createCanvasContext('myCanvas', this);
    ctx.setFillStyle('red');
    for (let i = 0; i < 1000; i++) {
      ctx.fillRect(i * 0.3, i * 0.15, 10, 10);
    }
    ctx.draw();
  },
  onUnload() {
    // 仅置空引用，并未销毁 Canvas
    // this.canvasContext = null;
  }
};
</script>

问题分析

在 Canvas 上绘制大量像素、图形后，会占用较多的原生内存；
如果页面离开后，Canvas 未被销毁或清空，其底层 Bitmap 仍保留；
重复创建同 ID 或不同 ID 的 Canvas，会导致 Native Heap 持续增加，可能最终崩溃。

定位思路

Native Heap 曲线监测
- 在微信开发者工具 Performance 的 Timeline 中，可同时观察 JS Heap 与 Native Heap；
- 打开页面后，Native Heap 明显上涨；关闭页面却不回落，说明 native 资源未被释放。
堆快照对比
- 虽然 JS Heap 堆快照主要显示的是 JS 对象，但在 Memory 面板下切换到 “Native & JS Heap” 可以看到原生内存；可发现 Canvas 相关内存一直被占用。

图解示意（Canvas 原生内存泄漏）

第一次 onLoad: Canvas 创建、绘制 → Native Heap ↑
页面 onUnload（未销毁 Canvas）→ Native Heap 保持 ↑
第二次进入：重新创建 Canvas → Native Heap ↑↑
页面 onUnload → 不回落 → Native Heap ↑↑
导致 Native Heap 持续上涨

修复方案

主动销毁 Canvas 上下文（部分平台支持）
在 onUnload 中调用 uni.canvasToTempFilePath 并 clearRect 清空，或者在新版本 uniapp 中使用 canvasContext.destroy() 接口销毁上下文。

<template>
  <view>
    <canvas canvas-id="myCanvas" style="width: 300px; height: 150px;"></canvas>
  </view>
</template>

<script>
export default {
  data() {
    return {
      canvasContext: null
    };
  },
  onLoad() {
    // 创建 Canvas 上下文并保存引用
    this.canvasContext = uni.createCanvasContext('myCanvas', this);
    this.canvasContext.setFillStyle('red');
    for (let i = 0; i < 1000; i++) {
      this.canvasContext.fillRect(i * 0.3, i * 0.15, 10, 10);
    }
    this.canvasContext.draw();
  },
  onUnload() {
    if (this.canvasContext) {
      // 清空画布
      this.canvasContext.clearRect(0, 0, 300, 150);
      this.canvasContext.draw(true);
      // （若新版本支持销毁方法）销毁上下文
      if (this.canvasContext.destroy) {
        this.canvasContext.destroy();
      }
      this.canvasContext = null;
    }
  }
};
</script>

修复后效验
在 onUnload 中先清空画布，再调用 destroy()（如有），并将 canvasContext 置空；
Native Heap 在页面退出后能正常回落，说明原生资源被释放。

六、内存快照与曲线对比示例

下面以「定时器泄漏」为例，示意如何在微信开发者工具中对比堆快照与内存曲线，并定位泄漏。

首次进入页面
- 打开「Performance」→「Timeline」，点击录制；
- 进入页面，等待 5s，关闭页面；停止录制。
- 查看 JS Heap 曲线，发现缓慢上涨后略微回落（GC），快照 1 为第 5s 时的堆状态。
第二次进入页面
- 清空上一次录制，再次点击录制；
- 进入页面，等待 5s，再关闭页面；停止录制。
- 比较 JS Heap 曲线：可以发现第二次关闭时，JS Heap 的回落远低于第一次，说明首次的闭包未被回收。拍快照 2。
快照对比
- 在「Memory」→「Heap Snapshot」中，分别加载快照 1 和快照 2；
- 使用 “Comparison” 查看对象数量变化；
- 重点关注以下类型：
  - Closure（闭包）实例数量；
  - 页面实例（如 PageContext、VueComponent）数量；
  - 定时器回调函数相关对象。

ASCII 图解：堆快照对比
Heap Snapshot 1 ( 第一次 5s 时 )   
┌─────────────────────────┐
│ VueComponent: 10 个     │
│ Closure: 5 个           │
│ TimerCallback: 1 个     │
└─────────────────────────┘
Heap Snapshot 2 ( 第二次 5s 时 )
┌─────────────────────────┐
│ VueComponent: 18 个 │ ← 比上次多 8 个，说明上次未释放
│ Closure: 10 个 │ ← 比上次多 5 个
│ TimerCallback: 2 个 │ ← 定时器回调累积
└─────────────────────────┘
图解示意（内存曲线对比）
 JS Heap (MB)
 40 ┤                                 ┌─────────
    │                              ┌──┘
    │                           ┌──┘
    │                        ┌──┘
    │                  ①    │     
 30 ┤     ┌───────────┘      │
    │     │                  │   ②
    │  ┌──┘                  │ ┌─┘
    │  │                     └─┘
    │──┴──────────────────────────────
      0s   2s   4s   6s   8s  时间（秒）

① 第一次进入 + GC 回收后，Heap 下降到 ~25MB  
② 第二次进入 + GC 回收后，Heap 下降到 ~28MB （残留泄漏）

通过曲线与快照对比，我们能够清晰地发现内存泄漏的位置——只要查到是哪种对象在不断累积，就能找到对应的代码闭包、事件监听或原生引用并进行修复。

七、综合解决策略与最佳实践

基于上述示例与分析，下面总结一套通用的内存泄漏防范与解决策略，在项目开发阶段即可应用，减少后续排查成本。

7.1 规范化生命周期管理

统一在 onUnload/beforeDestroy 销毁引用
- 对所有 setInterval、setTimeout、uni.request 回调、Promise 等可能持有页面上下文的引用，在 onUnload 中手动清理。
- 对所有 uni.$on、EventBus.$on、第三方库事件监听，在 onUnload/beforeDestroy 中 $off 或对应解绑 API。
- 对原生组件（Canvas、Map、Video）需要调用的销毁/清空方法，在 onUnload 调用。
避免在全局变量中存放大型数据
- 将真正需要跨页面共享的少量状态存入 Vuex、Pinia 或 uni.setStorageSync；
- 对可能无限增长的数据（日志、缓存数组）设置最大长度、过期时间，或在页面离开时及时清理。
慎重使用闭包
- 在方法内部定义匿名回调时，避免直接长时间持有 this；可考虑将逻辑拆分到独立函数，确保没有不必要的外部引用。
- 若必须使用闭包，应在引用结束后置空闭包变量，或者将长寿命回调限制在最小作用域。

7.2 按需加载与数据缓存策略

合理设置 List 数据量
- 对于长列表，尽量使用分页加载、虚拟列表（如 uni-virtual-list）等减缓内存压力；
- 清理离开页面时的列表数据，防止旧集合长时间驻留。
避免超大结构体传递
- 如果要在页面之间传递大型对象，尽量只传递 ID，再在目标页面根据 ID 异步拉取；
- 小程序传参（navigateTo）时要注意基于 URL 长度限制，若实在需要传递大对象，可先缓存到 uni.setStorageSync 或 Vuex，再在目标页面读取并清理。

7.3 优化原生组件使用

Canvas 及时清理
- 在 Canvas 绘制完成后，若无需再次使用，可先 clearRect 再销毁上下文；
- 避免在短时间内频繁创建大尺寸 Canvas，需要绘制时再创建、绘制完成后再销毁。
Map / Video / WebView
- 使用完毕后，尽量隐藏或销毁相关组件；若有 destroy() 或 clearCache() 等 API，要及时调用。

7.4 持续监控与自动化检测

CI/CD 集成打包与内存分析
- 在自动化构建流程中运行一次“预览构建 + 快照导出”脚本，并用工具生成报告；
- 设置阈值告警，例如 JS Heap 大于 30MB 或 Native Heap 大于 50MB 触发报警。
线上埋点内存指标
- 集成第三方监控 SDK，定期上报客户端内存使用情况；若发现某些机型/版本普遍内存使用过高，可重点排查相关业务逻辑。

八、总结

本文详细介绍了 uniapp 小程序可能出现的典型内存泄漏场景，包括定时器、事件监听、长列表持久数据、原生组件等方面的成因，并提供了相应的定位方法（Timeline、Heap Snapshot）与修复方案。通过对比堆快照与内存曲线，你可以快速找到“哪些对象在不断累积”、“是哪个闭包或事件监听没有被清理”，从而针对性地进行代码修复。

关键要点回顾：

及时清理定时器和回调闭包：在 onUnload 中 clearInterval、clearTimeout，将引用置空。
解绑全局事件监听：在 onUnload 或 beforeDestroy 中 $off。
避免过大数据驻留：对长列表、缓存数据要限制大小或生命周期。
原生组件手动销毁：Canvas、Map、Video 等组件在页面销毁时要调用清理或销毁接口。
善用调试工具：微信开发者工具及 Chrome DevTools 的内存分析面板，是快速定位泄漏的利器。

希望本文的代码示例、图解示意和详细说明，能帮助你在开发 uniapp 小程序时，更加高效地进行内存泄漏定位与解决，提升项目稳定性与用户体验。如果在实际项目中遇到其他特殊场景的问题，也可结合本文思路，灵活调整并进行验证。

一、引言

二、uniapp 小程序内存模型概述

2.1 JS 层与原生层内存

三、常见内存泄漏场景与成因

3.1 定时器（setInterval / setTimeout）未清除

3.2 事件监听（$on / $once / $off）未解绑

3.3 组件闭包、箭头函数、回调中引用外部变量

3.4 全局变量或单例缓存过度使用

3.5 原生组件（Map / Canvas / Video）未销毁

四、内存泄漏定位工具与方法

4.1 微信开发者工具 Performance 面板

4.2 HBuilderX + Chrome DevTools

4.3 console.memory（仅部分平台支持）

4.4 第三方内存监控插件

五、典型内存泄漏示例与修复方案

5.1 示例一：定时器未清除导致内存泄漏

故障代码

定位思路

修复方案

5.2 示例二：事件监听未解绑导致内存泄漏

故障代码

定位思路

5.3 示例三：长列表不停加载导致大对象驻留

故障代码

问题分析

定位思路

修复方案

5.4 示例四：原生组件（Canvas）未销毁导致 Native 内存泄漏

故障代码

问题分析

定位思路

修复方案

六、内存快照与曲线对比示例

七、综合解决策略与最佳实践

7.1 规范化生命周期管理

7.2 按需加载与数据缓存策略

7.3 优化原生组件使用

7.4 持续监控与自动化检测

八、总结

评论已关闭

推荐阅读

4.3 `console.memory`（仅部分平台支持）