前阵子跟客户微信语音聊需求说着说着突然没声了屏幕立马弹出“对方网络不佳”的提示或者自己这边提示当前网络不佳反复切WiFi、开流量都没用最后只能换电话沟通。其实这件事我想了很久了还是打算今天拿来好好唠唠顺便也给自己涨涨姿势看看到底是神不可及的技术还是最最最简单的网络延迟方法。为什么需要“网络不佳”提示在微信通话这种实时音视频场景里用户对流畅有非常低的容忍度一旦出现断续的声音、口型不同步、画面卡顿或通话直接掉线用户就会迅速认为服务不可靠并中断通话或投诉。因此在界面上及时、准确地提示“当前/对方网络不佳”不仅是对用户体验的尊重也是减少误判、引导用户采取补救措施切换到语音、关视频、切换网络或靠近路由器的关键。具体场景包括地铁或电梯等移动过程中发生的小区切换导致丢包与抖动多人群聊或屏幕共享时上行带宽被耗尽导致画面质量急剧下降等自适应码流和重传策略提供触发条件并提升用户对恢复机制的信任感这些都是设计“网络不佳”提示的直接动因。微信是如何做到的猜测从技术上看“网络好不好”并不是一个主观判断而是一组持续可观测、可量化的网络与媒体质量信号。在实时音视频RTC系统中最基础的一层是网络层指标丢包率Packet Loss反映数据在传输路径上的可靠性抖动Jitter描述包到达时间的不稳定性直接决定是否需要更大的播放缓冲RTTRound-Trip Time则刻画端到端时延和链路拥塞程度。在其之上是媒体层指标码率Bitrate是否能稳定达到目标值、帧率FPS是否持续下降、关键帧是否频繁请求再往上是体验层的综合指标如MOSMean Opinion Score通过对丢包、时延、抖动、音频 PLC 触发次数、视频卡顿时长等信号加权估算“用户主观感受”。这些指标的共同点在于它们都来自客户端和传输层的实时统计在微信以及主流 RTC 平台WebRTC、Agora、Zoom、腾讯云 TRTC 等的实现中通常不会依赖单一指标来下结论而是采用多信号融合 时间窗口判断的方式。典型做法包括在信令层和媒体层同时采集统计数据冗余信令避免单一路径或单一模块失效通过上/下行探测包Probe Packet或带宽估计算法如基于延迟梯度、丢包反馈的 BWE持续判断链路可用带宽在弱网或移动场景下启用多通路/备份链路如 Wi-Fi 蜂窝网络的快速切换或并行探测在播放端使用自适应缓冲区Adaptive Jitter Buffer根据抖动动态调整缓冲深度以在“低延迟”和“不卡顿”之间取平衡。一旦检测到多个关键指标在一定时间窗口内持续恶化例如丢包率超过阈值、RTT 快速上升、码率被迫下探系统就会触发体验等级下降并映射为“当前/对方网络不佳”的用户提示。这种思路在公开资料中也有佐证。WebRTC 官方文档和 RFC 中详细描述了基于 RTCP 统计的带宽估计与拥塞控制模型腾讯、字节、阿里等厂商在公开专利中多次提到多维网络质量评估、弱网对抗与体验分级提示机制学术与工业界关于 MOS 预测的技术文献也表明将底层网络指标映射为用户可理解的体验标签是大规模 RTC 系统的通用做法。如何决策在产品层面“网络不佳”不是技术结论展示而是不干扰用户体验核心目标只有一个在不打扰用户的前提下帮他理解当前通话异常的原因。因此微信这类产品在设计上通常遵循以下取舍。网络指标是实时波动的但提示不能实时波动。实际策略通常是时间窗口 连续恶化判定例如在 25 秒内持续丢包升高、RTT 上扬、码率被迫下探才认为是“稳定性问题”否则只是短暂抖动直接忽略。这也是为什么你在地铁刚进隧道那一瞬间微信往往不会立刻弹“网络不佳”。 当然了哈~~ 也不排除微信确实没及时检测到哈哈哈技术方案如果把“网络不佳”当成一个完整的技术功能来看它并不是某个 if 判断而是一条很清晰的过程数据采集 → 指标聚合 → 质量评分 → 防抖与阈值 → 展示或策略处理。一、数据采集Data Collection第一步解决的不是判断而是你到底能看到什么。在 RTC 客户端里采集通常来自三层网络层RTT、丢包率、抖动、发送/接收速率、重传次数传输/协议层RTCP 统计、NACK/PLI/FIR 次数、拥塞窗口变化媒体层编码码率、实际渲染帧率、卡顿时长、音频 PLC 触发次数注意这些数据不是按事件上报而是以固定周期如 200ms / 500ms / 1s持续采样形成时间序列。二、指标聚合Aggregation原始指标是噪声极大的不能直接用。现实情况下我们系统一定要收集滑动时间窗如最近 3s / 5s计算均值、P95、变化斜率标记异常峰值Spike而不是立刻判坏举个栗子一次 200ms 的 RTT 飙升可能是 GC、系统调度或基站抖动但RTT 连续 5 秒单调上升 丢包同步增加才是链路拥塞的信号。其实这个操作就是把瞬时的网络状态转换成一个网络趋势方便判断是否要提示用户三、质量评分Quality Scoring接下来不是直接出网络好/网络坏而是要有体验层映射。常见方式如下规则加权score w1*丢包 w2*RTT w3*卡顿 w4*帧率下降分档映射优 / 良 / 可接受 / 差对应 MOS 区间四、提示以及处理这里的提示我们必须做防抖不能反复频繁提示用户进入阈值评分连续低于 X持续 ≥ T 秒 退出阈值评分连续高于 YY X持续 ≥ T′ 秒 状态锁定同一状态不重复触发提示然后就是处理了 UI 层展示「当前 / 对方网络不佳」。 要做的处理- 自动降码率 / 降分辨率 - 关闭视频保音频 - 切备用链路 / 重连统计层上报埋点用于后续策略优化也就是说“网络不佳”往往是系统已经做了很多努力之后的结果告知而不是直接哇啦哇啦告诉用户你踏马网废了。整体流程示意原始数据采集RTT / 丢包 / 帧率时间窗口聚合均值 / 趋势质量评分MOS / 等级防抖 阈值判断状态机UI 提示网络不佳自适应策略降码率/切链路我们如何实现呢ReactNative前文拆解的这套网络检测逻辑并非微信独有的技术壁垒在工程实践中我们完全可以自己完成一套方案。下面直接用React Native结合WebRTC的实操举例别眨眼我要写代码了。可以眨眼技术选型与依赖在RN项目中基于WebRTC做数据采集是最稳妥的选择第一步先安装核心依赖yarn add react-native-webrtc这个库自带的getStats方法是网络质量判断的核心入口里面包含了所有关键数据维度RTT往返延迟packetsLost / packetsSent丢包数/发送数jitter抖动bitrate码率通过bytesSent差分计算得出frameRate帧率部分平台支持这里要明确一个核心认知无需刻意计算网络状态重点是精准读取传输过程中的原生统计数据。数据采集定时 时间序列const statsBuffer: StatSample[] []; setInterval(async () { const stats await pc.getStats(); const parsed parseStats(stats); statsBuffer.push({ rtt: parsed.rtt, packetLoss: parsed.packetLoss, jitter: parsed.jitter, bitrate: parsed.bitrate, ts: Date.now(), }); // 只保留最近5秒的数据 prune(statsBuffer, 5000); }, 1000);这里有两个至关重要的细节切勿依赖单次数据快照必须保留时间维度的连续数据。缺少这两点后续的防抖处理和趋势判断都会沦为空谈。指标聚合 质量评分可解释优先function calcQuality(samples: StatSample[]) { const avgLoss mean(samples.map(s s.packetLoss)); const avgRtt mean(samples.map(s s.rtt)); const avgJitter mean(samples.map(s s.jitter)); let score 100; if (avgLoss 0.05) score - 30; if (avgRtt 300) score - 30; if (avgJitter 50) score - 20; return score; }这种规则加权的评分方式在真实工程场景中应用极广。核心原因很简单可调优、可回滚、可追溯出现问题时能快速定位到具体异常指标。阈值 防抖用状态机思路别堆if判断let badSince: number | null null; let state: GOOD | BAD GOOD; function updateState(score: number) { const now Date.now(); if (score 60) { if (!badSince) badSince now; if (now - badSince 3000 state ! BAD) { state BAD; showNetworkBad(); } } else { badSince null; if (state BAD score 75) { state GOOD; hideNetworkBad(); } } }这段逻辑的核心要点很明确评分低于60分时触发预警判定持续3秒无改善才切换至异常状态恢复时需评分超过75分才回切正常状态。这一步的设计直接决定提示功能的专业性有效避免频繁误报影响用户体验。举例方便所以使用打分制也可以其他的然后UI展示轻提示{state BAD ( View style{styles.badNetwork} Text醒醒你踏马网废了/Text /View )}采用轻量提示设计不弹窗、不弹出 Toast、不抢占用户操作焦点仅安静告知用户当前网络存在异常非设备故障或操作问题。自动降级处理这点很重要在真实项目中网络异常提示绝非仅展示一句文案更重要的是触发对应的自适应应对策略例如当异常状态持续5秒自动降低视频码率下调视频分辨率或帧率当异常状态持续10秒提示用户关闭视频优先保障音频通话通畅当状态恢复正常时缓慢提升码率避免一次性拉满导致再次卡顿这里有个核心工程原则务必记牢恢复要慢降级要快。总结从技术角度来看判断通话网络好坏其实就是三件事持续采集指标、观察趋势、连续判定。瞬时波动不算数只有连续多秒丢包、抖动高、延迟大才真正算网络不佳。再配合降码率、先保音频、延迟提示的策略就能在用户几乎感觉不到的情况下保证体验。核心逻辑很朴素但工程上最难的是防抖、聚合和兜底原文 https://juejin.cn/post/76016826