QQ空间直播秒开优化实践

2016年应该是直播元年,直播应用百团大战,QQ 空间也在6.5版本上线了直播功能,从无到有、快速搭建了直播间。“先扛住再优化”,第一个版本和竞品相比,我们进入直播间的速度比较慢。根据外网统计在6.5版本的用户端看到画面需要4.4s,因此在6.5发布之后,着手启动了优化工作,目标:观看直播需要达到秒进体验(1s内看到画面)。

先上一张直播间的截图:

一、优化效果
1)实验室数据(小米5 WIFI)30次平均进入时间475ms

2)外网运营数据 (6.5版本 对比 6.5.3版本)

从外网运营数据看,观看成功率提升到99.41%;观看延时提升到平均2.5s,加快43.5%。用户进入直播间的时间区间在(0,1] (观看端0-1秒内进入成功)的占比提升到19.52%,提升191%。

3)与竞品对比 (左侧空间 VS 右侧竞品)

https://v.qq.com/iframe/preview.html?vid=x0306f83wfv&

4)总结

1、优化可以拔高速度上限,能使用户进入直播间的耗时上限提高到 500ms 以内,从(0,1]的占比区间提升,对大量用户的提升还是比较明显的。

2、直播是强依赖网络状况的产品。如果主播的网络条件很差,上行丢包严重时,观众卡在这个时间点进入,由于没有上行是拉取不到首帧数据的,这种情况会导致统计数据被拉高。这也是整体平均时间未到 1s 以内的原因。

二、QQ 空间直播的架构

在前期技术选型上,综合考虑开发周期,稳定性和质量监控体系,我们选用腾讯云的现有视频互动直播解决方案,以下是整体的架构图。

1、 直播房间使用 roomid 做唯一 key。逻辑上分为两层。音视频房间,主要负责和腾讯云的流媒体服务器通信音视频数据和 音视频房间状态的维护;消息房间,主要负责和空间的服务器进行交互,包括赞,评,打赏等业务逻辑和消息房间的状态维护。消息房间通过注册接口来响应音视频房间的状态。这样设计好处就是,消息房间和音视频房间是解耦的,各自单独运行都是允许的;

2、 观众端可以通过音视频 sdk、RTMP 或 HLS 协议三种方式收到主播的推流;观看场景涵盖 H5,native 多平台。

3、 直播浮层设计为独立进程,主要是考虑到独立进程 crash 不影响主进程的稳定性;缺点是和主进程的通信复杂,进程启动有部分耗时;

三、耗时分析
我们将观看直播耗时的各阶段拆细分析:

1、 整个观看直播的流程是串行的,导致整体耗时是每个步骤的耗时累加。

2、 拉取房间信息,拉取直播参数配置,拉取接口机 IP 是三个网络请求,耗时存在不稳定性,一般是 300ms,网络情况不好就会到 1000ms+;

3、 直播进程的生命周期是跟随 avtivity 的生命周期,activity 销毁后,进程也随之销毁,再打开需要耗时重新创建进程。

4、 视频 SDK 的上下文是依赖直播进程,新进入也需要重新初始化。

5、 拉取首帧数据是单步骤耗时最久,急需解决。

四、确立方案,各个击破

根据直播的具体业务来分析,我们确立了以下几个解决的纬度。

速度优化一般有以下几个方向来解决问题:

1、 预加载。

2、 缓存。

3、 串行变为并行,减少串行耗时。

4、 对单步骤中的耗时逻辑梳理优化。

根据这些方向,我们做的工作:

1、 预加载进程。

2、 视频 SDK 上下文全局单例,并且预先初始化。

3、 并行预拉取接口机 IP,房间信息,预进入 avsdk 房间。

4、 接口机缓存首帧数据,减少 GOP 分片时间,修改播放器逻辑,解析到I帧就开始播放。

1)新方案的整体流程图:

该方案在加速的基础上,还有其他的优点:

1、对现有的代码改动最小,保证版本的稳定性,除了新增的预拉取逻辑,在原有流程上只需要将之前的异步逻辑改为拉取缓存的逻辑。

2、原有逻辑成为备份逻辑,流程茁壮型得到增强,预拉取失败还有原有逻辑作为备份“重试”,进房间成功率提高。

2)预拉取流程,详细介绍

从“预拉取接口机 IP”这个点来详细介绍如何做预拉取,缓存管理和时序处理:

1、 由于直播进程和主进程是内存隔离。Feeds 滚动停止(开始预拉取)是在主进程触发。拉取的 wns 请求需要在直播进程。通过 AIDL 跨进程去调用。

2、 接口机 IP 的请求为异步,需要缓存请求的状态。请求缓存接口机 IP 数据时,预拉取的状态为成功,直接使用缓存数据。

预拉取的状态为请求中,等待本次预拉取的结果。

预拉取的状态为失败,走之前流程,重新请求接口机 IP。

3、 接口机 IP 需要有时效性的,每次滑动停止都预加载 IP,会造成了请求浪费;并且腾讯云的接口机 IP 有就近接入的特性。为保证负载稳定,如果一直使用缓存的接口机 IP 可能会导致某台机器负载过多。需要加入时效性的控制。

3)秒开关键

细心的同学肯定发现还有一个最大的耗时点没有解决——拉取首帧数据过慢。这个步骤耗时降低才是秒开的关键。

首帧数据的展示过程,其实是一个下载,解码,渲染的过程。

这里简单插述一下视频编解码过程中的一种约定:GOP( Group of Pictures )

为了便于视频内容的存储和传输,通常需要减少视频内容的体积,也就是需要将原始的内容元素(图像和音频)经过压缩,压缩算法也简称编码格式。例如视频里边的原始图像数据会采用 H.264 编码格式进行压缩,音频采样数据会采用 AAC 编码格式进行压缩。 视频内容经过编码压缩后,确实有利于存储和传输; 不过当要观看播放时,相应地也需要解码过程。因此编码和解码之间,显然需要约定一种编码器和解码器都可以理解的约定。就视频图像编码和解码而言,这种约定很简单: 编码器将多张图像进行编码后生产成一段一段的 GOP ( Group of Pictures ) , 解码器在播放时则是读取一段一段的 GOP 进行解码后读取画面再渲染显示。 GOP ( Group of Pictures ) 是一组连续的画面,由一张 I 帧和数张 B / P 帧组成,是视频图像编码器和解码器存取的基本单位,它的排列顺序将会一直重复到影像结束。

在互动直播 SDK 中,将帧类型扩展到五种:

  • I 帧不需要参考帧。
  • P 帧只参考上一帧。
  • P_WITHSP 帧可参考上一帧、I 帧、GF 帧、SP 帧,自己不可以被参考。
  • SP 帧可参考 I 帧、GF 帧、SP 帧。
  • GF 帧可参考 I 帧、GF 帧 。

1) 标准的 H264 编码的参照关系,每一个 GOP 的第一针是 I 帧,P 帧依次参考上一帧,抗丢包性不强,如果中间有 I 帧或 P 帧丢失,则该 GOP 内后续 P 帧就会解码失败。

(1.标准 GOP 组织图)

2) 在实时直播的场景,为保证流畅性,重写编码器逻辑,首个 GOP 包开头为I帧,后面 GOP 包开头为 GF 帧,这是利用 GF 帧的传递参考关系是跨 GOP,每个 GF 帧参考上一个 GOP 的 I 帧或 GF 帧。GF 帧体积对比 I 帧要小,后续 GOP 的下载解码更快速。

(2.SDK 的 GOP 组织图)

3) 对 GOP 内部的帧组织,也使用 P_WITHSP 帧来代替 P 帧,主要是因为 P_WITHSP 帧(粉红色表示)的解析可参考上一帧、I 帧、GF 帧、SP 帧,自己不可以被参考。就算上一帧 P_WITHSP 未解码出来,后一帧 P_WITHSP 的解码也不受影响,增强了抗丢包性

(3.SDK 的 GOP 帧内部参考关系)

那具体到业务上,通过 wireshark 抓包我们发现。过程主要耗时在首个 GOP 包下行比较慢,需要等待 I 帧(FT 是 0 代表 I 帧)下载完毕才开始解码,如果 I 帧不完整无法解码,则需要等待第二个 GOP 包,等待时间加长。

那通过这个现象,为了让整个过程加快,和 SDK 的同事在1.8.1版本一起做了以下工作:

1、 减小首个 GOP 包的分片大小:将 GOP 的分片由 5s 改为 3s,并且首个 GOP 包只缓存必要的 I 帧,减少首个 GOP 包的体积;(PS:GOP 包的长度和主播端编码性能也是强相关,GOP 分片太小,编码性能不高,分片时长的确定需要综合考虑)

2、 首个 GOP 包需要走网络下载,同样网络条件下这部分路径越短下载越快。GOP 包之前是存在流控服务器上,GOP 包要到达客户端连接的接口机,还需要链接传输的耗时。新的版本直接在接口机上缓存当前直播中房间的 GOP 数据,保证在客户端连上接口机之后,就可以直接从本机缓存中推流首帧数据,省掉之前的链接传输耗时。

3、 大部分播放器都是拿到一个完整的 GOP 后才能解码播放, 改写播放器逻辑让播放器拿到第一个关键帧(I帧)后就给予显示。不需要等待全部的 GOP 下载完毕才开始解码。

以上三点做好了之后,效果明显,整个的拉取首帧的时间由之前的 2140ms 降到平均 300ms,当然完成这些工作并不是上面叙述的三点那么简单,中间过程我们也发现一些棘手问题,并推动解决:

如主播上行网络丢包导致的 GOP 乱序、多台接口机之间缓存的管理、GOP 分片时长的确定。

4)持续优化

我们一直没有放弃“更快更爽”的体验追求,在后续的迭代中也持续优化直播的体验:

1、接口机 IP 竞速。

2、合并请求。

3、多码率。

五、遇到的问题

我们的优化手段是将串行的异步请求改为并行;但是将串行改为并行后,几个异步请求同时开始,如何保证各个异步回调的时序运行正常,这是一定要解决的问题,也是大家在做优化过程中比较有代表性的问题。

处理这种异步回调时序问题类似于 Promise 模式。我这里在具体业务上使用 LiveVideoPreLoadManager 来统一处理,类图如下:

  • LiveVideoPreLoadManager:负责对外暴露启动预加载方法和拉取结果数据对象的方法。其主要方法及职责如下。Compute:注册监听器,获取结果的数据对象,使用监听器实例来响应对数据对象的处理。preLoad:启动异步任务的执行。
  • CacheManager:缓存异步任务处理结果和状态,检查是否过期。负责检测异步任务是否处理完毕、返回和存储异步任务处理结果。其主要方法及职责如下。getResult:获取缓存异步任务的执行结果。setResult:设置缓存异步任务的执行结果及当前的执行状态:开始,过程中,结束。isDone:检测异步任务是否执行完毕。
  • Result:负责表示异步任务处理结果。具体类型由相应的业务决定。
  • Task:负责真正执行异步任务。其主要方法及职责如下run:执行异步任务所代表的过程。

获取异步任务处理结果的序列图如下。

采用这种模式,当异步任务同时开始,如拉取房间信息,接口机 IP,房间信息,它们都被封装在 LiveVideoPreLoadManager 的 Task 请求实例中,而主流程则无须关心这些细节,只需要将之前的请求方式变为 LiveVideoPreLoadManage.compute,并注册对应的异步回调接口。Compute 内部会通过 CacheManager 的 getResult 方法检查异步任务处理结果状态,如果异步任务已经执行完毕,则该调用会直接返回,类似与同步操作(步骤5,6,7),那么 LiveVideoPreLoadManager 对外暴露的 compute 方法是个同步方法;若异步任务还未执行完毕,则会阻塞一直等待异步任务执行完毕,再调用 compute 注册的回调来响应结果,此时 compute 方法是个异步方法(步骤5,4)。也就是说,无论compute方法是一个同步方法还是异步方法,对客户端的编写方式都是一样的。

采用这种 Promise 模式,即对原有流程改动最小,也增强了原有流程的茁壮型,在预拉取失败的时候,那么原有流程的串行逻辑作为兜底保护。从统计数据也可以看到,在优化版本之后,版本的观看端进入房间成功率也有提升。

六、总结

整个的秒开优化版本时间非常紧张,中间肯定还有别的优化空间,统计数据上来看,整体用户的进入时间还是在 2.5s+,新的迭代版本还在持续优化,大家如果对秒进有什么好的想法和建议,欢迎交流。也欢迎大家下载新版 QQ 空间独立版体验 Qzone 的直播功能,分享生活,留住感动!

2 1 收藏 评论

关于作者:腾讯bugly

Bugly是腾讯内部产品质量监控平台的外发版本,支持iOS和Android两大主流平台,其主要功能是App发布以后,对用户侧发生的crash以及卡顿现象进行监控并上报,让开发同学可以第一时间了解到app的质量情况,及时修改。目前腾讯内部所有的产品,均在使用其进行线上产品的崩溃监控。腾讯内部团队4年打... 个人主页 · 我的文章 · 3 ·  

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部