Flutter中WebSocket Provider管理下WebRTC跨网视频通话问题求助

核心问题定位 #

同网环境能正常连接，说明WebRTC的基础ICE配置、SDP交换逻辑本身是可行的。跨网失败的核心原因大概率是页面跳转过程中，Provider管理的WebSocket信令出现状态异常——毕竟跨网必须依赖完整的信令交换来传递公网ICE候选，而同网可能靠局域网直连绕开了部分信令环节。

具体排查步骤 #

• 检查WebSocket实例的生命周期稳定性

  • 确认页面跳转时，Provider中的WebSocket连接是否被意外销毁或重建。比如如果Provider是页面级注册的，跳转到视频通话页会创建新实例，之前的信令上下文直接丢失，导致跨网所需的公网ICE候选无法正常交换。
  • 打印WebSocket的readyState状态，在用户列表页跳转前后、视频通话页初始化时分别记录，看连接是否持续处于活跃状态。

• 验证信令消息的完整性

  • 跨网环境下，STUN/TURN返回的公网ICE候选是连接关键。在Provider中添加日志，记录所有收发的信令消息（SDP Offer/Answer、ICE候选），对比单页应用的消息序列，看是否存在消息丢失（比如跳转时刚好在发送ICE候选，导致对方未接收）。

• 检查Provider的注册范围

  • 如果使用ChangeNotifierProvider，确认是否是全局单例模式（在根Widget如MaterialApp外层注册）。页面级注册的Provider会在页面销毁时被dispose，直接导致信令中断。

修复方案 #

• 全局托管WebSocket实例

  • 将WebSocket的Provider注册在应用根节点，确保页面跳转时连接不中断。避免在用户列表页或视频通话页单独创建Provider，防止实例重复创建或销毁。
  • 给WebSocket添加自动重连逻辑：如果连接意外断开，Provider自动发起重连，并重新发送本地缓存的SDP和ICE候选，恢复信令上下文。

• 优化WebRTC连接触发时机

  • 在视频通话页初始化时，先判断WebSocket连接是否处于活跃状态，确认后再创建PeerConnection、发送SDP Offer。避免页面刚进入就立即发起连接，防止信令未准备就绪导致消息丢失。

• 确认STUN/TURN配置有效性

  • 核对Flutter项目与单页应用的STUN/TURN服务器配置是否一致。跨网场景下必须配置有效的STUN服务器，若遇到对称NAT网络，还需启用TURN服务器。可以在PeerConnection创建后打印ICE候选类型，确认是否生成了srflx（STUN公网候选）或relay（TURN中继候选）。

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