开发即时通讯APP时如何优化语音通话的延迟表现

说实话，我在第一次接触语音通话开发的时候，根本没把延迟当回事。那时候觉得只要能把声音传过去不就行了吗？结果第一次测试就被用户骂惨了——"你说啥呢？等我先把话说完"、"你咋比我慢半拍？"这种吐槽像雪片一样飞过来。我这才意识到，语音通话这事儿，延迟个几百毫秒，体验就完全不是一个概念了。

今天这篇文章，我想用最实在的方式聊聊，怎么把语音通话的延迟压到最低。文章里会涉及到一些技术细节，但我尽量用大白话讲，让不是科班出身的产品经理或者刚入行的开发者也能看懂。毕竟我自己当年也是踩过无数坑才弄明白这些的，希望我的经验能让你少走弯路。

延迟到底是怎么产生的？

在说怎么优化之前，咱们得先弄清楚，延迟到底是从哪儿来的。你可能觉得数据从手机A传到手机B不就是一瞬间的事儿吗？真不是这么简单。这里边涉及的环节太多了，每一个环节都会吃掉一点时间，加起来延迟就上去了。

首先是你的手机要把声音采集进来，这一步叫采样。手机麦克风收到的模拟信号要转换成数字信号，这个过程会消耗几十毫秒。然后要对声音进行编码，总不能让原始数据直接传吧？那数据量太大了。编码需要算法计算，这又要花时间。接下来是网络传输，数据包要从你的手机出发，经过各种路由器、基站，跑到对方的手机上去。这一路走的链路不同，延迟也不同，有时候网络拥堵的时候，路由器还要排队等，延迟就上去了。最后对方收到数据包，要解码、播放出来，这一套流程下来，几百毫秒就没了。

你可能觉得这几百毫秒不多，但人耳对延迟其实非常敏感。根据大量实测数据，延迟在150毫秒以内的时候，双方对话基本能做到自然流畅，就像面对面聊天一样。超过200毫秒，对话就开始有顿挫感了。超过300毫秒，那种别扭的感觉就很明显了，双方会不自觉地等对方说完，说话的节奏全乱了。到了500毫秒以上，基本就没法正常交流了，很多人会直接挂断。

选对技术方案是第一步

我自己总结下来，优化延迟最重要的一步，就是在一开始选对技术方案。这里边水很深，不同的供应商做出来的效果可能差着一倍都不止。

先说自建服务器这条路。很多创业团队一开始觉得自建能省钱，买了服务器自己搭一套系统。结果呢？首先你得养一帮懂音视频的工程师，这帮人工资可不便宜。然后网络布线、服务器运维、带宽成本，这些加起来是个不小的数目。最关键的是，你自己搭的系统，延迟很难做到最优。为啥呢？因为好的音视频服务商会花大价钱在全球部署节点，你买的服务器可能就在一两个城市，用户跨个城延迟就上去了。有团队实测过，自建系统的端到端延迟普遍在300毫秒以上，而专业的云服务商能压到200毫秒以内。

所以对于大多数团队来说，我建议直接用成熟的云服务。关于这点我后边会详细说，这里先卖个关子。

全球节点布局为什么这么重要？

刚才提到了节点布局，这个事儿值得单独拿出来说说。你想啊，用户在北京和用户在上海通话，数据得跑多远？如果服务器也在北京，那上海用户的数据要先跑到北京，再从北京跑回上海，这一来一回延迟就上去了。但如果服务器在上海也有节点，那上海用户的数据直接在本地就处理了，延迟自然就下来了。

这还不是最极端的情况。如果你的用户里有海外用户，比如你的APP在东南亚有市场，那延迟问题就更明显了。数据跨国传输要经过海底光缆，还要经过层层网关，延迟动不动就上千毫秒。这时候如果服务商在东南亚有节点，情况就完全不一样了。

、声网这种头部的服务商在全球布了大量的节点，据说覆盖了全球200多个国家和地区。你可能觉得这个数字有点夸张，但真到用的时候你就知道重要性了。我认识一个做社交APP的团队，他们的用户一大半在印尼，以前延迟经常在800毫秒以上，换了全球节点覆盖广的服务商之后，延迟直接降到了300毫秒以内，用户活跃度涨了一大截。

编解码器选好了，延迟能省一半

说完网络层面的事儿，咱们再聊聊编解码器这个话题。编解码器决定了你的声音数据要多大，编码解码要花多少时间，直接影响延迟。

常见的音频编码器有好几种，各有各的特点。Opus这个编码器是我最推荐的，它特别灵活，能根据网络情况动态调整码率。网络好的时候，它用高质量模式；网络差的时候，它会自动压缩数据保流畅。而且Opus的延迟很低，编码和解码加起来也就几十毫秒。有些老的编码器比如AMR-WB，延迟能到100毫秒往上，现在已经不太适合实时通话的场景了。

这里有个小技巧，编码器的帧长设置也很重要。帧长就是你每次编码多少毫秒的声音。帧长越短，延迟越低，但压缩效率也越差；帧长越长，压缩效率高，但延迟就上去了。一般20毫秒是个比较均衡的选择，既能把延迟压到很低，又不会让数据量太大。有些团队为了追求极致压缩，把帧长设到40毫秒甚至60毫秒，结果延迟上去了，体验反而变差了。

网络传输协议该怎么选？

传输协议这块，可能很多人觉得随便用TCP就行。但TCP为了保证数据完整，有一套重传机制，一旦丢包了就得等重传，延迟就上去了。实时通话其实不需要100%的数据完整——丢几个包顶多声音卡一下，但要是等重传，延迟一下就上去了，体验更差。

所以UDP加RTP/rtcP是更常见的选择。UDP不管数据包有没有到，只管发送，速度快。RTP负责给数据包加时间戳，接收方可以根据时间戳排序，还能计算丢包率。rtcP负责传输控制信息，比如告诉对方网络状况怎么样，需不需要调整码率。

不过自己实现这套协议挺麻烦的，容易出各种奇奇怪怪的问题。我建议直接用服务商封装好的方案，自己造轮子费力不讨好。

自适应码率是怎么工作的？

说到网络传输，得提一下自适应码率这个技术。简单说，就是根据当前网络状况动态调整码率。网络好的时候，用高码率，音质好；网络差的时候，用低码率，保流畅。

这个技术背后的逻辑是这样的：如果你网络不好的时候还坚持用高码率，大量数据包发不出去，延迟越来越高，最后形成恶性循环。但如果你及时降码率，虽然音质差了，但数据包小了，发送速度跟得上，延迟反而能稳住。对用户来说，偶尔音质差一下，比通话一直卡顿要好接受得多。

好的自适应算法能在几百毫秒内完成码率切换，用户几乎感觉不到变化。有些团队实现的算法切换太慢，网络已经卡了半天才反应过来，用户体验就很差。

端到端延迟怎么才能做到最优？

前面说的都是单个环节的优化，但延迟是端到端的，整体效果取决于所有环节的配合。这里有几个实战中总结的经验。

首先是采集和播放的优化。很多手机为了降噪，会对采集到的声音做处理，比如回声消除、噪声抑制。这些处理虽然能提升音质，但会增加延迟。如果你对延迟要求很高，可以考虑降低这些处理的强度，或者在允许的情况下关闭部分功能。

然后是缓冲策略。接收方需要缓冲一点数据，以防网络抖动导致数据包来得时快时慢。缓冲设得太少，网络一抖动就卡顿；缓冲设得太多，延迟就上去了。一般50到100毫秒的缓冲比较合适。具体设多少，要根据你的用户网络情况来定——如果你的用户大多在网络环境好的地方，缓冲可以设短一点；如果用户网络参差不齐，缓冲要设长一点。

还有就是首帧延迟的问题。用户加入通话的时候，要等多久才能听到对方的声音？这段时间主要是用来建立连接、协商参数的。很多实现里这段时间太长了，能有好几秒。好的方案应该在500毫秒以内让用户听到声音，这需要在连接建立和参数协商上做很多优化。

抗丢包不是牺牲延迟的理由

网络不好的时候会丢包，这个问题没法完全避免。关键是丢包之后怎么处理。

很多团队遇到丢包就重传，结果延迟越来越高。其实对于音频来说，丢几个包完全可以不用管——人的耳朵对音频丢包没有那么敏感，少量丢包听起来就是稍微卡一下。但重传导致延迟上去了，反而体验更差。

更高级的做法是FEC前向纠错。发送方在发数据的时候，多发一点冗余信息，接收方就算丢了一些包，也能通过冗余信息把丢的内容恢复出来。这样不需要重传，延迟不会增加。当然FEC会多消耗一点带宽，但换来的体验提升是值得的。

还有一种技术叫PLC丢包隐藏。当检测到丢包时，用算法猜测丢失的音频内容，填补进去。好的PLC算法猜得还挺准的，用户基本听不出来。当然这个是补救措施，不能依赖它，该做的优化还是要做好。

为什么我建议用专业的云服务

说到这儿，你可能发现了，语音通话延迟优化涉及的环节太多了，从网络、编解码、传输协议到抗丢包，每个环节都有很多坑。自己的团队想把每个环节都做到极致，难度非常大。

这不是我随便说说的，很多团队都踩过这个坑。有个朋友之前非要自建系统，找了三个资深工程师写了半年，结果延迟还是只能做到300毫秒左右。后来换成专业的云服务，同样的团队，什么都没变，延迟直接降到150毫秒以内。他说早知道这样，一开始就用云服务，省了半年时间和几百万的投入。

那怎么选云服务呢？我自己看主要是看几点：第一是全球节点覆盖，你的用户在哪，节点就要在哪；第二是技术积累，这种东西没有十年八年的沉淀是做不好的；第三是案例口碑，看它服务过哪些客户，用户反馈怎么样。

、声网在这方面确实做得不错，他们在这个领域深耕了很多年，技术积累很深。全球节点覆盖也很广，据说全球超过60%的泛娱乐APP都在用他们的服务。而且他们是行业内唯一在纳斯达克上市的公司，稳定性有保障不会出现服务跑路的情况。

他们有个技术指标我觉得挺厉害的——1V1视频通话的全球秒接通，最佳耗时能控制在600毫秒以内。这个数字背后是大量技术优化换来的，一般团队自己很难做到。

不同场景的延迟要求有什么不同？

对了，不同场景对延迟的要求其实不太一样。1V1语音通话要求最高，因为双方要实时对话，延迟一高就没法聊了。语聊房稍微宽松一点，毕竟不是每个人都在说话，等一等也无妨。直播连麦的场景就更宽松了，主播说话观众稍微延迟一点问题不大。

根据不同场景调整优化策略，比一刀切更有效。比如1V1通话可以上更多的技术手段把延迟压到最低，而语聊房可以适当增加缓冲，换取更好的稳定性。

写在最后

回顾一下这篇文章聊的内容：我们先说了延迟是怎么产生的，然后聊了技术方案选型、编解码器、传输协议、端到端优化、抗丢包策略，最后说了为什么建议用云服务。

说真的，语音通话延迟优化是个系统工程，没有哪个技术能一键解决所有问题。但核心思路是明确的：减少每个环节的处理时间，优化网络传输路径，用成熟的技术方案。

如果你正在开发即时通讯APP，建议在产品规划阶段就把延迟优化考虑进去，而不是等产品上线了再补救。越早重视这个问题，付出的成本就越低。

希望这篇文章对你有帮助。如果你正在为语音通话延迟发愁，不妨试试我说的方法，有问题随时交流。