查看 peerconnection 耗时需使用 chrome devtools 的 performance 面板录制，并配合 rtcpeerconnection 的事件监听来标记关键阶段。具体做法是：在页面加载或调用 createoffer/createanswer 前开始录制，通过 oniceconnectionstatechange、onsignalingstatechange 以及自定义的 performance.mark() 记录信令交换和 ice 收集完成的时间点。分析时，重点观察 scripting 线程中这些标记之间的时间差，以及网络请求（network）中 stun/turn 查询的往返延迟。
如何准确标记信令与 ICE 收集的起止点？
要准确测量信令生成和 ICE 候选收集的具体耗时，必须在代码中手动插入性能标记。默认情况下，DevTools 只能看到通用的脚本执行时间，无法区分 createOffer 内部的处理细节。通过在调用核心 API 前后使用 performance.mark()，可以在 Performance 面板的时间轴上创建可视化的参考线，从而精确计算每个阶段的持续时间。
// 伪代码示例：标记信令与ICE过程
const pc = new RTCPeerConnection(config);
performance.mark('start-offer');
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
performance.mark('end-offer');
// 监听ICE状态变化以标记结束
pc.onicecandidate = (e) => {
if (!e.candidate) {
performance.mark('ice-gathering-complete');
// 此时可以计算从 start-offer 到 ice-gathering-complete 的总耗时
}
};
上述代码展示了如何在 createOffer 前后添加标记。当 onicecandidate 触发且 e.candidate 为 null 时，表示本地候选收集完成。此时，开发者可以在 Performance 面板中选中这两个标记，查看它们之间的火焰图详情，识别出是在 CPU 密集型的序列化过程耗时较长，还是在等待网络响应上阻塞。
立即学习“Java免费学习笔记（深入）”；
ICE 候选收集慢通常由哪些网络因素导致？
如果性能分析显示 ICE 收集阶段耗时过长，通常是因为 STUN/TURN 服务器的网络延迟高或连接被防火墙拦截。在 Performance 面板中，需要结合 Network 面板查看相关的 UDP 数据包交互。若发现大量的超时重传或长时间的空闲等待，说明客户端与中继服务器之间的链路存在瓶颈。
// 优化配置示例：指定高效的 TURN 服务器
const config = {
iceServers: [
{ urls: 'stun:stun.l.google.com:19302' },
{
url: 'turn:your-turn-server.com',
username: 'user',
credential: 'pass'
}
]
};
const pc = new RTCPeerConnection(config);
通过调整 iceServers 配置，可以使用更靠近用户的 STUN 服务器或可靠的 TURN 中继。在性能分析中，对比优化前后的 ice-gathering-complete 标记时间点，可以验证网络路径优化是否有效减少了候选收集的延迟。同时，检查是否有大量 host 候选失败，转而依赖 relay 候选，这通常是 NAT 类型复杂导致的额外开销。
PeerConnection 状态变更事件对性能分析有何影响？
RTCPeerConnection 的状态变更事件（如 iceconnectionstatechange）本身执行开销极小，但它们触发的回调函数如果包含复杂逻辑，会在 Performance 面板的 Scripting 列产生明显的峰值。分析时需关注这些事件触发时的调用栈，避免在状态回调中进行同步阻塞操作或大量 DOM 更新，否则会导致主线程卡顿，间接影响媒体流的处理性能。
