如何像百度直播一样优化用户体验（起播篇）

百度Geek说

关注

发布于: 21 小时前

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

全文 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。