经过五年的努力，腾讯云终端团队不断完善并积累出了一套完整的终端SDK方案体系，包含即时通信，主播推流，直播播放、点播播放、RTC实时互动、短视频录制，特效编辑等一系列音视频和实时通信相关的功能特性。在这些功能背后，团队是如何完成了框架设计、组件打磨、数据流转、性能优化的呢？本次LiveVideoStackCon 2021北京站我们邀请到了腾讯云的常青来从产品能力、架构设计、以及技术原理等多个角度进行剖析分享。

文 | 常青

整理 | LiveVideoStack

我们团队在腾讯云主要做音视频通讯类的SDK，这一部分包含功能相对比较丰富，包括RTC通讯、直播推流、播放器、短视频的录制、音视频的特效处理、还包括IM的技术通讯，种类方方面面，符合各种场景下的需求。现在大热的全真互联网会对业务产生新机遇、挑战。如何去面对机遇、迎接挑战是我本次分享重点，是技术部分内容和思想内容的融合。

1. 全真互联网

首先说一下全真互联网，不同的人有不同的理解，我以我的角度说一下对其的理解。全真互联网在我看来是四个更加，更加清晰、更加沉浸、更加强互动、更加低延时。

1.1 更清晰的画质

上图左边是腾讯云统计的所有端包括PC、PAD、手机全网流媒体平均观看码率。可以看出从2018年上半年到现在，每年平均码率都在慢慢增长。大家对观看清晰度的需求越来越高，在码率变高同时，压缩效率也在提升，从H.264到H.265到最近提交的100多个技术预案H.266技术，都是让码率的压缩比变得更好。比方说现在H.266可以比H.265多出50%的压缩率。

1.2 更好的沉浸感

沉浸式体验也在逐步拓展，例如3D导览、3D模型构建、AR、VR游戏、多点位赛事自由观看都是新交互体验创新。

1.3 更强的互动能力

更强的实时互动性方面例如可以通过手机采集面部点云，通过云端回馈到观众端做到很强的实时交互。

1.4 更低的互动延时

过去几年中感受最深的更快的延时方面，几年前网页上是十几、几十秒的延时，现在可以做一些几十毫秒级别的直播间实时合唱延时，可以看出延时在不断降低。

1.5 全真互联网的四大要素

所以更高的清晰度、更强的互动性、更佳的沉浸式体验、更低的延时共同构成了我所理解的全真互联网。这一块在背后云端和终端需要付出更多的努力，迎接更多的挑战。我们需要处理一些绕不开的困难。

2. 一座塔的故事

我是一个比较喜欢讲故事的人，我将从一座塔的故事开始分享我的一些感受。

2.1 《圣经》中的巴比伦塔

《圣经·旧约》中讲的是犹太教的故事。旧约中有七约，故事比较有意思，两个年轻男女亚当和夏娃，因偷吃禁果，创造孩子，由于孩子越来越多，相互斗争，上帝怒发洪水，上帝派诺亚造了一艘船救了动物，而诺亚的子孙们吸取前人的教训，齐心协力想要创造一个功绩-----一座塔，希望可以直通上帝。塔越造越高，上帝认为如果塔建成了，就没有他们搞不定的事情了，于是就让人类说不同的语言，相互产生隔阂猜忌，果然大家就放弃了造塔。

这是开场的第一个小故事，其中的问题在软件研发中也频繁出现，当团队在一起做一件事情时，随着项目的推进，发现面对的困难不仅仅是时间成本和需求还有思想的不一致，团队之间沟通成本很高，来自不同Team的成员有会不同习惯架构框架。

2.2 不同的“语言”

团队成员各自有非常喜欢的语言和设计理念。其中java和C++语言不是很对付还要写jni进行互通。在团队管理方面，有些人认为研发流程太少了不靠谱，而有些人觉得团队研发流程太复杂，不要那么顽固。以上方面都会导致整个团队心不齐，当事情恶化，就会导致“通天塔”造不起来。失败的项目太多了，即使克服了这些克服，是否其他问题能解决了呢。

2.3 小说中的巴比伦塔

再来说说第二个故事。一位华裔美籍科幻作家姜峯楠的处女作《通天塔》讲得是一个叫南尼的工人加入到造塔运动中，人人都很努力尽责，大家万众一心，几个世纪的时间一点点地将塔直通天庭。到了天庭之后，发现天顶是一个光滑的大理石穹顶，南尼和众人先用火烧，再用冷水快速冷却，让这些光滑的外壳逐渐碎裂，一层层拨开。直到主人翁南尼从一个年轻小伙干到了一个老人，他相信一定能够凿穿。终于有一天，天庭外壳凿穿，南尼九死一生后，看了一束光亮，穿过这道光亮，他爬了出来，是一片沙漠，沙漠中有一座塔，就是他们造的通天塔。当我读完这个故事之后，我感受到了无奈和无助，这是无法抗衡的宿命。

在软件研发过程中很常见，一群人聚在一起，立项后进入敏捷迭代，快速上线，不断地升级一个又一个版本，功能堆积，出现维护困难，直到发现实在难以维护，一致要求重构。于是，我们又开始一次斗志昂扬的立项，并且开始了新一轮的轮回。我在腾讯13年很少打破这个宿命，不知道大家是否遇到过这个问题。

2.4 产品研发是一个系统性工程

那我们怎么解决“语言不通”的问题，怎么打破“无限轮回”的宿命呢？其实工程学的老前辈们给我们指明了道路，产品研发是一个系统性的工程，我们应该更多地运用“系统取胜”的设计思路，比如我们熟知的两款国之重器，J20战斗机和99A坦克，就是系统取胜的典型代表。在这两款武器的设计之初，没有世界一流的技术可以使用。99A 坦克炮比不过莱茵金属，动力比不过豹2，装甲也拼不过 M1A1 的贫铀装甲，通过系统性优化让整辆坦克的综合素质是世界顶尖的。J20装鸭翼会让隐身性变差，但可以通过鸭翼提升气动性能，让飞机在动力一般的情况下也能完成非常高难度的机动性，满足防卫要求。所以将各个部件折中扬长避短，出来的系统非常有竞争力。

回到腾讯云现在的音视频服务，也是类似的一种思路，就是通过打通各个子系统和子服务，通过统一的架构设计、统一的通信语言以及统一的基础设施，完成整个音视频和通信服务的互联互通。这包括两个方面：

一个是 RT-ONE™ 音视频网络，它由 TRTC 实时音视频网络，IM 通信网络和 CDN 流媒体分发网络共同构成，在这些网络的互通过程中，我们将账号系统，无缝音视频数据的流转，以及监控系统和控制台都进行了打通和融合。效果比原来好很多。

另一个是 RT-Cube™ 视立方解决方案，完成了基础框架，架构设计、消息总线、线程模型、编译环境、监控模块以及测试系统的统一，在整个端上的组件进行很好的协同增强，无论使用一个或是多个功能，整个运转效果都会比之前好很多。

我主要是负责端方面，将与大家分享这些部分我们是如何达到协同统一系统化效果。

3. 面临的技术挑战

先说一下我们所面临的挑战，再去聊一聊如何解决。

3.1 挑战一：RT—Cube™ 的架构设计

挑战有很多比较有意思的东西。

第三个故事是机械手表中的陀飞轮，它被用来抵消地球引力对表芯中的“擒纵系统”的影响。这个模块要把游丝，叉式杠杆和“擒纵系统”都放在同一个轴上运作，而且还要能在运动时不停地转动，让地心引力的影响达到最小。它是人类设计的精密机械设备中的皇冠级产品。在两个世纪前，有个设备比它还复杂，英国数学家查尔斯·巴贝奇发明差分机，它可以用来算多项式求值，可以理解为这个机器可以给一组输入数字套计算公式，而且精度很高，很适合用来做 excel 里面的表格计算。机械设备能做到的精密程度是有天花板的，英国政府拨了很多钱这台机器完成了 1/7 ，但是每次演示都能惊掉一群人的下巴。每个部件都需要动力驱动它转动，部件与部件之间的衔接处会有误差，误差会被一层层的传递和放大，部件与部件之间的衔接处还会摩擦，以至于这台设备最终在 1985 年被做出来的时候，需要一个壮汉才能驱动。

我拿这个例子要讲的是第一个挑战。我们在做大到操作系统，小到SDK功能时，需要做到协同和运转和谐是很难的，SDK有很多模块。左下角是音视频的引擎，我只画了很小一部分，可以看出非常多。右下角是TIM的部分，上端的是TUI级的组件。多模块协同运作时会发生很多协同、咬合、CPU拼抢的问题。

以音频为例，上图是在 RT-Cube™ 中的音视频引擎的架构设计，它由很多个核心模块组成，而这些核心模块的内部又会有很多的子模块构建，模块之间会有大量的数据通信和控制逻辑。如果仅仅是这样，那么当系统处于平稳运行阶段，可能暂时不会有什么问题。但如系统的 CPU 出现降频，或者内存不太够用，各个模块的各自为战很快就会让整个系统快速进入崩溃的边缘。所以我们引入了一个中心控制模块，通过它来实时监控和协调各个模块的状态，并在必要的时刻采取干预，让各模块能够更好的协同以免发生雪崩。这是模块间协作解决的方法论。

3.2 挑战二：RT-Cube™ 的版本管理

第二个挑战是版本的问题，提供的功能非常多，不是所有客户都需要所有功能，要组合需要的功能。我们需要面对要有多少版本的问题。

为解决这个问题，引入德国数学家康托，他发明了集合论，子集，空子集，非空子集。假设如果一个集合有 n 个元素，那么就可以用这个公式算出这个集合的所有非空子集的个数。集合论的意义远不与此，它奠定现代数学的理论基础，真正意义是在于能够用集合论定义和解释几乎所有传统数学的理论定义。现代科学基于数学构建。但由于康托理论太过超前，被人当成了神经病，被送进哈雷-维滕贝格大学的附属医院。但他的理论是不能被驳倒的。

如果SDK中有 9 个功能，按照客户需要要进行自由组合，根据公式，可以算出大概需要提供510 种版本，且还要提供四个平台的实现将510*4，2000多个版本。当我跟产品团队的同事们介绍这个数字的时候，他们觉得我不仅仅认同康托的理论，而且也应该获得跟康托先生晚年一样的待遇。

为了解决这一问题，需要抛弃传统的平台相关的编译工具，比如 Xcode、Android Studio等，建立一套全新的编译平台，它可以使用一套编译方案，同时输出不同平台的 SDK，而且可以做到自由组合，通过这种方式使版本功能组合更加灵活容易。

3.3 挑战三：RT-Cube™ 的质量监控

第三个挑战是质量监控，要解决这个问题，引出一个老奶奶，她叫勒维特，是哈佛大学天文台的一名计算员，每天对着星空的感光胶片监控星星，记录其亮度变化和运动情况，恒星是不会动的，一旦运动，肯定是行星。不过大家要注意，这是在1893 年的时候，伟大的毛爷爷刚刚出生，那时女性的地位非常低，她本着兴趣一天到晚重复枯燥的工作，最终她发现越亮的恒星，亮度变化周期也就越长，周光关系的公式规律，被后来的天文学家发现可以用来检测我们地球和星星之间的距离远近，且银河系不是宇宙中唯一的星系，还有很多系外星系。

上述的这个故事的问题对于我们也非常难。假设做一个产品，现有6个人看一场直播或视频会议，其中一人在20分钟时间内卡顿10秒，其他5个人在20分钟时间内都没卡，在监控中卡顿率是0.13%。10秒的卡顿是很糟糕的，如果按照人数来算占16.7%，很多时候，质量监控解决的问题是将不好Case在很多数据中眼尖的挑出，是决定产品好坏的关键点。解决单个用户的糟糕体验会被海量的上报数据淹没的办法，首先基础设施不能变，每天都要上报上一条数据包括卡顿、大小、画面不流畅、模糊、有回声。数据要用细致算法基于用户指标算出体验糟糕。接下来对它的数据进一步分析，找出大概的用户数量、占比数量增长或减少、变差原因。从万繁星中找到改进点。

3.4 挑战四：模块间通信的效率

第四个挑战是模块间的通信效率。这次是可能很多人都知道的例子——著名的阿波罗13号，原本要成为第三艘在月球着陆的宇宙飞船。在半路上飞船的3个氧气罐中有两个爆了，导致飞船的电能和氧气供应都非常紧张。三人挤到登月舱，由于这里的氧气是多出来给给两个人登月用的，多了一个人，呼出来的二氧化碳也就多了一份，二氧化碳滤芯提早用完。从指令舱拿出滤芯用，发现一个是圆的，一个是方的，不匹配。最后是休斯顿基地指挥中心让其用塑料袋胶带凑合，一路回来。

这个问题在游戏端非常常见，后台系统很多公司都会统一，例如SDP标准协议，微服务概念语言等。但端iOS、Android、Windows不是我们所能改变的，想要用C++进行跨平台统一，面对的问题挑战巨大。其中苹果视频处理纹理图像格式、安卓格式、Windows的D3D都有很多差异，到C++上都是二进制的Buffer来解决问题，所以要想保证之间通讯不出现如阿波罗十三号拿方形滤芯往圆形的孔塞的情况，需要进行很多统一适配和努力。这个问题最终被克服，数据在各平台间的流转也没有太多性能损耗。

4. 完成的优化与改进

上述是面对挑战及面对措施。接下来说一说在这一套基础设施革新升级完成后半年到一年内的优化与改进。这一部分偏技术一些。

4.1 改进一：音频模块的进化

4.1.1 功能

通过对架构的升级，我们最新版本中的音频模块支持了很多新的能力，比如对声音全频带得支持，对3D空间音频特效得支持，基于深度学习的 AI 降噪以及信源信道相融合的抗损伤技术。基于这些新的能力，我们可以实现更多更有挑战的实时交互需求，比如对音视频通信延迟要求极低的在线实时合唱功能；再比如在音乐直播场景中，我们针对音乐模式进行了诸多优化，可以最高还原度地保证高解析度的音乐音质。同时，我们也通过一系列大数据分析手段，对声音的各种问题进行定向监控和实时分析，在音频质量上不断地压低故障率和投诉率。

4.1.2 使用

在音频使用上进行人性化改造。我们给出一些比较容易选择档位，对于会议通讯场景可以使用Speech模式；对于不太确定的场景可以使用Default，比较“万金油”；对于主打音乐可以用Music音质模式；还提供如游戏般全定制设置，自定义所有想要的参数。

4.2 改进二：视频模块的进化-效果

我们对视频模块的整体效果也进行了一定的提升，比如在色彩空间上优化了对 bt601 和 bt709 这两种色彩空间的的处理算法，同时也增加了对 bt2020 等 HDR 相关色彩空间的支持。这使得画面的亮度更加饱满。同时，在清晰度方面我们也进行了一系列的定向优化，使得在同码率水平下，我们的 SDK 可以获得更好的清晰度效果。

4.3 改进三：网络模块的改进

4.3.1 架构

最后是网络模块，是我们赖以生存，最拿得出手的核心技术。这一部分对于流控，整体化改造做了大幅度升级。上图中可以看出云和端一体，整个系统都不是单独模块战斗，是由很多模块共同协助。中控大脑做了多轮基于数据的改进。

4.3.2 推流

网络模块还有一些较为细节的部分。我们把场景主要分成两种直播类和通讯类。直播类在上行算法处理更加注重清晰，保证平滑。到RTC通讯类，例如腾讯会议，更偏重于实时，尽量保证中间流畅，不出现延时变高、卡顿问题。

4.3.3 播放

播放这一部分，腾讯在直播场景非常靠前，CDN竞争力很强，与此同时在不断拓展新场景，例如快直播，除了标准浏览器，可以通过SDK实现比浏览器更好性能、更多格式支持的效果体验，可以做到将近1s左右延时，对苛刻场景适用。如果假设延时要更低更强互动，如语言聊天场景，更多去优化上下麦的平滑，开麦到不开麦场景的无缝衔接。

4.4 改进四：TUI组件库

我们还进行TUI组件库的升级和补充。用这些PaaS组件最痛苦的是每个组件都很专业，上百个接口需要投入很大心血，做出的不一定比一些标准产品好。我们提供面向各平台的组件库，需要花的努力大概只有几分钟，将库导入，几行代码牵动。这一部分如上图界面，大多数一个上午甚至一个上午就能够构建出，非常容易，不需要很有经验就能作出好的效果。

5. 总结

最后做一下总结。

本次主要讲的是系统化设计，将各个部件进行整合，完成1+1>2的过程。

在云端，我们成功地完成了三网的融合，即 TRTC 实时音视频网络、IM 即时通信网络以及 CDN 流媒体分发网络。

在终端，我们一方面不断地优化已有功能的稳定性和性能表现，比如通过更多应用场景和大数据分析的夹逼，让 RTC SDK 的各方面素质都达到业内一流水准。与此同时，我们也将新推出的快直播 SDK 和新内核的IM SDK融入到这个体系中，共同构成强大的 RT-Cube™ SDK 架构。

再加上界面完成度很高的 TUI 组件库，共同构成一个强大且易用的 PaaS 体系，为构建全真互联网提供更多的基础能力组件。

视立方可以在上图网站上下载，现在放的是比较常用版本，后续定制能力会在随后编译系统健壮性更强后逐步开放，可以根据自身需要，随意组合功能，生成最需要的版本。

以上是我本次分享的主要内容，非常感谢。