Three.js 页面卡顿怎么办？内存泄漏排查与性能优化

一、卡顿诊断：定位 CPU 瓶颈与 GPU 显存泄漏

排查卡顿的第一步不是盲目修改渲染参数，而是用数据确认瓶颈发生在哪一个硬件环节。很多开发者容易将“算力过载”与“内存泄漏”混为一谈：算力过载会导致页面从一开始就帧率低下；而内存泄漏则表现为刚打开页面时帧率正常，随着模型切换、组件装载卸载或运行时间延长，帧率不可逆地持续衰减，最终触发浏览器崩溃或 WebGL 上下文丢失（WebGL Context Lost）。

1. 读取 WebGL 运行时状态：renderer.info

Three.js 的 WebGLRenderer 实例内置了 renderer.info 对象。这是监控运行时状态最轻量、最精确的切入点。建议在开发阶段将该对象打印到控制台，或挂载到页面的实时监控小面板中：

// 打印当前帧的 WebGL 状态
function logRendererInfo(renderer) {
  console.log('【显存对象】Geometries:', renderer.info.memory.geometries, 'Textures:', renderer.info.memory.textures);
  console.log('【当前帧渲染】Draw Calls:', renderer.info.render.calls, 'Triangles:', renderer.info.render.triangles);
}

通过监控上述四个数值，可以快速得出以下判断依据：

• Draw Calls (render.calls)：CPU 每次向 GPU 提交一次绘制指令就是一个 Draw Call。如果 PC 端单帧超过 200 次，或移动端超过 100 次，CPU 主线程在准备 WebGL 状态切换时就会发生严重阻塞。
• 三角面数 (render.triangles)：常规 WebGL 页面建议控制在数十万面以内。若面数达到数百万级且伴随多光源实时计算，GPU 顶点着色器和像素着色器将承受超额计算负荷。
• 显存对象统计 (memory.geometries 与 memory.textures)：在场景切换、销毁模型或重新加载数据后观察这两个数值。如果模型已被 scene.remove()，但 geometries 或 textures 数量没有减少，说明底层的 GPU 显存仍然处于泄漏状态。

2. 借助 Chrome DevTools 区分瓶颈属性

当帧率下降时，打开 Chrome DevTools 的 Performance 面板录制 3 到 5 秒：

• 如果主线程（Main）出现大量红色长任务（Long Task）：耗时多分布在 Animation Frame Fired、射线检测 raycaster.intersectObjects() 或频繁的矩阵更新 updateMatrixWorld 上，这属于 CPU 算力瓶颈。
• 如果主线程单帧执行时间很短（例如不足 5ms），但帧率依然只有 20~30 FPS：说明瓶颈在 GPU 端，通常是片元着色器计算过重、阴影贴图分辨率过大或后处理通道层层嵌套所致。

排查 JavaScript 堆内存泄漏时，使用 Memory 面板录制 Heap Snapshot（堆快照）。在页面切换前录制快照 1，在卸载 3D 组件后录制快照 2，并在 Class Filter 中搜索 Mesh、BufferGeometry 或 Material。如果在快照 2 中依然能检索到已卸载模型的实例，说明应用存在全局引用未断开。

二、内存泄漏的本质：JS 堆内存与 GPU 显存的生命周期断层

在标准的 JavaScript 编程中，开发者习惯了垃圾回收机制（GC）的存在：只要一个对象断开所有引用，V8 引擎就会在适当时机自动释放其内存。但在 WebGL 和 Three.js 的世界中，这种直觉会导致严重的显存泄漏。

1. 为什么 scene.remove(mesh) 无法释放显存？

执行 scene.remove(mesh) 仅仅是将网格对象从场景图（Scene Graph）的层级树中剔除。这只是断开了父子层级的 JavaScript 引用关系。

然而，网格底层的几何体数据（顶点坐标、法线向量、UV 纹理坐标）早已通过 gl.bufferData() 上传到了显卡显存；材质中绑定的各种贴图，也早已通过 gl.texImage2D() 载入了 GPU 纹理显存中。浏览器的 JavaScript 垃圾回收器完全无法感知，也无权触碰独立显卡硬件显存中的数据。只要不向底层发送明确的 WebGL 销毁指令，显卡驱动就会一直常驻保留这些数据。

三、彻底解决内存泄漏：深度递归销毁标准规范

要实现真正的显存回收，必须对场景对象进行深度递归遍历，将网格节点、几何体、各种材质以及材质关联的所有贴图依次调用 .dispose() 方法。

1. 通用递归销毁函数实现

以下是经过工程验证的健壮销毁函数。该函数不仅处理了单个材质，还兼容材质数组（多材质模型），并对材质所挂载的所有纹理属性（map、normalMap、roughnessMap 等）进行了安全检测与释放：

/**
 * 深度递归销毁 Three.js 3D 节点及其全部子孙资源的显存占用
 * @param {THREE.Object3D} obj 需要销毁的目标对象（Mesh、Group 或 Scene）
 */
function disposeHierarchy(obj) {
  if (!obj) return;

  // 递归清理所有子对象
  while (obj.children.length > 0) {
    disposeHierarchy(obj.children[0]);
    obj.remove(obj.children[0]);
  }

  // 1. 释放几何体显存
  if (obj.geometry) {
    obj.geometry.dispose();
  }

  // 2. 释放材质及绑定的贴图显存
  if (obj.material) {
    // 材质可能是单个实例，也可能是材质数组
    const materials = Array.isArray(obj.material) ? obj.material : [obj.material];

    materials.forEach((mat) => {
      if (!mat) return;

      // 遍历材质对象的所有属性，检索所有绑定的 Texture 实例并释放
      Object.keys(mat).forEach((prop) => {
        const value = mat[prop];
        if (value && typeof value === 'object' && typeof value.dispose === 'function') {
          // 排除非纹理的可处置对象或防止环形引用
          if (value.isTexture) {
            value.dispose();
          }
        }
      });

      // 释放材质着色器程序与内部显存
      mat.dispose();
    });
  }
}

2. 组件卸载时的完整注销流程

在单页应用（Vue/React）中，当离开 3D 页面组件时，仅清理场景对象是不够的，还需要停止帧循环并注销渲染器：

function destroyThreePage(scene, renderer, animationFrameId) {
  // 1. 立即停止 requestAnimationFrame 循环，防止空帧持续渲染
  if (animationFrameId) {
    cancelAnimationFrame(animationFrameId);
  }

  // 2. 执行场景递归显存释放
  disposeHierarchy(scene);

  // 3. 清理渲染器与 WebGL 上下文
  if (renderer) {
    renderer.dispose();
    renderer.forceContextLoss(); // 强制通知 GPU 释放当前上下文资源
    if (renderer.domElement && renderer.domElement.parentNode) {
      renderer.domElement.parentNode.removeChild(renderer.domElement);
    }
    renderer.domElement = null;
  }

  // 4. 清理解绑全局事件（如 resize、mousemove、pointerdown 等）
  window.removeEventListener('resize', onWindowResize);
}

四、运行时性能优化：压降 Draw Calls 与渲染负载

解决了内存泄漏后，如果页面仍然感到卡顿，则说明每一帧的实时运算量超出了设备的处理能力。优化的核心目标是：用最少的 Draw Calls、最轻量的几何体和最小的着色器开销，完成同等的视觉呈现。

1. 使用 InstancedMesh 替代海量独立 Mesh

很多新手在生成上千个相同模型（如建筑群、粒子、森林或散落的几何零件）时，会循环创建多个 new THREE.Mesh(geometry, material)。这种做法会导致 1000 个物体产生 1000 次 Draw Calls，直接将 CPU 拖垮。

优化方案：使用 THREE.InstancedMesh。它允许通过单次 Draw Call 绘制成千上万个几何结构相同、仅位置和颜色不同的模型实例：

// 优化前：1000 个独立 Mesh 产生 1000 次 Draw Call（严重卡顿）
// 优化后：使用 InstancedMesh 仅产生 1 次 Draw Call
const count = 1000;
const geometry = new THREE.BoxGeometry(1, 1, 1);
const material = new THREE.MeshStandardMaterial({ color: 0x687D8D });
const instancedMesh = new THREE.InstancedMesh(geometry, material, count);

const dummy = new THREE.Object3D();
for (let i = 0; i < count; i++) {
  dummy.position.set(
    (Math.random() - 0.5) * 50,
    (Math.random() - 0.5) * 50,
    (Math.random() - 0.5) * 50
  );
  dummy.rotation.set(Math.random() * Math.PI, Math.random() * Math.PI, 0);
  dummy.updateMatrix();
  instancedMesh.setMatrixAt(i, dummy.matrix);
}

// 必须标记变换矩阵需要上传至 GPU
instancedMesh.instanceMatrix.needsUpdate = true;
scene.add(instancedMesh);

2. 静态几何体合并：BufferGeometryUtils.mergeGeometries

如果场景中有许多位置固定、不再移动但形状各异的静态小物体，可以使用 Three.js 扩展库中的 BufferGeometryUtils.mergeGeometries 将它们合并为一个大的几何体。合并后物体数量缩减为一个单一网格，从而将数十甚至数百次 Draw Call 缩减为 1 次。

适用边界注意：合并后的几何体不能再独立移动、旋转或缩放单个子部件。因此，该技术仅适用于纯静态场景元素（如不可破坏的地形地貌、固定管线与静态背景设施）。

3. 按需渲染（On-Demand Rendering）：停止无效的死循环

常规的 3D 项目教程通常使用无休止的 requestAnimationFrame 循环：

function animate() {
  requestAnimationFrame(animate);
  renderer.render(scene, camera);
}

如果你的页面是一个展品展示、数据可视化大屏或 3D 编辑器，用户没有操作且没有动画时，画面是完全静止的。每秒依然强制重绘 60 次是在浪费宝贵的 CPU 和 GPU 资源，也是移动端发热、电量消耗过快的元凶。

优化方案：改用事件驱动的按需渲染。只有在视角旋转、模型缩放或数据更新时，才触发一次 render()：

const controls = new OrbitControls(camera, renderer.domElement);

// 只有当相机移动或物体被操作时才执行渲染
controls.addEventListener('change', () => {
  renderer.render(scene, camera);
});

// 首次加载初始化渲染一帧
renderer.render(scene, camera);

4. 纹理与贴图规格控制

• 尺寸必须为 2 的幂次方（POT）：例如 512×512、1024×1024、2048×2048。如果上传了非 2 的幂尺寸（NPOT，如 1200×800），WebGL 在生成 mipmaps 时必须在 CPU 中对图像进行强制拉伸重采样，极度消耗启动时间与显存。
• 移动端切忌滥用 4K 贴图：一张未压缩的 4096×4096 RGBA 贴图在解压入显存后，实际占用高达 64 MB 显存。若材质中包含法线、粗糙度、金属度等四五张贴图，单个模型就会吞噬数百兆显存。
• 使用 KTX2 / Basis Universal GPU 压缩纹理：通过压缩纹理格式，数据无需在内存中解码为原始位图，可直接被显卡识别渲染，能够节省 70% 以上的显存空间并大幅缩减加载白屏时间。

五、性能指标对比与项目自查清单

下表总结了优化前后核心性能维度的表现对比，可作为上线前的评估指标参考：