2.3 轨道管理与设备热切换

2.3 轨道管理与设备热切换

本节摘要：轨道拿到手只是上半场，通话几十分钟里用户会静音、关摄像头、换耳机、插拔设备，每一次都是对轨道管理的考试。本节讲清 enabled 与 stop 的本质区别——前者是「闭嘴但活着」，后者是「离开并不可逆」——以及 replaceTrack 如何做到换流不断线、设备枚举事件如何接住热插拔。这一节是采集关的售后条款，也是第 6 章动态降级的技术储备。

目标清单

阅读完本节，你应当能够：

1. 说清 track.enabled = false 与 track.stop() 在设备占用、指示灯、可恢复性上的差异；
2. 实现麦克风静音与摄像头关闭，并同步对端「对方已静音」的界面状态；
3. 用 replaceTrack 在通话中切换摄像头或降码率，对端无感、协商不动；
4. 监听 devicechange 事件与设备枚举联动，接住耳机拔插与摄像头掉线；
5. 处理设备消失导致的轨道静默死亡，设计通话不中断的恢复路径。

一、问题与直觉：静音为什么不是关掉

产品里最常见的需求是「静音按钮」。不少实现直接调 track.stop()，结果指示灯熄了、但再次开麦要重新走授权，甚至重新协商。正确的模型是把轨道想成一条持续供水的水管：enabled = false 是在管口装了个阀门——水厂还在供水（设备还被占用、指示灯还亮着），但出口没水；stop() 是把管子剪断——水流彻底停止，设备释放，而剪断的管子接不回去。

为什么浏览器要这样设计？因为用户的信任建立在「我看得见设备在什么时候开着」上。摄像头指示灯亮着却传不出有效画面，是所有视频产品都要面对的信任考题：enabled = false 时轨道仍在采集，只是发送静音帧与黑帧。产品层面的正确应对不是回避，而是明确告知——静音状态在两端都要有清晰的视觉标识，让「灯亮但静音」成为可理解的常态而非隐私疑云。

二、核心原理：三个管理动作与两个事件

动作一：阀门式静音。 一行代码，随时可逆：

// 静音与恢复：轨道活着，设备未释放
micTrack.enabled = false;   // 对端收到静音帧
camTrack.enabled = false;   // 对端收到黑帧，指示灯仍亮
// 对端如何得知「对方静音了」：监听轨道的 mute 与 unmute 事件
remoteTrack.addEventListener('mute', () => showPeerMuted(true));
remoteTrack.addEventListener('unmute', () => showPeerMuted(false));
​

mute 与 unmute 事件在两端各有一次投递：本端 enabled 改变时本端轨道发事件，对端轨道在收到静音帧或黑帧后也发同名事件——对端 UI 就靠它变灰。注意静音帧到达对端有一瞬间延迟，UI 切换的节奏要与之一致，避免「按钮已灰、画面未灰」的错位感。

动作二：剪断式停止。 stop() 释放设备，轨道进入 ended 终态，不可复用。要再采集，必须重新 getUserMedia 拿新轨道；如果这条轨道已经 addTrack 进了连接，重新采集后还要用 replaceTrack 把新轨道塞回原发送器——这就引出动作三。

动作三：无缝替换。 replaceTrack 在不重新协商的前提下换掉发送内容：

// 通话中从摄像头切到屏幕共享：对端画面切换，连接不断
const sender = pc.getSenders().find((s) => s.track && s.track.kind === 'video');
const shareStream = await navigator.mediaDevices.getDisplayMedia({ video: true });
await sender.replaceTrack(shareStream.getVideoTracks()[0]);
// 切回摄像头同理：sender.replaceTrack(camTrack)
// 旧轨道不再发送，记得按需 stop 释放屏幕共享
​

replaceTrack 的内部机制值得说一句：协商时 SDP 里已经写死了「这条 m 行发视频、用什么编码」，替换轨道只要参数兼容（同为视频、分辨率相近）就不必重谈。它是第 6 章动态降级的基石——把高清轨换成低清轨，本质就是一次 replaceTrack。

事件一：devicechange。 设备插拔时整个系统触发：

navigator.mediaDevices.addEventListener('devicechange', async () => {
  const devices = await navigator.mediaDevices.enumerateDevices();
  refreshDevicePicker(devices);   // 重新渲染设备选择列表
});
​

事件二：轨道之死。 用户拔掉正在采集的耳机，那条音频轨道不会抛异常，而是安静地发 ended 事件（部分平台表现为 mute 长挂）。恢复路径是标准的组合拳：devicechange 里发现新设备出现后，重新采集并 replaceTrack 回发送器，通话全程不中断。写成伪流程就是：ended → 提示用户 → 等待 devicechange → 重新采集 → replaceTrack。

💡 关键直觉：把通话中的轨道管理想成舞台换景——replaceTrack 是换布景不熄灯，stop 是拉闸散场。观众（对端）体验好坏，取决于你选哪个。

三、工程实践要点：换耳机的完整恢复链

设备热切换在生产环境的状态组合很碎，值得给出一个完整的案例拆解。

完整案例：会议中拔掉 USB 耳机

背景：用户在一场小时级会议中段拔掉 USB 耳机，改用笔记本内置麦克风与扬声器。若无处理，他从此变成「被静音的人」——自己说话别人听不见，且没有任何报错。

操作：客户端做了三层防护。第一层，音频轨道监听 ended，触发后立即在界面上提示「麦克风已断开，正在尝试恢复」，同时把本端按钮置为不可用态；第二层，devicechange 触发后用 enumerateDevices 比对前后快照，找到新出现的音频输入设备；第三层，用新 deviceId 重新 getUserMedia，成功后对原 sender 执行 replaceTrack，并恢复按钮状态。三层各司其职：提示归 UI，发现归枚举，恢复归替换。

结果：拔插耳机全程会议不断线，恢复耗时约一到两秒，与会者最多看到该用户短暂静音图标。极端情形——新设备采集失败（设备被其他应用锁死）——则回落为「提示用户手动在设置里选择设备」，降级路径同样清晰。

解读：这个案例的工程要义是「设备生命周期与通话生命周期解耦」：设备会来会走，通话必须常在。把恢复动作做成状态机（断开、等待、恢复、失败兜底）而不是一行 try-catch，是因为每一步都可能失败，失败后都要有下一步。很多产品在这里翻车，不是不知道事件，而是只做了第一层提示、没做第三层恢复。

变式：如果产品要求「切换到新耳机后自动选中它」，比对快照时把「新出现的默认设备」也纳入决策——enumerateDevices 返回的 deviceId 为 default 的条目代表系统默认，重新采集时优先用它即可实现「插上新耳机自动切过去」。再进一步，视频设备的热切换（会议室摄像头被碰掉）用同一套状态机，只是把音频轨换成视频轨，逻辑完全复用。

⚠️ 常见坑：replaceTrack 替换分辨率差异过大的轨道（如从 1080p 换到 360p 屏幕共享）时，部分旧版本浏览器会触发重协商或直接失败。稳妥做法是替换前后保持同类与相近分辨率，跨类切换（视频换音频）则必须走重协商流程。

本节要点回顾

• 阀门与剪断：enabled 是可逆的阀门（设备仍占用、指示灯仍亮），stop 是不可逆的剪断（设备释放、轨道终态），静音用前者、彻底退出用后者。
• 静音要两端知情的：本端改 enabled，对端靠 mute 与 unmute 事件同步界面，UI 节奏与静音帧到达节奏对齐。
• replaceTrack 是换景不熄灯：不重协商替换发送内容，是热切换与动态降级的共同底座。
• devicechange 加 ended 组成恢复链：设备会来会走，通话必须常在；提示、发现、恢复、兜底四步要做成状态机。
• 跨类替换有雷区：同类相近参数的替换最稳，跨类切换要走重协商，别拿 replaceTrack 硬跨。