21、性能调试：使用 Performance API 测量 WebRTC 函数执行时间，分析帧处理瓶颈

做 WebRTC 开发，最怕什么？

我个人最怕的就是「画面卡了，但不知道卡在哪」。帧率掉到 15fps，编码器说它很忙，渲染线程说它在等数据，网络模块说它早就发出去了…… 到底谁在拖后腿？

嗯，这时候就需要一把「手术刀」—— Performance API。它能精确测量每个函数的执行时间，帮我们把瓶颈从黑盒里挖出来。

为什么不用 console.time？

很多同学习惯用 console.time('encode') 和 console.timeEnd('encode') 来测时间。说实话，简单场景够用。但 WebRTC 的帧处理是毫秒级甚至微秒级的竞争，console.time 的精度和侵入性都不太够。

Performance API 的优势在于：

• 高精度：精度可达微秒级（performance.now() 返回 DOMHighResTimeStamp）
• 低侵入：可以标记、测量，而不影响原有逻辑
• 可组合：支持异步任务、嵌套测量、自定义标记
• 可导出：能生成 Performance Timeline，配合 Chrome DevTools 的 Performance 面板分析

核心 API 速览

我们主要用这三个方法：

方法	作用	使用场景
performance.mark()	打一个时间戳标记	标记「开始编码」「结束编码」
performance.measure()	计算两个标记之间的耗时	测量「编码耗时」「渲染耗时」
performance.getEntriesByType()	获取所有标记或测量结果	导出数据做统计或可视化

另外，performance.now() 可以随时取当前时间戳，适合在循环或回调里做差值计算。

实战：测量 WebRTC 帧处理流水线

假设我们有一个典型的帧处理流程：

1. 从摄像头获取帧（getUserMedia）
2. 送入编码器（RTCRtpSender 或自定义编码）
3. 编码完成后发送
4. 接收端解码并渲染

我们可以在关键节点打标记，然后测量每个阶段的耗时。

代码示例：标记帧处理阶段

// 假设有一个帧处理函数
function processFrame(frame) {
  // 标记开始
  performance.mark('frame-start');

  // 模拟编码（实际可能是 encoder.encode()）
  encodeFrame(frame);

  // 标记编码结束
  performance.mark('frame-encode-end');

  // 模拟发送
  sendFrame(frame);

  // 标记发送结束
  performance.mark('frame-send-end');

  // 测量编码耗时
  performance.measure('编码耗时', 'frame-start', 'frame-encode-end');

  // 测量发送耗时
  performance.measure('发送耗时', 'frame-encode-end', 'frame-send-end');

  // 清理标记（避免内存泄漏）
  performance.clearMarks('frame-start');
  performance.clearMarks('frame-encode-end');
  performance.clearMarks('frame-send-end');
}

获取并分析测量结果

// 在需要的时候（比如每 100 帧）导出数据
function reportPerformance() {
  const measures = performance.getEntriesByType('measure');
  measures.forEach(m => {
    console.log(`${m.name}: ${m.duration.toFixed(2)}ms`);
  });

  // 也可以计算平均值
  const encodeMeasures = measures.filter(m => m.name === '编码耗时');
  const avgEncode = encodeMeasures.reduce((sum, m) => sum + m.duration, 0) / encodeMeasures.length;
  console.log(`平均编码耗时: ${avgEncode.toFixed(2)}ms`);

  // 清理所有测量结果
  performance.clearMeasures();
}

分析帧处理瓶颈的常见模式

我在项目中遇到过几次典型的瓶颈，分享出来供你参考：

模式一：编码耗时突增

正常情况下，H.264 编码一帧 720p 大概在 5~15ms。如果突然跳到 50ms+，多半是：

• CPU 被其他任务抢占（比如同时在做人脸检测）
• 编码器内部缓冲区满了，在等待 I 帧刷新
• 分辨率或码率动态调整导致编码器重置

我曾经遇到过一个 case：编码耗时从 8ms 飙升到 120ms，查了半天发现是某个第三方 SDK 在后台做了大量日志写入，导致 CPU 降频。用 Performance API 一测就锁定了问题。

模式二：渲染线程阻塞

接收端解码后，渲染到 canvas 或 video 标签时，如果 requestAnimationFrame 回调里做了重计算，就会阻塞渲染。测量方法：

function renderFrame(frame) {
  performance.mark('render-start');
  // 渲染逻辑
  drawFrame(frame);
  performance.mark('render-end');
  performance.measure('渲染耗时', 'render-start', 'render-end');
  performance.clearMarks('render-start');
  performance.clearMarks('render-end');
}

如果渲染耗时超过 16ms（60fps 的帧间隔），画面就会掉帧。这时候需要把非渲染任务（比如统计、日志）放到 setTimeout 或 requestIdleCallback 里。

模式三：网络发送排队

发送端调用 RTCRtpSender.send() 后，数据可能不会立即发出，而是进入 ICE 或 DTLS 的发送队列。测量方法：

performance.mark('send-queue-start');
sender.send(frame);
performance.mark('send-queue-end');
performance.measure('发送排队耗时', 'send-queue-start', 'send-queue-end');

如果这个耗时持续增长，说明发送队列在堆积，可能是带宽不足或对端接收窗口满了。

可视化：帧处理流水线

下面这张图展示了完整的帧处理流水线，以及我们可以在哪些节点打标记：

避坑指南

进阶：结合 Performance Observer

如果你不想手动调用 getEntriesByType，可以用 PerformanceObserver 自动监听测量事件：

const observer = new PerformanceObserver((list) => {
  const entries = list.getEntries();
  entries.forEach(entry => {
    if (entry.entryType === 'measure') {
      console.log(`[自动上报] ${entry.name}: ${entry.duration.toFixed(2)}ms`);
    }
  });
});
observer.observe({ entryTypes: ['measure'] });

这样每次调用 performance.measure() 时，回调会自动触发，适合做实时监控或上报到远端。

总结

Performance API 是 WebRTC 性能调试的「标配工具」。它不复杂，但用好了能帮你快速定位帧处理瓶颈是在编码、渲染还是网络。我个人建议在开发阶段就埋好标记点，上线后配合采样上报，这样线上问题也能快速复现。

嗯，记住一句话：没有测量就没有优化。先搞清楚时间花在哪，再动手改代码。