Flutter-WebRTC 中 `onAddStream` 回调失效问题解析与解决方案

在 Flutter-WebRTC 开发过程中，开发者可能会遇到一个常见问题：在 Web 平台上 onAddStream 回调无法正常触发，而在 iOS 设备上却能正常工作。这种现象源于 WebRTC 标准的演进和不同平台实现方式的差异。

问题本质

onAddStream 是 WebRTC 早期的 API 设计，用于在远程媒体流添加时触发回调。然而随着 WebRTC 标准的更新，这个 API 已经被标记为废弃并最终从规范中移除。现代 WebRTC 实现推荐使用 onTrack 事件作为替代方案。

平台差异原因

iOS 平台的 Flutter-WebRTC 实现基于原生代码封装，为了保持向后兼容性，仍然支持 onAddStream 回调。而 Web 平台直接使用浏览器提供的 WebRTC API，遵循最新的标准规范，因此不再支持这个已废弃的接口。

现代解决方案

开发者应该使用 onTrack 事件来替代 onAddStream。onTrack 提供了更精细的媒体轨道控制能力，能够区分音频和视频轨道，并且可以访问关联的媒体流集合。

以下是推荐的实现方式：

rtcPeerConnection!.onTrack = (RTCTrackEvent event) {
  if (event.track.kind == 'video') {
    _remoteVideoRenderer.srcObject = event.streams.isNotEmpty 
      ? event.streams[0] 
      : null;
    // 更新UI状态
    setState(() {});
  }
};

迁移注意事项

1. 轨道类型检查：onTrack 会触发所有类型的媒体轨道，包括音频和视频，需要通过 event.track.kind 进行区分

2. 流关联性：一个轨道可能关联多个流，通过 event.streams 数组访问

3. 状态管理：由于 onTrack 可能多次触发（例如每个轨道单独触发），需要合理管理渲染器状态

4. 跨平台兼容：虽然 iOS 仍支持 onAddStream，但建议统一使用 onTrack 以保证代码一致性

最佳实践建议

1. 对于新项目，直接使用 onTrack 事件处理媒体流

2. 对于已有项目，逐步将 onAddStream 逻辑迁移到 onTrack

3. 在处理视频轨道时，考虑添加渲染器状态检查和错误处理

4. 在跨平台开发中，使用条件编译或平台检测来确保代码的健壮性

通过采用 onTrack 这一现代 WebRTC API，开发者不仅能解决 Web 平台的兼容性问题，还能获得更灵活、更符合标准的媒体处理能力，为应用未来的功能扩展打下良好基础。