3、内存管理优化：内存泄漏检测与修复、对象池模式、图片与资源缓存策略、GC调优

内存管理，说白了就是让你的应用「吃得少、拉得快」。我见过太多桌面应用，功能做得花里胡哨，结果跑半小时内存就飙到 2GB，用户直接崩溃。今天咱们就聊聊怎么把这摊子事理顺。

3.1 内存泄漏检测与修复

内存泄漏是什么？就是对象用完了，但垃圾回收器（GC）觉得它还有人用，死活不回收。我早期做的一个 IM 工具，用户反馈挂机一晚上内存涨了 300MB，查了半天，原来是聊天窗口关闭后，事件监听器没解绑。

常见泄漏场景

• 事件监听未移除：比如 addEventListener 后没有 removeEventListener
• 全局引用：把局部对象挂到了 window 或全局静态变量上
• 闭包滥用：闭包引用了外部函数的 DOM 元素，导致元素无法释放
• 定时器未清理：setInterval 或 setTimeout 没有 clear

检测工具

我个人习惯用 Chrome DevTools 的 Memory 面板。拍快照、做操作、再拍快照，对比看哪些对象没被回收。Electron 应用也可以用同样的方式，因为 Chromium 内核支持。

// 一个典型的泄漏案例
class ChatWindow {
  constructor() {
    this.element = document.getElementById('chat');
    // 问题：这里绑定了事件，但从未解绑
    document.addEventListener('click', this.onClick);
  }

  destroy() {
    // 修复：必须解绑
    document.removeEventListener('click', this.onClick);
    this.element = null;
  }
}

3.2 对象池模式

对象池是什么？就是提前创建一堆对象放池子里，用的时候拿，用完还回去，避免频繁创建和销毁。你想想看，如果每帧都要 new 一个粒子对象，GC 会疯掉的。

我做过一个实时数据可视化工具，每秒要渲染上千个数据点。如果每个点都 new 一个 Shape 对象，帧率直接掉到 10fps。用了对象池后，稳定在 60fps。

class ObjectPool {
  constructor(createFn, resetFn, initialSize = 50) {
    this.pool = [];
    this.createFn = createFn;
    this.resetFn = resetFn;
    // 预创建
    for (let i = 0; i < initialSize; i++) {
      this.pool.push(createFn());
    }
  }

  acquire() {
    if (this.pool.length > 0) {
      return this.pool.pop();
    }
    // 池子空了，动态创建
    return this.createFn();
  }

  release(obj) {
    this.resetFn(obj);
    this.pool.push(obj);
  }
}

// 使用示例
const bulletPool = new ObjectPool(
  () => new Bullet(),
  (bullet) => bullet.reset()
);

// 发射子弹时
const bullet = bulletPool.acquire();
bullet.fire(x, y);

// 子弹消失时
bulletPool.release(bullet);

3.3 图片与资源缓存策略

图片是内存大户。一张 1920x1080 的图片，解码后占多少内存？4 字节每像素，算下来 8MB。如果缓存 100 张，就是 800MB。嗯，这里要注意。

缓存策略

策略	说明	适用场景
LRU（最近最少使用）	淘汰最久没被访问的缓存	图片浏览、列表缩略图
LFU（最不经常使用）	淘汰访问频率最低的缓存	图标、固定资源
TTL（生存时间）	缓存过期后自动清除	网络请求结果、临时数据

我个人习惯用 LRU + 内存上限控制。比如设置最大缓存 50MB，超过就淘汰最旧的。Electron 里可以用 lru-cache 这个 npm 包，或者自己实现一个简单的。

class ImageCache {
  constructor(maxSize = 50 * 1024 * 1024) { // 50MB
    this.cache = new Map();
    this.maxSize = maxSize;
    this.currentSize = 0;
  }

  get(key) {
    if (!this.cache.has(key)) return null;
    // 更新访问顺序
    const value = this.cache.get(key);
    this.cache.delete(key);
    this.cache.set(key, value);
    return value;
  }

  set(key, image) {
    // 估算图片内存大小
    const size = image.width * image.height * 4;
    // 如果单张图片超过上限，直接不缓存
    if (size > this.maxSize) return;

    // 淘汰旧缓存，直到有足够空间
    while (this.currentSize + size > this.maxSize) {
      const oldestKey = this.cache.keys().next().value;
      const oldest = this.cache.get(oldestKey);
      this.currentSize -= oldest.width * oldest.height * 4;
      this.cache.delete(oldestKey);
    }

    this.cache.set(key, image);
    this.currentSize += size;
  }
}

3.4 GC调优

GC 调优，说白了就是让垃圾回收器少干活、干快活。V8 引擎的 GC 分新生代和老生代，新生代用 Scavenge 算法，老生代用 Mark-Sweep-Compact。但咱们开发者能做什么？

减少 GC 压力

• 避免频繁创建临时对象：比如在循环里 new 对象，尽量复用
• 使用对象池：上面讲过了，减少 GC 触发次数
• 合理设置内存上限：Electron 里可以通过 --max-old-space-size 设置
• 手动触发 GC：只在特定时机调用 global.gc()，比如窗口关闭后

// 在 Electron 主进程中设置内存上限
app.commandLine.appendSwitch('js-flags', '--max-old-space-size=1024'); // 1GB

// 手动触发 GC（需要开启 --expose-gc）
if (global.gc) {
  global.gc();
}

监控 GC 行为

怎么知道 GC 有没有问题？用 Chrome DevTools 的 Performance 面板，录制一段操作，看 GC 的耗时和频率。如果 GC 耗时超过 100ms，说明内存压力大了。

我记得有一次，一个 Electron 应用在用户操作时频繁卡顿。录了 Performance 一看，每 2 秒触发一次 Full GC，耗时 200ms。原因是一个全局的日志数组不断增长，没有清理。改成环形缓冲区后，GC 频率降到了每 30 秒一次。