导读：随着互联网的发展，越来越多人喜欢直播，百度直播也在快速发展中，为了提升用户的使用体验，本文针对百度直播的复杂流程进行了整体梳理，并详细说明开展的一系列起播优化工作。

全文4216字，预计阅读时间 9分钟。

一、背景

百度做直播有两个目标：

1、把现实世界照搬到线上，在线上和在线下有一样的体验，直播种类有媒体、咨询、电商、秀场等；

2、是对美好想象的一个完美塑造，随着5G、VR、AI到来，带给我们想象的空间，把线下没有的东西超越这个时空，放到线上，超越线下的想象空间。

做直播首先要做的就是QOE（Quality of Experience），我们作为技术同学在保证业务目标的同时，也要提升用户的体验。

直播的体验有很多：首屏时间、延迟、画面质量、音画同步、清晰度、杂音、回声等。

从QOE角度出发，作为衡量的标准QOS（Quality of Service）也有很多：推流成功率、推流卡顿流、转推慢速比、端到端延迟、CDN流畅率、启播耗时、拉流卡顿率、视频码率、转推慢速比、内存消耗、CPU&GPU消耗等等。这些技术指标统一构成一个整体，作为衡量直播服务质量的标准。

但是从直播用户的角度出发，当用户点开直播后，用户希望能够马上看到画面，也就是直播启播速度要快；当在沉浸式直播间上下滑动时，用户也会希望当前屏幕要看到的直播迅速启播。启播耗时作为用户的首个直播感知，被放到了首要优化的目标。

二、现状

百度直播分中泛服务直播&泛娱乐直播，其中泛服务直播提供了媒体直播、咨询直播、电商直播等服务，泛娱乐直播提供了秀场、音播、语音房等娱乐直播。

其中泛服务直播更为复杂一些，关于启播流程有以下几个特点：

1、流程繁琐：分为外部跳转直播间&沉浸式直播间内跳转两套流程，其中流程流转环节也较多；

2、直播状态较多：包含了直播中，回放、回放生成中等状态

3、涉及面广：涉及百度App多个团队：直播、播放器、内核、网络、CDN等

4、行驶汽车换轮子：百度极度重视直播，业务高速迭代，需要给行驶的汽车换轮子。

总结完了泛服务启播的特点，那么就要定量的去分析整个启播的流程，用数据来衡量整个启播的环节。

三、数据分析

对整个启播流程进行数据分析，大致将启播流程分为三个大阶段：**直播业务耗时、播放器耗时、内核耗时。**下图是大致的划分：

在实际数据统计中，会对各个环节进行更精细的统计，简单说一下直播业务的数据统计和内核的数据统计：

直播业务的每个环节的进行数据量化，精确到每个步骤耗时，这样在数据的基础上进行分析。

以内核为例：

然后就可以得到一份详尽关于内核的数据的图表。

从用户点击跳转到直播间或者沉浸式直播间内滑动切换直播间，到最终的直播播放成功，预计会有60多个的点位进行一些列的追踪分析。详细的数据表格呈现启播过程中每一步骤的耗时，然后针对于耗时多的地方进行优化。

首先在报表里面占比最大的是业务场景的耗时，约占到60%以上，那么首先解决的就是这块耗时；
第二块耗时占比较大的阶段是拉流的耗时；
当比较大的耗时解决后，就需要针对于小的耗时进行针对性的优化。

业务场景的优化

百度App的媒体直播和全民的秀场直播融合之后，会在直播间内进行混合分发。从直播跳转角度来看，直播间的跳转分为两种：一种是外部通过scheme跳转到直播间，一种是沉浸式直播间内的滑动跳转；

下面是外部通过scheme跳转到直播间的简单流程：

通过scheme跳转直播间有两种情况：

1、无roomID的的情况，首先需要请求list接口，然后根据list中的roomId来继续请求当前直播间的相关信息，根据相关的信息进行组件&插件的的安装以及渲染操作，当页面渲染完成后，开始创建播放器，setURL，并初始化内核，开始播放直到播放成功回调；

2、有roomID的情况，那么会直接请求当前直播间的相关信息，然后执行与步骤1相同的操作。

下面是沉浸式直播间内的滑动跳转：

相对于外部跳转，沉浸式直播间内跳转多了用户的滑动操作，从滑停开始统计启播，直到播放成功回调，整个启播时长预计在1700ms左右，而在整个流程中，整个直播的业务耗时约为1000ms左右。
外部跳转：内部跳转 = 1: N；N要远远大于1，这样看的话，优先优化直播间内跳转。

定性定量分析后，制定针对的优化方案：

基于页面卡顿的考虑，整体方案A&B两种：

A方案是在iphone8及以上的机型上面实施：在用户滑动开始时开始创建播放器，并且直接调用播放。

方案B是在iphone8以下的机型上面实施：在用户滑动时开始创建播放器并且准备好资源，在用户滑停之后销毁上个直播间，并且开始下个直播间的播放。

A&B方案的实施，使得卡顿率在这iphone8上下的机型都能够表现的不错，并不会给用户卡顿带来劣化的体验，针对于机型也是经过ABTest不断测试启播与卡顿之间的平衡，寻求的一个暂时的平衡点。后面也会针对于卡顿来做不断的优化来避免对象频繁的创建与销毁，来减少CPU的不断计算，以使方案A所适应的机型不断扩增。

有了直播间内部跳转的优化方案之后，那么外部scheme的跳转也就显而易见了：

百度App的组件间通信方案使用的scheme来通信，那么在scheme里面添加直播的URL，在跳转进直播页面时直接通过scheme携带的URL来创建播放器，并开始播放直播，与业务逻辑并行执行。

四、DNS预解析

DNS（Domain Name System），它的作用是根据域名查出IP地址，它是HTTP协议的前提，只有将域名正确的解析成IP地址后，后面的流程才能进行。在内核处理直播流的时候，直播DNS耗时八十分位大约在60ms，这块的耗时也是比较多的。

在百度AppAPP中，防止DNS的劫持，同时也是为了降低网络时延，我们采用了HTTPDNS的方案：

为了优化直播DNS解析耗时，采用DNS预解析策略，提前缓存对应的IP，可以减少DNS解析的耗时时间。

在应用冷启10s、网络切换、前后台切换等时机，根据模型判断是否采取直播DNS预解析方案，模型的判断标准为：用户N天内浏览直播时长M、当前网络状态、后端控制等等。当模型判定通过时，会调用HTTPDNS异步发起直播域名的解析获得一个IP列表，对IP分别进行测速，测速后并不是直接选用结果最优的那一个，而是在测试结果可以接受的一定范围内进行随机挑选并缓存预解析的结果。避免了大量用户都聚集到少数节点，导致的节点负载不均衡。

HTTPDNS缓存IP的有效时间是从服务端获取的，默认300s。当直播流域名解析开始时，查询缓存，若存在有效IP(缓存时间<300s)直接返回对应IP，并调用HTTPDNS异步发起请求更新。若不存在也会异步发起请求更新，此时会降级到LocalDNS解析。

当网络变化时(Wifi <-> 4G)，清除当前的缓存IP，并重新发起域名列表内所有域名的预解析。

最终收益：使用HTTPDNS预解析后，直播DNS耗时小于3ms的PV占总直播PV的90%以上。

五、内核的一些优化

针对于报表里面耗时较多的阶段，进行了一系列针对的优化：

1、首屏强制渲染：主要就是视频的首帧解码出来就会强制走渲染流程，不会去做音画同步；

2、弱网情况下，启动低码率启播策略；

3、高端机型下加载下个播放器内核，并prepare，当切换直播时进行追帧操作。大概逻辑就是缓冲区延时超过3秒就每隔2秒就丢200ms音频，直到低于3秒内不丢，如果超过16秒，就会全部丢掉直接重连。

六、直播起播优化

直播起播优化-媒体信息解析模块的优化

视频宽高、图像编码格式等信息是Android平台硬件解码器Mediacodec，IOS平台硬件解码器Video ToolBox必备信息，播放内核在配置平台硬件解码器之前，需要准备好视频宽高、图像编码格式等信息。

一些封装格式(例如MP4)会在头部描述视频宽高、图像编码格式等信息，针对视频容器不包含上述信息的情况(例如FLV)，FFMPEG原生流程就循环的下载视频流，然后通过软件解码器解码视频，获取上述信息；

在H.264/AVC视频编码标准中，整个系统框架被分为了两个层面：视频编码层面（VCL）和网络抽象层面（NAL）。其中，前者负责有效表示视频数据的内容，而后者则负责格式化数据并提供头信息，以保证数据适合各种信道和存储介质上的传输。NAL中的SPS，PPS中已经宽高信息，图像编码格式的描述，可以通过解析SPS，PPS获取必要信息，省去软解视频的流程。

七、直播回放(HLS)m3u8预取

直播视频通常会被编码成HLS格式保存，我们称此为直播回放，HLS封装格式的视频起播80分位为1250ms，起播速度是反应播放体验的核心指标，直播回放起播性能显著差于直播(HTTP-FLV)的510ms。

HLS封装起播慢的主要原因是因为需要先下载视频索引文件(M3U8)，通过解析该索引文件才得到真正的视频文件，也就是说相比直播（HTTP-FLV）至少多了一次HTTP的请求。为了解决这个问题，通过提前预取HLS视频索引文件（M3U8）到本地sdcard；起播时省去了M3U8下载部分耗时，AB实验收益：对比命中和未命中预取M3U8实验组，命中预取收益为346ms。