rtc源码性能优化：那些年我们踩过的坑和找对的路

做rtc这行有些年头了，印象最深的一次事故是去年双十一那天晚上，直播间突然炸了。那时候我们团队所有人盯着监控面板，看着延迟从100ms一路飙到3秒多，丢包率冲到百分之二十多，用户投诉像雪花一样飞过来。那天晚上我们紧急拉会，一个同事说了一句让我至今还记得的话：”平时跑得好好的，怎么一到关键时刻就拉胯？”这个问题其实问到了点子上——RTC系统的性能优化，从来不是一蹴而就的事情，而是需要在源码层面不断打磨。

今天想和大家聊聊，我们在RTC源码优化这条路上积累的一些经验和思考。文章不会面面俱到，但会把几个最核心的优化方向讲透。说是经验总结也好，踩坑记录也罢，希望对正在做这方面工作的朋友有些参考价值。

一、先搞明白：RTC性能到底在优化什么？

在动手改代码之前，我觉得首先要弄清楚优化目标是什么。RTC场景下的性能优化，说白了就是要在有限的资源条件下，让音视频数据以最快的速度、最少的损耗从一端跑到另一端。这个过程涉及好几个关键环节，每个环节都有优化空间。

我习惯把RTC系统拆成几个核心模块来看：采集编码、网络传输、解码渲染。外加一个贯穿所有环节的缓冲区管理。这四个模块就像接力赛里的每一棒，任何一棒掉链子，整体体验都会受影响。下面我会逐一展开讲每个模块的优化思路。

二、音视频编解码：CPU占用的大户

编解码这一块，向来是CPU消耗的大头。早年我们用的是开源的编解码器，参数配置也比较粗放，跑起来CPU占用率经常在百分之七八十徘徊。后来我们花了很大力气在这块做优化，效果还是比较明显的。

2.1 编解码器的选型与调优

编解码器的选择是第一个要考虑的决策点。我们在项目中做过对比，同一个视频画面，不同编码器出来的码率和质量差别还挺大。后来我们固定下来几套针对不同场景的编码配置：高清会议场景用H.264的高质量预设，带宽紧张时就切到H.265，这些配置现在都做成可动态切换的了。

参数调优这块有个细节想特别说说。GOP（图像组）大小的设置直接影响延迟和画质。我们最开始用的是标准的30帧GOP，后来改成动态GOP——运动剧烈时自动缩短GOP，静态画面时拉长GOP。这样做既控制了码率，又不会在画面切换时出现明显的块效应。另外，参考帧数量的优化也很关键，之前我们一直用默认值，后来改成根据场景自适应调整，编码效率提升了大概百分之十五左右。

2.2 硬件加速的正确打开方式

现在主流平台都有硬件编解码能力，但实际用起来坑不少。我们第一次接入硬件编码器时，欢天喜地地测了一波，发现CPU占用确实降下来了，但码率波动特别大，画面质量也不稳定。后来仔细研究才发现，硬件编码器的码率控制策略和软件不太一样，需要做额外的适配。

这里有个经验：硬件加速不是开箱即用的，必须配合细致的参数调优。比如在Android平台上，不同芯片厂商的硬件编码器行为差异很大，有的对QP敏感，有的对帧率敏感。我们后来做了一套自适应策略，根据设备型号和芯片平台选择不同的参数模板，这套模板是实测出来的，不是理论推导。声网在这块积累了大量设备的适配数据，这确实是个苦活累活，但值得做。

2.3 码率控制：这是个技术活

码率控制直接决定了带宽利用率和画质。早期的恒定码率（CBR）模式在带宽波动时很被动，经常要么画质糊成一团，要么卡顿丢帧。后来我们改成了动态码率控制，根据实时带宽探测结果动态调整目标码率。

这个动态调整策略迭代了好几个版本。第一版很简单，带宽探测结果出来直接设置目标码率，结果带宽突然下降时调整太慢还是会卡顿。第二版加了缓冲区的预警机制，当队列积压超过阈值时主动降码率，但这样又经常过度降码导致画质波动。第三版，也就是现在用的这套，引入了预测模型，不仅看当前带宽，还预估未来几秒的带宽趋势，提前做调整。虽然没法做到百分之百准确，但整体体验已经稳定多了。

三、网络传输：延迟和丢包的博弈

如果说编解码是CPU的战场，那网络传输就是延迟的主战场。RTC场景下，网络问题从来不是简单的”好”或”差”，而是一个复杂的博弈过程——我们要尽可能降低延迟，同时又要在丢包发生时保证音视频的连续性。

3.1 拥塞控制算法：不是越激进越好

拥塞控制算法是网络传输的核心。早期我们用的是标准的BBR算法，在实验室环境下表现很好，但上了生产环境发现水土不服。问题出在BBR的探测机制上，它会主动探测可用带宽，在高并发场景下这种探测会产生额外的延迟，反而影响实时性。

后来我们基于BBR做了一些改进，引入了”探测平滑”机制。具体来说，就是把探测周期拉长，单次探测的步长减小。虽然探测效率略有下降，但整体延迟更稳定。另外，我们还加了场景识别逻辑——当检测到对端处于弱网状态时，自动切换到更保守的拥塞控制策略，不再一味追求带宽利用率。

3.2 抗丢包：FEC和ARQ的平衡艺术

丢包是网络中不可避免的情况，处理丢包的方式主要两种：前向纠错（FEC）和重传（ARQ）。这两者各有优缺点，FEC会增加额外带宽但能实时恢复，ARQ不占带宽但需要等待往返时延。

我们最初的做法是统一用FEC，冗余度设为固定值。但实践中发现，不同丢包率下固定冗余度效果很差——丢包少时冗余浪费带宽，丢包多时冗余不够还是会有卡顿。后来改成了动态FEC冗余度策略，根据实时丢包率动态调整。实现上我们用的是异或FEC，计算开销小，恢复速度快，适合实时场景。

至于ARQ，我们用得很克制，只对关键帧开启重传。因为关键帧丢了会导致后续帧都无法解码，而普通帧丢了影响相对小一些。这个策略帮我们节省了不少带宽，同时保证了基本的视频质量。

3.3 弱网策略：降级而不是放弃

弱网是RTC永恒的挑战。我们很早就意识到一个问题：当网络真的特别差的时候，与其勉强维持高清流畅，不如主动降级保证可用。所以我们设计了一套阶梯式弱网降级策略。

这套策略分为几个级别。网络轻微变差时，先降低码率和帧率，优先保证延迟；再差一些时，切换到更激进的编码配置，甚至考虑降低分辨率；如果检测到持续高丢包，会启用超级帧模式——把多帧数据合并成一帧发送，牺牲帧率换取传输稳定性；最后万不得已的时候，进入最低质量模式，只传输音频和关键信息。

这套策略的关键是切换要平滑，不能让用户感受到突变。我们用了交叉淡入淡出的技术，上下文切换时有几帧的过渡，画面不会跳变得太突兀。

四、缓冲区管理：延迟和卡顿的跷跷板

缓冲区管理是我觉得最容易被忽视、但实际上影响非常大的环节。缓冲区大了延迟高，缓冲区小了容易卡顿，这两者需要精细的平衡。

4.1 自适应抖动缓冲区

我们最早用的是固定大小的抖动缓冲区，设为120毫秒。这个值在网络比较稳的时候没问题，但网络波动时要么不够缓冲导致卡顿，要么缓冲区爆了导致延迟累积。后来我们实现了自适应抖动缓冲区，能够根据实时网络状况动态调整大小。

这个自适应算法有几个关键设计。首先是趋势判断，不仅看当前延迟，还要分析延迟的变化趋势。如果延迟在持续上升，说明网络在恶化，需要提前扩容。其次是快速收敛，当网络恢复稳定后，要尽快把缓冲区缩小，不能一直维持在高位。最后是异常值过滤，网络偶尔的抖动不应该触发缓冲区调整，不然会导致缓冲区大小频繁波动，反而影响体验。

4.2 播放平滑：插帧和丢帧的抉择

当网络抖动导致音视频数据到达时间不一致时，播放端需要做取舍：是等齐了再播（可能增加延迟），还是抛弃晚到的帧（可能造成卡顿）。我们在这块做了很多实验，最终确定了一套基于场景的决策逻辑。

对于音频，我们采用的是等待策略，因为人对音频中断更敏感，少量延迟可以接受。但等待时间设有上限，超过阈值就静音替代。对于视频，考虑到人对帧率波动相对容忍，我们用的是动态丢帧策略——当滞后帧数超过两帧时，果断丢弃中间帧直接跳到最新帧，保证画面基本流畅。为了让丢帧不那么明显，我们还加了帧复制技术，丢掉的帧用前后帧插值代替，虽然画质略有损失，但比直接跳帧自然多了。

五、内存与线程：容易被忽视的基础设施

前面讲的都是业务层面的优化，最后说说基础设施层面的东西。内存和线程管理虽然不直接体现在功能上，但对整体性能影响很大。

5.1 内存分配优化

RTC场景下音视频数据吞吐量大，内存分配和释放非常频繁。我们分析过性能数据，发现大量的CPU时间花在了内存管理上。后来做了几个优化：一是禁止在音视频核心路径上进行动态内存分配，所有缓冲区都预先分配好；二是使用内存池技术，复用已分配的内存块；三是针对小内存分配，改成了定长内存池，避免碎片化。

这套优化做完，内存分配的CPU开销降了大概百分之四十，效果还是很明显的。不过内存池的管理逻辑比较复杂，调试时遇到过一次内存泄漏，查了两天才找到问题所在。所以我的建议是，内存池能用但要用得小心，加上完善的监控和检测机制。

5.2 线程模型设计

线程模型的合理与否直接影响系统的并发能力和响应延迟。我们早期的设计是每个模块一个线程池，结果发现线程太多，调度开销大，而且模块间通信经常需要跨线程同步，延迟不可控。

后来重新设计了线程模型，核心原则是”数据驱动”而非”模块驱动”。简单说就是按照数据流的走向划分线程阶段，每个阶段专注于自己的事情，尽量减少跨阶段的数据传递。具体实现上，我们用了流水线模式：采集编码一个阶段，网络收发一个阶段，解码渲染一个阶段。阶段之间用无锁队列通信，既保证了并发性，又避免了复杂的同步逻辑。

线程绑定也很重要。我们把不同类型的任务绑定到不同的CPU核心上，音视频编码这种计算密集型任务独占大核心，网络收发这种IO密集型任务放在小核心上。这样做既提高了缓存命中率，又避免了核心切换带来的开销。

写在最后

这篇文章写了我断断续续好几天，有些地方反复删改了好几遍，生怕说得不够准确，又怕太技术化大家看不下去。后来想想，也就这么着吧，都是实实在在踩过的坑和总结的经验，没必要追求完美。

RTC的性能优化这条路，说实话没有终点。网络环境千变万化，用户设备参差不齐，总会有新的问题冒出来。我们能做的，就是保持敬畏之心，持续学习和改进。声网在这行干了这么多年，最大的感触就是——细节是魔鬼。很多看起来不起眼的小优化，积累起来就是质的变化。

如果你也在做RTC相关的工作，欢迎大家一起交流。优化这条路，一个人走走得快，但一群人走才走得远。

td>平滑BBR、动态FEC、阶梯降级

td>自适应抖动缓冲区、动态丢帧策略

td>内存池、无锁队列、线程绑定