TOP100summit：【分享实录-QQ空间】10亿级直播背后的技术优化

本篇文章内容来自2016年TOP100summit QQ空间客户端研发总监王辉的案例分享。
编辑：Cynthia

王辉：腾讯SNG社交平台部研发总监、腾讯QQ空间移动客户端技术负责人高级工程师。09年起负责QQ空间技术研发，经历从Web时代到移动客户端技术的转变，在Web、移动终端上都有不错的技术积累。

导读：移动互联网飞速发展，2016年，社交网络对视频技术的应用获得爆发式的增加，短视频、视频直播、视频滤镜、视频人脸动效、音乐、K歌、变声、连麦等功能陆续在产品中上线，如何在快速上线功能的同时，保证稳定流畅的体验，成为挑战。
主要面临的挑战以下：
一、复杂的网络环境下，如何保证视频播放的成功率，如何保证直播的流畅度，减小卡顿？
二、体验上，如何保证快速流畅的播放体验，如何实现直播秒开，即点即播？
三、性能上，直播中滤镜、美容、人脸动效，效果全开，如何保证主播端的性能？
四、亿级海量并发用户状况下，如何更好的保障质量，柔性带宽的策略如何作到极致？
本案例围绕上述挑战进行，揭秘腾讯QQ空间团队在挑战中的一些优化尝试。

1、案例介绍

QQ空间目前是国内最大的SNS社区，日高峰上传5亿张图片，播放10亿个视频，6.3亿用户在这里分享生活，留住感动，其中主流人群正是95后的年轻人。
也正由于是年轻人，且年轻人是生活方式转变的主要推进力，不知足于如今图片+视频传统的分享方式，他们但愿经过直播的方式让你“如今、马上、立刻”看到我。这就是内容消费的升级，同时伴随着手机硬件的升级、流量费用的降低，因而手机直播变为可能。
而咱们的直播产品定位也是基于目标用户生活的内容，外加社交的传播力量，有别于如今主流的网络+游戏直播的模式。
带来的好处是：用户创造的内容更多元化，更贴近生活，更能在好友间产生共鸣和传播；
带来的问题是：咱们要兼容的移动终端也是海量的，性能问题是咱们重点关注的内容。

在以上背景下，咱们开始作直播了。目标是一个月内构建直播的闭环能力，也就是快速上线。须要实现发起直播、观看直播（1人发起，多人观看）、回看直播（回放）、直播互动（直播间中的评论、送礼等）、直播沉淀（Feeds沉淀、分享直播等）等功能（可参考图1）；且同时支持Android、iOS、Html5三大平台（即方案成熟），而且支持空间以及手机QQ内的空间。

首先咱们就面临项目工期紧张、团队直播技术积累不够的问题。虽然如此，但咱们仍然硬着头皮继续与各大相关技术提供商进行交流，根据咱们的标准以及提供商的建议进行技术选型，咱们的标准以下：
● 专业度好（直播低时延迟，支持全平台、基础服务建设好）；
● 开放源代码；
● 支持度高，有问题能够随时沟通解决；
● 支持动态扩容。

最后根据标准选择了腾讯云提供的ILVB直播解决方案，尤为音视频相关组在这块有多年技术积累，而且同部门可合做双赢。
这其中值得一提的是咱们的闭环研发模式也促使咱们以及合做伙伴不断提高产品质量。首先快速上线（完成产品需求，并完善监控），再在上线后查看监控数据（分析数据），接着应用到优化工做（跟进数据、专项优化），最后进行灰度验证（灰度一部分用户验证优化效果），根据效果再决定是否正式应用到产品中（如图2）。

最后，咱们如愿实现了1个月上线，同时支持QQ空间和手机QQ(结合版QQ空间)，到目前为止已经迭代12+版本。观看量也从5月份的百万级到8月份的千万级、到如今的亿级，成为用户参与的大众化全民直播。产品数据也跟随用户的需求一直在飙升，随之而来的是各类各样的问题反馈，尤为是性能问题，这也是本文要重点讨论的话题。

2、直播架构

在介绍直播架构前，我想有必要给你们再复习一下H264编码，目前市面上直播的视频编码基本都是H.264。H264有三种帧类型：完整编码的帧叫I帧、参考以前的I帧生成的只包含差别部分编码的帧叫P帧、还有一种参考先后的帧编码的帧叫B帧。H264的压缩流程为分组（把几帧数据分为一个GOP，一个帧序列）、定义帧类型、预测帧（以I帧作为基础帧,以I帧预测P帧,再由I帧和P帧预测B帧）、数据传输。
用简单的例子来解释视频模型，若是把一个GOP(Group of pictures)当作一列拉货的火车，那一段视频就是N辆火车组成的货运车队（图3）。

直播就是视频数据的流动，边拍摄、边传输、边播放的数据流动过程。数据由主播生产装车，通过网络（铁路），再到观众端卸货并进行播放消费。
火车须要调度，视频流也同样，这就是视频流协议，即经过协议控制视频有序的传输给观众。
常见协议如图4：

咱们采用的是腾讯云基于UDP开发的QAVSDK协议。

前面讲了协议相关的内容，下面讲讲咱们的直播模型，如图5：

视频房间（视频流）以及业务房间（相关业务逻辑互动）大体结构差很少，差异在于数据流动（注意图5中箭头）。
视频房间数据由主播经过视频流协议流向视频服务器，而视频服务器也经过视频流协议把数据下发给观众，观众端解码并播放。主播只上传，观众只下载。而业务房间任何人都须要给服务器发送相关的业务请求（如评论，固然客户端会屏蔽一些特殊逻辑，如主播不可送礼给本身）。更详细的结构如图6：

注：iOS手Q观众采用RTMP协议不是由于不支持QAVSDK，而是由于手Q有减包压力，而QAVSDK相关的SDK占用空间较大。

3、技术优化

接下来进入本文的重头戏：技术优化。技术优化分为四个方面：秒开优化（耗时类优化实践）、性能优化（性能优化实践）、卡顿优化（问题分析类实践）、回放优化（成本类优化实践）。
在优化以前，咱们的必要工做是监控统计先行，咱们会对咱们关心的数据点进行前期的统计，并作相关报表和告警，以辅助优化分析。
监控分为如下五部分：
● 成功率，发起直播成功率、观看直播成功率、错误占比列表；
● 耗时，发起直播耗时、进入直播耗时；
● 直播质量，卡帧率、0帧率；
● 问题定位，各步骤流水、直播2s流水、客户端日志；
● 实时告警，短信、微信等方式。

经过这些，咱们实现了数据的查看、分析定位、以及实时的告警，从而更方便地解决问题。

4、秒开优化

几乎全部人都在吐槽“为何直播打开很慢，竞品比咱们快多了！！！”，咱们本身也以为不能忍。咱们要让观看直播达到秒开（从点击直播到看到画面，耗时在1秒之内），而统计到的外网平均打开耗时为4.27秒，离秒开还有必定的差距。
因而咱们梳理从点开到渲染第一帧画面这一段时间的时序关系，同时统计各阶段的耗时。流程图和耗时大体如图7 ：

经过流程分析和数据分析发现两个耗时缘由是：获取首帧数据耗时太长、核心逻辑串行。接下来咱们针对这两个问题进行优化。
首帧耗时太长。核心问题在于加速首个GOP到达观众的时间。
咱们的优化方案是：让接口机缓存首帧数据，同时对播放器进行改造，解析到I帧就开始播放。这样大大加快了观众看到首帧的时间。
核心逻辑串行。这部分咱们主要经过如下流程：
● 预加载，提早准备环境和数据，如在feeds中提早预拉起直播进程，提早获取接口机IP数据；
● 延迟加载，对UI、评论等其余逻辑进行延迟加载，让出系统资源给首帧；
● 缓存，如缓存接口机IP数据，一段时间内复用；
● 串行变并行，同时拉取数据，节省时间；
● 对单步骤耗时逻辑进行优化和梳理，减小单步耗时。
优化后的流程和耗时大体如图8所示，耗时下降到680ms，目标达成！

5、性能优化

产品不断迭代，直播的玩法也愈来愈丰富了，同时一些性能问题也不断暴露出来。尤为咱们后来增长了动效贴纸、滤镜、变声等功能，大量用户反馈直播很卡。
经过统计发现：主播短帧率很低，画面不连续，主观感受卡；另外，用户使用设备中也有大量的低端机。如图9所示。

经过分析发现帧率低的主要缘由是单帧图像处理耗时过长致使，而编码所占因素较低。通常总耗时=处理工做量*单帧耗时。因而咱们逐渐对这两方面进行优化。

减小图像处理工做量
● 采集分辨率与处理分辨率一致，好比编码为960×540，因为有些手机可能不支持这个采集分辨率，采集通常都是1280*1024，以前处理是先处理再缩放，如今先缩放再处理，减小图像在滤镜、动效贴纸中的处理耗时。如图10

● 处理帧前丢帧。虽然咱们对系统相机设置了采集帧率，可是不少机型并不生效，因而咱们经过策略对额外的帧进行丢弃，减小图像处理的帧数。好比咱们设置采集帧率为15，但实际有25，这多余的10帧处理了在编码的时候也会浪费，以前就丢弃，可减小资源消耗。
● 机型分档位，不一样的机型根据不一样的硬件能力采用不用的采集帧率和编码帧率，保证流畅；同时在过热的时候以及回归正常时动态调整帧率去调整资源消耗。
● 人脸识别采集优化，每帧识别改成两帧识别一次人脸，既不会产生人脸漂移也能够减小处理耗时。
减小单帧耗时
● 采集流程改造，减小了大约33%的没必要要耗时，如图11.

● 动效贴纸多GL线程渲染，贴纸渲染放在另一个OffScreenThread进行渲染，彻底不占用整个美化处理过程的时间，效果如图12：

● 动效贴纸采用OpenGL混合模式；
● 图像处理算法优化，如ShareBuffer优化（实如今GPU与内存之间快速拷贝数据，排除CPU介入，节省纹理转RGBA时间；耗时几乎下降一半，FPS也至少提高2-3帧左右），滤镜LUT优化，如图13.

除了以上两个大的优化点，咱们还推进更多的机器采用硬件编码。首先编码稳定，帧率不会波动；其次，占用CPU会有必定下降。
以上是咱们大体的一些优化点，优化以后，用户直播投诉大量减小。

6、卡顿优化

咱们先看一些相关的定义：
卡顿用户定义：（卡顿时长/总时长）>5%定义为卡顿用户，卡顿率＝卡顿用户/总用户。
主播卡顿点定义：上行大画面编码后帧率<5的点数。
观众卡顿点定义：解码后帧率<5的点数。
咱们的目标就是让卡顿率达到50%如下。
固然上行发生卡顿时，会形成全部用户卡顿，而下行卡顿时，只有单个观众才会卡顿。
咱们看看会形成卡顿的缘由，见图14 ：

大概有主播端、网络、观众端三个大的模块可能会致使卡顿问题，而主播端的性能优化基本解决了，那就看下网络以及观众端的。
从统计数据发现网络质量影响占比达到50%左右，这明显要优化。因而网络上行优化咱们作了图15的事情，减小单帧中的数据以及减小帧数，用火车的例子就是减小货物以及控制火车数量。

而用户端下行优化则是囤积货物，丢掉货物，如图16 。

如图17，咱们来看优化后的效果，与竞品相比优点十分明显：

同时，主播卡顿率也降低到30%，观众卡顿率降低到40%，目标算是达成了。

7、回放优化

如图18，咱们先来看看直播回看（回放）的大体流程：

回放一样也存在一些问题，主要体如今两个方面：
● 回放直播质量：服务器器端保存，回看视频质量受主播短网络影响较大
● 服务器成本：服务器除了须要推一个私有协议流，另外还须要对私有流进行转码成HLS和MP4以便回放使用

在方案选择上，MP4具备播放方案成熟、速度快、用户体验佳等优势；而HLS系统支持差、用户等待时间也长。那是否意味着咱们要直接选择MP4方案呢？
其实回看采用HLS以及MP4都是能够的，可是直播观看时因为数据是在变化的，HTML5只能使用HLS，若是咱们回看的时候使用MP4，那就等于服务器须要对私有协议流分别转码成MP4和HLS，那这明显不经济。这就导致咱们选择HLS，服务器只须要转码一次流为HLS便可。
既然选择HLS，咱们就要针对性地解决HLS存在的问题。
在Android平台上，Android 3.0开始支持HLS，后来由于Google官方想推DASH取代HLS，对HLS的支持便慢慢减弱了，在官方文档上甚至找不到一点儿关于HLS的说明。经实践发现Android原生播放器对HLS的支持程度仅仅是能播，彻底没有任何优化。这样不只会有多余的m3u8文件请求，并且启动播放后整个流程是串行的，很是影响视频画面的首帧可见耗时（平均耗时4.5s左右）。
咱们能够经过本地代理提早下载来解决这个问题，接入下载代理后，在代理层能够对m3u8文件的内容进行扫描，并触发对ts分片的并行下载，把ts数据缓存起来。通过这样的处理后，虽然播放器的层面仍是串行下载，因为咱们已经提早准备好了数据，数据会很快返回给播放器，这样就实现了咱们下降首帧耗时的效果，经实验接入后平均首帧可见耗时下降到了2s左右。
优化先后流程图见图19：

缓存策略上，HLS的缓存业界目前尚未成熟方案。咱们实现了对图20中三种模式的自动侦测与支持，使用方彻底不须要关心底层的缓存与下载逻辑。

最后，服务器成本方面节省了50%的转码计算和存储成本；另外，回放的加载速度也变快了。

8、案例总结

经过以前的案例和相关优化分析，总结出三种大体的问题模式，以及相应的优化思路。
● 速度类：理清时序，统计各阶段耗时，各个击破；
● 性能类：经过Trace，明确性能损耗点，各个击破；
问题解决类：创建模型，初步分析，统计上报，确认问题，各个击破。

总结成一个套路就是图21 ：

在案例中也体现了如下一些参考点：
● 快速迭代，小步快跑
● 监控驱动优化
● 创建模型，抽象问题直观分析
● 产品定位决定优化的方向
● 海量服务，以小省大

最后，以一张空间直播的拓补图做为结束本文（图22）。

TOP100全球软件案例研究峰会已举办六届，甄选全球软件研发优秀案例，每一年参会者达2000人次。包含产品、团队、架构、运维、大数据、人工智能等多个技术专场，现场学习谷歌、微软、腾讯、阿里、百度等一线互联网企业的最新研发实践。大会开幕式单天体验票申请入口