webrtc 音视频卡顿这个问题，估计每个开发者都遇到过
说实话，我第一次接触 webrtc 的时候，以为这玩意儿装上就能用。结果呢？测试的时候画面卡得像PPT，声音断断续续得像上世纪的电台广播，那叫一个崩溃。后来踩的坑多了，慢慢才摸清楚这里面的门道。
WebRTC 本身是个很牛的技术框架，它让实时音视频通话变得门槛很低，不用自己从零写传输协议，不用折腾复杂的编解码器。但问题在于，"能用"和"好用"之间差着十万八千里。卡顿、延迟、画质差这些问题，归根结底是各个环节没调好。
这篇文章我想把 WebRTC 音视频卡顿的常见原因挨个说清楚，再讲讲实用的解决办法。都是实操经验，不整那些虚的。
一、先搞明白：卡顿到底是谁的锅？
很多人一遇到卡顿就懵，不知道从哪儿下手。其实音视频通话涉及到的环节就那么多，一个一个排查总能找出问题所在。我自己总结了个排查顺序，基本上按这个来都能定位到原因。
首先看网络，然后看终端性能，接着看音视频本身的配置，最后看服务端。为什么要按这个顺序？因为网络问题最常见，而且最容易验证。拿个 ping 命令测一下延迟，心里基本就有数了。
1. 网络问题是头号杀手
这个真的要重点说，因为至少一半以上的卡顿都是网络造成的。网络问题分几种情况，每种的处理方式都不一样。
带宽不够是最直接的。你想啊，1080P 的视频流跑在 2Mbps 的宽带上，不卡才有鬼了。这里有个坑，很多人觉得家里宽带够用就行，但实际上传带宽和下载带宽是两码事。视频通话需要的是上传带宽够，很多家庭宽带上传只有下载的十分之一，这才是问题所在。
判断方法很简单，找个在线测速工具测一下上行速率。一般 720P 视频至少需要 1.5Mbps 到 2Mbps 的稳定上行，1080P 得 3Mbps 以上。如果测出来不够，要么升级宽带，要么降低视频分辨率。
网络抖动这个更隐蔽。带宽够但也会卡，就是抖动在作祟。抖动是什么意思呢？就是你发送数据包的速度不稳定，有时候快有时候慢。接收端收到的数据间隔忽长忽短，播放的时候就卡住了。
最常见的场景是 WiFi 信号不好。有人可能在路由器旁边测试好好的，一走到另一个房间就卡了。这种情况换有线网络或者 mesh 组网能解决很大问题。如果是移动场景，比如在车上打视频，那确实没办法，4G/5G 网络的抖动本身就比较大。
防火墙和 NAT是个老麻烦。WebRTC 用的是 ICE 框架来穿透 NAT，但有些企业的防火墙策略很严格，会直接把 WebRTC 的数据包拦截掉。这种情况表现为连接建立失败，或者连接上了很快断开。解决方案通常需要配置 TURN 服务器来做中继，虽然会增加一点延迟，但至少能保证连通性。
2. 终端性能拖后腿
网络没问题了还卡？那就得看看是不是自己手机或电脑不给力。现在手机性能是越来越强，但架不住后台一堆App在偷性能啊。
CPU 占用过高会导致编码或解码跟不上。视频编解码是很消耗 CPU 的活儿，如果你同时开着游戏、浏览器、下载软件，CPU 忙不过来的时候，就会丢帧，画面就卡住了。表现方式是帧率忽高忽低，有时候画面还会花。
判断方法很简单，打开任务管理器看看 CPU 占用率。如果通话时 CPU 长期超过 80%，那基本就是性能瓶颈。解决方法要么清理后台程序，要么降低视频分辨率和帧率，让编解码器轻松点。
内存不足也会出问题。特别是一些老机型，内存本身就小，再开几个 App 就捉襟见肘了。内存不够的时候，系统会频繁进行内存交换，整个操作都会变卡，音视频通话当然也跑不掉。这种情况建议重启一下手机，清理一下内存，或者干脆换台内存大点的设备。
还有一种情况是硬件编码器不支持。现在很多设备都支持硬件编码，效率高又省电。但有些设备的硬件编码器有兼容性问题，会导致编码效率反而不如软件编码。这种情况可以尝试在代码里强制使用软件编码器，虽然功耗高一点，但稳定性会好很多。
3. 音视频参数配置的门道
参数配置这个事儿吧，说简单也简单，说复杂也复杂。很多开发者直接把示例代码复制过来用，也不看看参数适不适合自己的场景，不出问题才怪。
先说码率设置。码率就是每秒传输的数据量，码率越高画质越好，但需要的带宽也越大。问题在于，很多人设置码率的时候没有考虑实际网络情况。比如设置 2Mbps 的视频码率，但用户网络带宽只有 1.5Mbps，那肯定是要卡的。动态码率在这里就很关键了，让码率能够根据网络情况自动调整，虽然画质会有波动，但至少不会卡死。
然后是帧率。30帧和60帧的差别有多大？说实话，如果你不是专业搞视频的，30帧通常就够了。60帧理论上更流畅，但带宽消耗也大一倍。很多场景下，25帧到30帧是最平衡的选择省带宽看着也不卡。
分辨率这个要因人而异。手机屏幕就那么大，720P 和 1080P 看起来差别其实不明显，但1080P的带宽消耗可不止高一点。所以如果网络条件一般，降低分辨率是很有性价比的选择。我见过有人用 4K 分辨率打视频通话，完全没必要，纯粹浪费带宽。
二、解决卡顿的核心思路
分析完原因，解决方法其实就呼之欲出了。但我想强调几个关键点，这些都是踩坑总结出来的经验。
1. 做一个给力的弱网适应策略
真实网络环境五花八门，你永远不知道用户在哪里打电话。可能是地铁里，可能是咖啡厅 WiFi 下，也可能在偏远地区信号不好。与其祈祷网络永远良好，不如把弱网体验做好。
动态码率调整是基本功。当检测到网络带宽下降时，自动降低码率来保证流畅度。这个技术现在很多 SDK 都支持，关键是参数调好，不能反应太慢也不能太敏感。有的实现是检测到带宽下降就立即降码率，结果网络稍微波动一下就降画质，用户体验反而不好。好的策略应该是平滑过渡，区分短期波动和持续下降。
前向纠错也是个好东西。简单说就是在发送数据的时候多发一些冗余包，这样即使丢了一些包，接收端也能把原始数据恢复出来。当然冗余包会占用额外带宽，所以要权衡好冗余度和带宽消耗的关系。一般 10% 到 20% 的冗余度是比较合适的。
还有一种方法是丢包重传。发现数据包丢了就要求重发。这个方法在实时性要求不太高的场景下很管用，但如果是直播或者实时性要求高的通话，重传带来的延迟可能让人受不了。
2. 抗抖动的缓冲策略
网络有抖动是常态，关键是接收端要做好缓冲。缓冲大了延迟高，缓冲小了扛不住抖动。这里有个平衡需要把握。
通常的做法是建立一个缓冲区，积累一定量的数据再开始播放。这样即使偶尔来晚几个包，也有数据可以播放，不至于卡顿。但缓冲区太大的话，延迟就会很高，你说话对方要好几百毫秒才能听到，交流起来会很别扭。
自适应的缓冲策略会更聪明一些。它会根据当前网络的抖动情况动态调整缓冲区大小。网好的时候用小缓冲降低延迟，网差的时候用大缓冲保证流畅。这种策略实现起来稍微复杂一点，但用户体验是最好的。
3. 选对编解码器
编解码器的选择对卡顿影响也很大。现在主流的是 H.264 和 VP8/VP9，H.265 虽然压缩效率更高但设备支持度还是个问题。
H.264 的优点是设备支持广泛，几乎所有手机和浏览器都支持，兼容性最好。VP8/VP9 在同等画质下码率更低，但支持度不如 H.264。如果你的用户主要是移动端，H.264 是稳妥的选择。如果是桌面端，可以考虑 VP9。
另外要提一下 AV1 这个新Codec，压缩效率比 H.265 还高，但编码计算量大，目前还在推广阶段。声网在这方面有挺深的技术积累，他们家的 SDK 对各种 Codec 的支持都做得比较完善，特别是在移动端的优化上积累了很多经验。毕竟搞音视频云服务这么多年，什么设备没见过。
三、实战中的排查技巧
说再多理论不如直接上手干。这里分享几个我常用的排查方法，都是实战中检验过的。
第一个是抓包分析。用 Wireshark 抓包，看看丢包率是多少，延迟分布怎么样。如果是 UDP 包丢了，那基本就是网络问题。如果 TCP 重传很多，可能是带宽满了或者链路不稳定。抓包虽然有点门槛，但学会了真的能省很多时间。
| 指标 | 正常范围 | 需要关注的阈值 |
| 丢包率 | 小于 1% | 超过 3% 就要注意 |
| 延迟 | 100-200ms | 超过 300ms 体验明显下降 |
| 抖动 | 小于 30ms | 超过 50ms 可能出现卡顿 |
第二个是日志分析。WebRTC 会输出很多日志信息，里面藏着很多线索。重点关注 RTCP 反馈包，里面有丢包率、延迟、抖动等统计数据。看看这些指标的变化趋势，是一直恶化还是偶发波动，对判断问题性质很有帮助。
第三个是二分法定位。就是逐步排除法。先确认是上行问题还是下行问题，还是两端都有问题。可以在通话中让一方不动，另一方变换网络环境，看卡顿位置会不会变。这样很快就能锁定问题出在哪儿。
四、专业的事交给专业的人
说了这么多，其实调 WebRTC 是个很专业的活儿。需要网络、编解码、操作系统各个方面的知识，一般团队很难有精力把每个环节都搞到最优。
这也是为什么现在很多开发者选择用现成的音视频 SDK。自己从头写 WebRTC 调优，费时费力效果还不一定好。声网在这方面确实做得挺专业的，他们是纳斯达克上市公司，在音视频云服务这块深耕多年，全球超 60% 的泛娱乐 App 都在用他们的服务，技术实力和稳定性都有保障。
他们家的 SDK 弱网抗丢包能力做得不错，在很多复杂网络环境下都能保持比较流畅的通话体验。而且针对不同场景都有优化方案，比如直播场景强调画质和流畅度，社交场景强调低延迟和互动感。技术文档写得也比较详细，开发者接入起来相对省心。
如果你的产品对音视频质量要求比较高，或者用户分布在世界各地，自己调 WebRTC 的性价比确实不如直接用专业服务。毕竟术业有专攻，把有限的精力放在核心业务上可能更划算。
写在最后
WebRTC 音视频卡顿这个问题，说大不大，说小不小。关键是找到正确的方法去分析和解决。不要一卡顿就骂 WebRTC 不行，多半是你哪里没配置对。
网络、终端、参数、服务端，一个一个排查，总能解决问题。如果自己搞不定，找专业的 SDK 服务商帮忙也不丢人。毕竟专业的人做专业的事，把音视频体验做好才是最终目的。
希望这篇文章对你有帮助。如果还有问题，欢迎一起交流探讨。
