19、WebRTC性能优化：延迟优化、CPU/GPU占用控制、内存管理

做WebRTC开发这几年，我踩过最多的坑，其实不是信令怎么设计，也不是媒体协商怎么搞。真正让人头疼的，是跑起来之后——卡顿、延迟高、CPU爆表、内存泄漏。用户不会管你用了什么协议，他只看到画面卡了，声音断了，体验就崩了。

所以这一章，我想跟你聊聊性能优化。说白了，就是三件事：延迟怎么压下去，CPU/GPU怎么省着用，内存怎么管住不乱涨。这三件事做好了，你的WebRTC应用才算真正能上线。

19.1 延迟优化：从采集到渲染，每一毫秒都要抠

延迟是实时通信的命门。我见过一个项目，端到端延迟做到800ms，用户直接投诉说“你们这是对讲机吗？” 后来我们硬是压到了150ms以内，体验才真正可用。

延迟的构成其实不复杂，我习惯把它拆成四个阶段：

• 采集延迟：摄像头/麦克风拿到数据的时间
• 编码延迟：压缩数据的时间
• 网络传输延迟：数据在网络上跑的时间
• 渲染延迟：解码+显示的时间

每个阶段都有优化空间，咱们一个一个说。

19.1.1 采集端：别让摄像头拖后腿

采集延迟往往被忽略。很多人上来就调编码器，结果发现摄像头本身就有延迟。我建议你这么做：

• 选对分辨率：不是越高越好。720p在大多数场景下足够，1080p的采集延迟可能多出20-30ms
• 降低帧率：30fps够用就别上60fps。帧率越高，每帧的处理时间越短，但CPU压力越大
• 用MediaCapture的约束：设置 width、height、frameRate 的精确值，别让浏览器自己猜

// 我常用的采集配置
const constraints = {
  video: {
    width: { ideal: 1280 },
    height: { ideal: 720 },
    frameRate: { ideal: 30 },
    // 关键：关闭自动对焦和自动白平衡，减少处理延迟
    advanced: [{ focusMode: "manual" }, { whiteBalanceMode: "manual" }]
  },
  audio: {
    echoCancellation: true,
    noiseSuppression: true,
    // 采样率别太高，16kHz够用
    sampleRate: { ideal: 16000 }
  }
};

19.1.2 编码端：硬件编码器是你的好朋友

编码是延迟的大头。软件编码器（如VP8、VP9的软件实现）虽然兼容性好，但延迟高、CPU占用大。我建议：

• 优先用硬件编码器：H.264硬件编码在大多数设备上都有，延迟比软件编码低30%-50%
• 调整编码参数：降低 keyFrameInterval，别让I帧间隔太长。我一般设到2秒
• 用Simulcast或SVC：别让编码器一次输出最高质量，分层编码能降低单帧处理时间

// 在RTCPeerConnection中设置编码参数
const transceiver = pc.getTransceivers()[0];
const sender = transceiver.sender;
const params = sender.getParameters();

// 设置编码优先级和码率
params.encoders[0].maxBitrate = 1000000; // 1Mbps
params.encoders[0].minBitrate = 200000;
params.encoders[0].scaleResolutionDownBy = 1.0; // 不降分辨率

// 关键：设置编码器的延迟模式
params.degradationPreference = "maintain-framerate"; // 优先保帧率

await sender.setParameters(params);

19.1.3 网络传输：JitterBuffer和FEC的平衡

网络延迟是客观存在的，我们能做的是减少它对体验的影响。这里有两个关键点：

• JitterBuffer大小：缓冲区越大，抗抖动能力越强，但延迟也越大。我建议动态调整，别用固定值
• FEC（前向纠错）：丢包率高的时候，FEC能减少重传，但会增加带宽和延迟。我一般丢包率超过5%才启用

WebRTC内部有自适应算法，但你可以通过 RTCRtpReceiver 的 getStats() 来监控，然后手动调整策略。

// 监控网络延迟和丢包
async function checkNetworkStats(pc) {
  const stats = await pc.getStats();
  stats.forEach(report => {
    if (report.type === 'inbound-rtp' && report.kind === 'video') {
      console.log(`延迟: ${report.jitter}ms, 丢包: ${report.packetsLost}`);
      // 如果丢包超过5%，可以考虑增加FEC
      if (report.packetsLost / report.packetsReceived > 0.05) {
        // 动态调整FEC
        console.log('丢包率过高，建议启用FEC');
      }
    }
  });
}

19.2 CPU/GPU占用控制：别让浏览器变成电暖器

CPU和GPU占用过高，不仅会导致卡顿，还会让设备发热、掉电。我见过一个案例，用户用笔记本开视频会议，风扇狂转，最后直接蓝屏了。嗯，这其实是可以避免的。

19.2.1 视频处理：能省则省

视频是CPU/GPU消耗的大户。我总结了几条“省电法则”：

• 降低分辨率：640x480在大多数场景下够用，别动不动就1080p
• 降低帧率：15fps的视频通话其实也能接受，30fps是上限
• 关闭不必要的处理：比如美颜、背景虚化，这些功能很吃GPU
• 用Canvas做缩放：如果摄像头输出分辨率太高，先用Canvas缩到目标大小，再传给编码器

// 用Canvas做视频缩放，减少编码器压力
function scaleVideoFrame(video, targetWidth, targetHeight) {
  const canvas = document.createElement('canvas');
  canvas.width = targetWidth;
  canvas.height = targetHeight;
  const ctx = canvas.getContext('2d');
  ctx.drawImage(video, 0, 0, targetWidth, targetHeight);
  return canvas.captureStream(30).getVideoTracks()[0];
}

19.2.2 音频处理：别小看那点CPU

很多人觉得音频不占资源，其实不然。音频的3A算法（回声消除、降噪、自动增益）在低端设备上能吃掉不少CPU。我建议：

• 关闭不必要的音频处理：如果环境安静，可以关掉降噪
• 降低采样率：16kHz够用就别上48kHz
• 用Opus的低复杂度模式：设置 complexity 为0-5，别用10

// 设置Opus编码器的低复杂度模式
const audioSender = pc.getSenders().find(s => s.track.kind === 'audio');
const audioParams = audioSender.getParameters();
audioParams.encoders[0].codecPayloadType = 111; // Opus
// 通过SDP参数设置复杂度
audioParams.encoders[0].parameters = {
  'complexity': '5', // 0-10，越低越省CPU
  'maxaveragebitrate': '32000' // 32kbps够用
};
await audioSender.setParameters(audioParams);

19.3 内存管理：别让内存泄漏毁了你的应用

内存泄漏是WebRTC开发中最隐蔽的问题。它不会立刻崩溃，但会随着时间推移，让应用越来越卡，最后OOM。我经历过一次线上事故，用户开视频会议2小时后，页面直接白屏。查了半天，发现是MediaStream没有释放。

19.3.1 及时释放MediaStream

这是最常见的泄漏点。每次创建 MediaStream 或 MediaStreamTrack，用完一定要释放。我习惯在组件卸载或通话结束时，统一清理。

// 清理MediaStream
function cleanupMediaStream(stream) {
  if (stream) {
    stream.getTracks().forEach(track => {
      track.stop(); // 停止轨道
      track.enabled = false; // 禁用轨道
    });
    stream = null; // 释放引用
  }
}

// 清理RTCPeerConnection
function cleanupPeerConnection(pc) {
  if (pc) {
    pc.getSenders().forEach(sender => {
      if (sender.track) {
        sender.track.stop();
      }
    });
    pc.close();
    pc = null;
  }
}

19.3.2 控制RTP缓冲区大小

WebRTC内部有RTP接收缓冲区，如果网络抖动大，缓冲区会不断增大，导致内存占用飙升。我建议：

• 设置合理的缓冲区上限：通过 RTCRtpReceiver 的 setParameters 控制
• 监控内存使用：用 performance.memory 或 chrome://memory-internals 定期检查
• 定期清理：如果发现内存持续增长，可以考虑重建PeerConnection

// 监控内存使用
function monitorMemory() {
  if (performance.memory) {
    const used = performance.memory.usedJSHeapSize;
    const total = performance.memory.totalJSHeapSize;
    console.log(`内存使用: ${(used / 1024 / 1024).toFixed(2)}MB / ${(total / 1024 / 1024).toFixed(2)}MB`);
    
    // 如果内存超过200MB，触发清理
    if (used > 200 * 1024 * 1024) {
      console.warn('内存占用过高，建议重建连接');
      // 触发重建逻辑
    }
  }
}

// 每30秒检查一次
setInterval(monitorMemory, 30000);

19.3.3 避免DOM元素泄漏

如果你用 <video> 或 <audio> 元素来渲染流，记得在不用的时候移除它们。DOM元素如果一直挂在页面上，即使流已经停止，内存也不会释放。

// 正确做法：移除DOM元素
function removeVideoElement(videoElement) {
  if (videoElement && videoElement.parentNode) {
    videoElement.pause();
    videoElement.srcObject = null; // 关键：解除流引用
    videoElement.parentNode.removeChild(videoElement);
  }
}

19.4 性能优化的整体策略

说了这么多，其实性能优化没有银弹。我习惯用一张图来梳理整体策略：

这张图是我自己总结的。你看，三个维度不是孤立的，它们互相影响。比如你为了降低延迟，用了更低的编码复杂度，CPU占用就下来了；但如果你为了省CPU，把分辨率降得太低，用户又会觉得画质差。所以，性能优化是一个不断权衡的过程。

19.5 实战建议：从监控开始

说了这么多理论，最后给你一个实战建议：先做监控，再做优化。没有数据，你根本不知道瓶颈在哪。

我习惯在项目中集成WebRTC的统计API，实时采集延迟、丢包、CPU、内存等指标。然后根据数据，动态调整参数。比如：

• 如果CPU超过50%，自动降低分辨率
• 如果延迟超过200ms，自动降低帧率
• 如果内存超过150MB，触发清理流程

这样做的好处是，你的应用能自适应不同的设备和网络环境。说白了，就是让代码自己学会“省着用”。

---

公众号:蓝海资料掘金营，微信deep3321