【腾讯bugly干货】QQ空间直播秒开优化实践
本文来自于腾讯bugly开发者社区，非经作者同意，请勿转载，原文地址为：http://bugly.qq.com/bbs/forum.php?mod=viewthread&tid=1204&extra=page%3D1
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 右侧映客 小米5 WIFI）
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，房间信息，预进入互动直播 sdk 房间。
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 的直播功能，分享生活，留住感动！ - 更多精彩内容欢迎关注bugly的微信公众号：
-
腾讯 Bugly是一款专为移动开发者打造的质量监控工具，帮助开发者快速，便捷的定位线上应用崩溃的情况以及解决方案。智能合并功能帮助开发同学把每天上报的数千条 Crash 根据根因合并分类，每日日报会列出影响用户数最多的崩溃，精准定位功能帮助开发同学定位到出问题的代码行，实时上报可以在发布后快速的了解应用的质量情况，适配最新的 iOS, Android 官方操作系统，鹅厂的工程师都在使用，快来加入我们吧！
