28、WebRTC性能优化：内存管理、CPU占用优化、渲染性能调优

性能优化这件事，说白了就是跟资源较劲。内存、CPU、渲染，这三座大山压着，任何一个扛不住，你的实时通信体验就会崩。我这些年做WebRTC项目，踩过的坑不少，今天就把压箱底的经验掏出来聊聊。

一、内存管理：别让浏览器吃掉你的内存

内存泄漏是WebRTC应用中最隐蔽的杀手。我接手过一个项目，通话半小时后内存占用飙到2GB，用户直接卡死。查了半天，原来是MediaStream对象没有及时释放。

1.1 缓冲区控制

视频帧缓冲区是内存消耗大户。默认情况下，WebRTC会缓存大量帧用于抖动缓冲。但如果你不做限制，内存会像漏水的桶一样。

// 设置合理的缓冲区大小
const config = {
  iceServers: [{ urls: 'stun:stun.l.google.com:19302' }],
  // 限制接收缓冲区
  rtcpMuxPolicy: 'require',
  bundlePolicy: 'max-bundle'
};

// 手动控制抖动缓冲区
const pc = new RTCPeerConnection(config);
pc.ontrack = (event) => {
  // 限制视频帧缓冲
  event.receiver.jitterBufferTarget = 100; // 毫秒
};

1.2 对象池复用

每次创建新的RTCDataChannel或MediaStream都会产生对象分配开销。用对象池可以显著降低GC压力。

class StreamPool {
  constructor(maxSize = 10) {
    this.pool = [];
    this.maxSize = maxSize;
  }

  acquire() {
    if (this.pool.length > 0) {
      return this.pool.pop();
    }
    return null; // 池空时创建新对象
  }

  release(stream) {
    if (this.pool.length < this.maxSize) {
      // 清理流状态
      stream.getTracks().forEach(track => track.stop());
      this.pool.push(stream);
    }
  }
}

1.3 内存泄漏检测

我曾经犯过一个低级错误：在组件卸载时忘了关闭PeerConnection。结果每次页面切换都留下一个僵尸连接。

// 组件销毁时一定要清理
componentWillUnmount() {
  if (this.pc) {
    this.pc.close();
    this.pc = null;
  }
  if (this.localStream) {
    this.localStream.getTracks().forEach(track => track.stop());
    this.localStream = null;
  }
}

二、CPU占用优化：让编解码器喘口气

CPU是WebRTC的命门。编解码、降噪、回声消除，哪个都在吃CPU。我见过一个项目在低端手机上CPU占用冲到90%，通话直接变幻灯片。

2.1 编解码器选择

VP8和H.264的CPU消耗差异很大。VP8在软件编码上更友好，H.264硬件加速支持更好。

编解码器	软件编码CPU占用	硬件加速支持	推荐场景
VP8	中等	部分支持	通用场景、低端设备
H.264	较高	广泛支持	移动端、硬件加速设备
VP9	高	有限支持	高画质需求、桌面端
AV1	极高	极少支持	未来场景、实验性项目

2.2 分辨率动态调整

别傻傻地一直用1080p。根据网络状况和CPU负载动态调整分辨率，这是基本功。

// 动态调整分辨率
function adjustResolution(pc, cpuUsage) {
  const sender = pc.getSenders()[0];
  if (!sender) return;

  let params = sender.getParameters();
  if (!params.encodings) params.encodings = [{}];

  if (cpuUsage > 0.8) {
    // CPU过载，降分辨率
    params.encodings[0].scaleResolutionDownBy = 2.0; // 降到480p
  } else if (cpuUsage > 0.5) {
    params.encodings[0].scaleResolutionDownBy = 1.5; // 降到720p
  } else {
    params.encodings[0].scaleResolutionDownBy = 1.0; // 保持1080p
  }

  sender.setParameters(params);
}

2.3 帧率控制策略

帧率不是越高越好。30fps和15fps在视觉上差别不大，但CPU消耗差一倍。

// 根据场景调整帧率
const frameRateConfig = {
  'video-conference': { maxFramerate: 24 },
  'screen-share': { maxFramerate: 15 },
  'low-bandwidth': { maxFramerate: 10 }
};

// 设置帧率限制
const constraints = {
  video: {
    frameRate: { ideal: 24, max: 30 },
    width: { ideal: 1280 },
    height: { ideal: 720 }
  }
};

三、渲染性能调优：别让UI拖后腿

渲染优化往往被忽视。你想想看，CPU和内存都优化好了，结果渲染掉帧，用户照样骂你卡。

3.1 Canvas vs WebGL

渲染视频帧时，WebGL比Canvas2D快3-5倍。我做过对比测试，在4路视频流场景下，Canvas2D的帧率只有12fps，WebGL能跑到30fps。

// WebGL渲染视频帧
function renderVideoFrame(gl, video, texture) {
  gl.bindTexture(gl.TEXTURE_2D, texture);
  gl.texImage2D(
    gl.TEXTURE_2D,
    0,
    gl.RGBA,
    gl.RGBA,
    gl.UNSIGNED_BYTE,
    video
  );
  gl.drawArrays(gl.TRIANGLE_STRIP, 0, 4);
}

3.2 离屏渲染

把视频帧先渲染到离屏Canvas，再一次性绘制到主Canvas。这样可以减少主线程的绘制次数。

// 离屏渲染优化
const offscreenCanvas = document.createElement('canvas');
const offscreenCtx = offscreenCanvas.getContext('2d');

function renderOffscreen(videoElement) {
  // 在离屏Canvas上绘制
  offscreenCtx.drawImage(videoElement, 0, 0, width, height);
  
  // 一次性复制到主Canvas
  mainCtx.drawImage(offscreenCanvas, 0, 0);
}

3.3 合成层优化

利用CSS的will-change和transform，让浏览器把视频元素提升到合成层。这样视频渲染不会触发重排。

/* 视频元素合成层优化 */
.video-stream {
  will-change: transform;
  transform: translateZ(0);
  /* 或者使用 */
  contain: layout style paint;
}

3.4 帧缓冲管理

渲染队列的长度要控制好。我见过一个项目，渲染队列堆积了200帧，用户看到的画面延迟了6秒。

// 帧缓冲控制
class FrameBuffer {
  constructor(maxSize = 3) {
    this.buffer = [];
    this.maxSize = maxSize;
  }

  push(frame) {
    if (this.buffer.length >= this.maxSize) {
      // 丢弃最旧的帧
      this.buffer.shift();
    }
    this.buffer.push(frame);
  }

  pop() {
    return this.buffer.shift();
  }
}