同时 SDK 会在连接质量变化、CPU/带宽受限时主动触发事件,业务层可以被动订阅而不用轮询。
一、主动订阅事件(推荐)
连接质量相关事件复用现有的ChannelEvent 体系,直接在 onNotifyChannelEvent 里处理:
二、主动查询
2.1 连接质量评估 getConnectionQuality
qualityLimitationReason 等多维指标综合打分。
2.2 网络总体统计 getNetworkStats
delay 和 up_level 字段已被移除:delay 现在拆分为更精确的 rtt_up 与 rtt_down,up_level 由 getConnectionQuality() 返回的 QualityEvaluation.uplink 替代。
:::
2.3 全量 metric 快照 getStreamMetric
三、Track 级原始统计
StreamMetric 里每个 track 的 stats 字段对应 WebRTC 原生的 sender/receiver stats:
四、推荐的接入姿势
大多数业务只需要展示”网络状态灯”,推荐组合:五、弱网处理
处理弱网先分清两件事:方向和原因。- 上行差是你发不出去,你能主动降级(降码率、切小流、关摄像头);下行差是你收不进来,只能少收(切小流、退订视频)。所以要看
uplink/downlink两个方向,而不是只看overall。 BANDWIDTH_CONSTRAINED是带宽不足,CPU_CONSTRAINED是设备编码跟不上,两者处置不同。
5.1 展示网络状态
用overall 映射一个状态灯即可,不要把丢包率、RTT 这类原始数据直接展示给终端用户:
上行差和下行差的提示文案不同,需要区分:
poor 持续几秒再 toast,不要一波动就弹。BANDWIDTH_CONSTRAINED / CPU_CONSTRAINED 事件 SDK 已做去抖,业务层弹窗建议再限一次频率。
5.2 上行变差
按从轻到重逐级降级:- 编码器自适应:浏览器自动完成,默认已开,无需干预。不想让分辨率被自动压低时,用
degradationPreference改变降级方式(见 5.4)。 - 切小流 / 降分辨率:发布了大小流时可切到小流(320×180、约 250 Kbps)。见大小流与分辨率。
- 关摄像头、只保留音频:音频码率低(约 32 Kbps),弱网下几乎总能保住。
- 彻底停止发布:
unpublishLocalTrack(localVideoTrack),比关摄像头更彻底,释放上行编码与发送资源。
CPU_CONSTRAINED 时优先降分辨率 / 帧率(减轻编码负载);BANDWIDTH_CONSTRAINED 时降码率或分辨率都可以。
关摄像头会改变通话形态,建议提示用户后再执行,不要静默操作——应急指挥、执法记录等场景尤其如此。
5.3 下行变差
- 先确认是不是对端的问题:本端有下行丢包,才是你的接收链路差;若本端几乎无丢包、只是某人画面卡顿,通常是对方上行差,此时你退订也无济于事,提示”对方网络不佳”即可。SDK 评分已区分这两种情况,不会因对方问题误降你的下行档。
- 发布方发大小流时,SFU 自动切层:SFU 会依据每个订阅者自身的下行带宽和丢包,自动把它切到合适的大 / 小流,订阅端无需手动切;只发单流则无法自动降。见大小流与分辨率。
- 退订视频、只收音频:
- 多路会议:只订阅当前说话人的视频,其余成员只收音频。
5.4 控制降级方式:degradationPreference
publishLocalTrack 的 VideoPublishOptions.degradationPreference 决定弱网下牺牲什么:
不希望分辨率被自动压低时,设为
maintain-resolution:
maintain-resolution;480p / 360p 未设置,走浏览器默认。
5.5 连接断开(lost)
overall === 'lost' 表示媒体已中断,应进入重连并提示用户”正在重连”;恢复后刷新状态灯,并恢复此前主动关闭的摄像头或订阅。
5.6 速查表
5.7 完整示例
把上面的做法串起来:发布时配置降级策略,运行时订阅事件更新状态灯、分方向提示、按需降级与恢复。示例里publishLocalTrack/disableLocalTrack/enableLocalTrack均为 SDK 现有方法。关摄像头这类改变通话形态的操作通过按钮交给用户确认,未静默执行;普通会议等场景可自行改为自动。下行”仅语音”兜底按注释里的思路自行实现(用unsubscribeRemoteTrack退订视频、保留音频)。