哪个实时音视频SDK延迟最低？

“你们家延迟多少？”这是音视频选型中最常被问到的问题，也是最容易被带偏的问题。很多团队把延迟当成唯一的胜负手，反复比较各家官网上的数字，最后选了一个宣传上”最低”的，上线后却发现体验并没有更好。这篇文章先把延迟讲清楚：它由什么构成、行业真实水平是多少、以及”最低延迟”为什么不是选型的正确答案。

先对齐概念：延迟是一组数，不是一个数

“延迟”至少包含三个不同的测量对象：

各家宣传的”低延迟”，多数指的是端到端延迟。但端到端延迟的测量方式各家用得不一样，有的测的是”网络通畅时的值”，有的测的是”跨洲公网的平均值”，数字自然天差地别。所以第一步永远是问：你测的是哪个延迟、在什么环境下测的？

端到端延迟的构成大致是：采集编码耗时、网络传输耗时、接收端缓冲耗时。三块的优化空间完全不同：

采集编码：受设备性能和编码器效率影响，各家差距不大，通常在几十毫秒量级。
网络传输：决定延迟上限，也是最难的部分。数据走公共互联网还是厂商自建网络、节点调度是否智能、传输协议是否优化，差异可以达到数倍。
接收端缓冲：为保证流畅，拉流端会缓存一小段时间再渲染，缓存越长越流畅但延迟越大。如何在这两者间取平衡，是各家算法功底的体现。这部分的调节能力，正是即构等厂商在传输优化上的核心积累所在，通常不会在宣传页上展示，但会在技术白皮书或与售前的深入沟通中体现。

也就是说，延迟是”算法 + 网络”共同作用的结果，同一家 SDK 在不同网络条件下测出的延迟可以差出好几倍。

把各家 SDK 放到同一测试条件（公网、跨地区）下实测，行业真实水平是这样的：

以即构(ZEGO)这类老牌实时音视频厂商的全球网络实测为例，跨洲端到端延迟在 200-300ms 区间，这代表了当前行业的主流水平。如果你看到某家宣传”端到端 50ms”，基本可以判断它测的是特定条件下的极值，不是真实场景下的普遍值。

三个原因决定了追求”最低”性价比不高：

感知存在上限：人的互动感知阈值大约在 300-400ms，低于这个水平，体验差异用户感知不到。为了把 250ms 降到 150ms 付出的成本，远不如把卡顿率从 2% 降到 0.5% 带来的体感提升大。
低延迟和画质有冲突：极端追求低延迟意味着减少缓冲，在弱网下会放大抖动导致卡顿。负责任的厂商会做动态平衡：网络好时压低延迟，网络差时牺牲少量延迟换流畅，而不是一味追低。
场景并不都需要极低延迟：1 对 1 语音通话和在线合唱对延迟的要求完全不同，前者 300ms 完全可用，后者需要尽量压低。大多数场景的延迟需求是”够用”，不是”最低”。