WebRTC页面手动刷新后黑屏问题求助

一、核心可能原因 #

1. 媒体轨道/资源未彻底释放（最可能） #

手动刷新页面时，浏览器的资源回收时序与自动刷新、页面跳转不同：旧页面的MediaStreamTrack或PeerConnection可能未完全销毁，导致：

• 浏览器端：新页面请求的媒体流与残留轨道冲突，无法正确渲染；
• Android端：摄像头捕获资源仍被旧PeerConnection占用，新连接无法获取有效视频流。

2. 信令流程时序异常 #

手动刷新时，信令交互的时序出现偏差：

• 浏览器端未正确清理旧会话的信令状态，发起新呼叫时携带了旧的会话标识或SDP参数；
• Android端收到新呼叫请求时，未彻底清除旧PeerConnection的上下文，导致新的SDP/ICE协商不完整（比如ICE候选未全量收集、m-line匹配失败）。

3. 浏览器自动播放策略触发差异 #

手动刷新后，若新页面自动发起呼叫，浏览器可能将其判定为“无用户交互的自动播放请求”，阻止视频渲染；而自动刷新时，浏览器可能保留了之前的用户交互状态，未触发限制。

4. 信令服务器会话残留 #

手动刷新时，旧会话的标识未从信令服务器清除，Android端误将新呼叫绑定到旧会话的PeerConnection上下文，导致流无法正确推送。

二、针对性调试方法 #

针对媒体资源残留 #

• 浏览器端调试：
  • 在页面beforeunload或unload事件中，强制执行清理逻辑：

    window.addEventListener('beforeunload', () => {
      if (window.peerConnection) {
        window.peerConnection.getTracks().forEach(track => track.stop());
        window.peerConnection.close();
        window.peerConnection = null;
      }
    });
    

  • 手动刷新前后，在浏览器控制台执行navigator.mediaDevices.enumerateDevices()，查看是否有残留的视频轨道；对比自动刷新时的设备列表差异。
• Android端调试：
  • 监听信令的断开事件（若有），确保收到后立即调用peerConnection.close()，并释放摄像头的CaptureSession；
  • 手动刷新后，检查Android端的摄像头资源占用情况，确认新连接能正常获取摄像头实例。

针对信令时序异常 #

• 全链路日志打印：
  • 浏览器端：打印SDP offer/answer的内容、ICE候选的收集状态、peerConnection的iceConnectionState变化；
  • Android端：打印收到的信令消息、SDP解析结果、ICE连接状态；
  • 对比手动刷新与自动刷新时的日志，重点看SDP的m-line是否有效、ICE候选是否完整、iceConnectionState是否能到达connected。
• 会话标识校验：
  • 确保每次呼叫使用全新的会话ID，手动刷新后，浏览器端发起呼叫时携带的会话ID与旧会话完全隔离；Android端收到请求后，先校验会话ID，若为新会话则创建全新的PeerConnection。

针对自动播放策略 #

• 在浏览器控制台检查video元素的状态：

  console.log('video readyState:', video.readyState);
  console.log('video paused:', video.paused);
  console.log('has tracks:', video.srcObject?.getTracks().length > 0);
  

• 手动刷新后，尝试手动点击视频元素触发播放，若能正常显示，则说明是自动播放限制问题，需修改逻辑：在用户交互（比如点击“重新呼叫”按钮）后再发起连接并绑定流。

针对信令服务器会话残留 #

• 检查信令服务器的会话存储，手动刷新后，确认旧会话已被删除或标记为失效；
• 呼叫发起时，强制生成新的会话ID，避免与旧会话冲突。

内容的提问来源于stack exchange，提问作者JustDontKnow