22、性能优化：内存管理、CPU使用优化、网络带宽优化、延迟优化策略

做WebRTC开发，性能优化是绕不开的坎。我见过太多项目，功能都跑通了，一上量就崩——要么内存爆了，要么CPU飙到90度，要么视频卡成幻灯片。说白了，WebRTC是个资源大户，不精心伺候着，它分分钟给你颜色看。

这一章，我把性能优化拆成四个维度来讲：内存、CPU、带宽、延迟。每个维度我都会结合自己踩过的坑，给你一些实战经验。

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

WebRTC的内存问题，说白了就是「谁分配了，谁释放」。我早期做的一个视频会议项目，跑了半小时内存就飙到2GB——查了半天，发现是MediaStream对象没有及时释放。

1. 缓冲区复用

每次编码都new一个缓冲区？那你的内存分配器会哭的。我建议用对象池模式：

// 不推荐：每次创建新缓冲区
function processFrame(frame) {
  const buffer = new ArrayBuffer(frame.width * frame.height * 4);
  // ...处理...
}

// 推荐：复用缓冲区
class FrameBufferPool {
  constructor(size) {
    this.pool = [];
    for (let i = 0; i < size; i++) {
      this.pool.push(new ArrayBuffer(1920 * 1080 * 4));
    }
  }
  
  acquire() {
    return this.pool.pop() || new ArrayBuffer(1920 * 1080 * 4);
  }
  
  release(buffer) {
    if (this.pool.length < 10) {
      this.pool.push(buffer);
    }
  }
}

2. 及时释放MediaStream资源

这个坑我踩过好几次。每次调用getUserMedia或getDisplayMedia，都会创建新的MediaStream。不用了就得手动停掉：

// 停止所有轨道
function stopMediaStream(stream) {
  if (!stream) return;
  stream.getTracks().forEach(track => {
    track.stop();
  });
  // 注意：还要释放对stream的引用
  stream = null;
}

3. 监控内存泄漏

怎么发现内存泄漏？我常用的方法：

• Chrome DevTools的Performance面板，录制一段操作，看内存曲线是否持续上升
• 用performance.memoryAPI定期采样（仅Chrome支持）
• 写一个简单的内存快照对比工具，每次关键操作后拍个快照

CPU使用优化：别让风扇转起来

CPU优化，说白了就是「少干活，干巧活」。WebRTC最吃CPU的就是编解码和渲染。

1. 编解码器选择

不同编解码器的CPU消耗差别很大。我做过实测对比：

编解码器	编码CPU消耗	解码CPU消耗	适用场景
VP8	低	低	移动端、低端设备
VP9	高	中	桌面端、带宽受限
H.264	中（硬件加速）	低（硬件加速）	大多数场景首选
AV1	极高	高	未来、高端设备

我个人习惯：移动端优先H.264（硬件加速），桌面端看情况选VP8或H.264。VP9和AV1虽然压缩率高，但CPU扛不住就别硬上。

2. 帧率与分辨率自适应

为什么要跑30fps？很多时候15fps就够了。我做过一个在线教育项目，老师讲课的视频，10fps完全够用，CPU直接降了40%。

// 根据CPU负载动态调整帧率
function adjustFrameRate(constraints, cpuLoad) {
  if (cpuLoad > 0.8) {
    // CPU快满了，降帧率
    return { ...constraints, frameRate: { ideal: 15, max: 20 } };
  } else if (cpuLoad > 0.6) {
    return { ...constraints, frameRate: { ideal: 24, max: 30 } };
  }
  return constraints;
}

3. 渲染优化

如果你用<video>标签渲染，注意几点：

• 不要同时渲染多个大尺寸视频，用object-fit: cover配合小尺寸canvas
• 离屏视频（比如9宫格中当前不活跃的）降低分辨率或暂停渲染
• 用requestAnimationFrame代替setInterval做渲染循环

网络带宽优化：在有限的管道里跑更多的数据

带宽优化，说白了就是「用好每一比特」。WebRTC内置了拥塞控制，但默认配置不一定适合你的场景。

1. 码率自适应

WebRTC的RTCRtpSender提供了setParameters方法，可以动态调整编码码率：

// 根据网络状况调整码率
function adaptBitrate(sender, estimatedBandwidth) {
  const params = sender.getParameters();
  if (!params.encodings) return;
  
  // 留20%余量给重传和FEC
  const targetBitrate = estimatedBandwidth * 0.8;
  
  params.encodings.forEach(encoding => {
    encoding.maxBitrate = targetBitrate;
  });
  
  sender.setParameters(params).catch(e => {
    console.warn('设置码率失败:', e);
  });
}

2. Simulcast与SVC

这两个技术都是为了解决「不同接收端带宽不同」的问题：

• Simulcast：同时发送多个分辨率的流，接收端选合适的。CPU消耗大，但灵活。
• SVC：一个流包含多个层，接收端根据带宽决定解码多少层。CPU消耗小，但浏览器支持有限。

我建议：如果目标用户主要是桌面端，用Simulcast；如果移动端多，用SVC（VP9支持较好）。

3. FEC与NACK策略

丢包了怎么办？两种思路：

策略	原理	带宽消耗	延迟
FEC（前向纠错）	发送冗余数据，接收端直接恢复	高（额外20-50%）	低
NACK（重传请求）	丢包后请求重传	低（仅丢包时消耗）	高（一个RTT）

延迟优化：让对话像面对面一样自然

延迟是WebRTC的终极挑战。端到端延迟超过300ms，对话就开始别扭了。

1. 抖动缓冲（Jitter Buffer）

网络有抖动，所以需要缓冲。但缓冲越大，延迟越大。WebRTC默认的抖动缓冲算法已经很好了，但你可以调整参数：

// 通过RTCRtpReceiver的配置调整抖动缓冲
const receiver = pc.getReceivers()[0];
// 注意：这个API在不同浏览器中可能不同
if (receiver.jitterBufferTarget) {
  // 设置目标延迟为100ms（默认通常200ms）
  receiver.jitterBufferTarget = 100;
}

2. 减少编解码延迟

编解码本身也有延迟。怎么优化？

• 使用硬件编解码（H.264/H.265硬件加速）
• 减少参考帧数量（VP8的cpu_used参数调大）
• 关闭B帧（B帧会引入额外延迟）

3. 网络路径优化

这个很多人忽略。WebRTC默认走P2P，但P2P路径不一定是最优的。我遇到过两个用户在同一栋楼，结果流量绕到国外再回来——延迟直接200ms+。

解决方案：

• 部署TURN服务器时，尽量靠近用户（多区域部署）
• 使用ICE的candidatePair选择策略，优先选延迟低的路径
• 考虑使用Selective Forwarding Unit（SFU）架构，由服务器做路由优化

4. 应用层优化

有时候延迟不是网络问题，是代码问题：

• 不要在ontrack回调里做耗时操作（解码、渲染是异步的）
• 使用Web Worker处理数据，避免阻塞主线程
• 音频和视频分开处理，音频优先（人耳对音频延迟更敏感）

总结：优化是个系统工程

性能优化没有银弹。内存、CPU、带宽、延迟四个维度相互影响——你降了CPU，可能带宽就上去了；你降了延迟，可能内存就爆了。我个人的优化流程是：

1. 先跑一轮性能基线，记录各项指标
2. 找到瓶颈（是CPU？内存？还是网络？）
3. 针对瓶颈做优化，每次只改一个变量
4. 重新跑基线，对比效果
5. 重复，直到满足目标

记住一句话：没有测量就没有优化。别凭感觉改代码，用数据说话。

---