优酷安卓短视频秒播优化

一、背景介绍，短视频关注秒播

近几年，短视频一直处于流量的风口，各大平台纷纷涉足。不同的业务形态对技术有不同的述求，传统长视频关注的是减少播放中的卡顿，降低用户 seek 的耗时；直播关注的是如何保证实时性；而短视频关注的是秒播。

为什么短视频关注的是秒播？一是因为短视频通常只有十几秒，一是短视频的消费带有很大的探索性和随机性。如果用户花几秒钟等待十几秒的视频，很有可能起播后还不是用户喜欢看的，这个代价对用户来说太大了，久而久之，就是用户流失的时候。

二、现状与目标

短视频播放相关的核心技术指标有两个：缓存命中率和秒播率。通常情况，缓存命中率越高，响应的秒播率也就越高。短视频秒播专项优化项目启动时，关于缓存命中率和秒播率，结合现状，目标为缓存命中率提升 40%，200 毫秒秒播率提升 150%，400 毫秒秒播率提升 25%。

三、困难和挑战

首先，我们是短视频分发消费场，属于上层业务，底层播放器链路和预加载模块对我们都是黑盒的，无法直接在底层从根本去优化；

其次，短视频分发消费场，用户诉求是随机的，当用户滑到不感兴趣的视频时，会立即滑走，以便快速探索下一个视频。这会造成用户停留时间很短（通常不到 1 秒），大大挤压了预加载下一个视频的时间，造成滑出来的视频大概率在线起播，如果恰逢网络不稳定，很容易造成起播慢；

再次，优酷的长视频和短视频共用一个播放器。长视频场景下，更关注的是起播之后的流畅度。故播放器为了保证起播之后的流畅度，有如下播放优先策略。

1）播放前，由于不确定本地缓存的视频流是否足够起播，所以开始播放时，为了防止预加载任务抢网络带宽，此时会暂停所有的预加载任务，以优先保证起播。起播之后，在当前播放视频缓存的视频流达到配置的水位，才恢复被暂停调的预加载任务；

2）配置的时间阈值（300 毫秒）内无法起播，则会等待缓存的视频流加载到指定水位（指定时长或者指定大小），才会开始起播。

播放器以上两点播放优先策略，放到在短视频场，就不适用了，甚至是矛盾的，这无形中大大增加了短视频秒播优化的难度。

四、行业做法

在开始优化之前，很有必要花些时间对行业做法深入调查一番。主要集中在两个方面，一个是货，即视频源；一个是预加载策略。

如下表所示，从数据上可以看出，优酷和快手两家的货大同小异，而抖音在视频编码上支持 H.265。

平台 时长 (s) 分辨率 码率 (mbps) 大小 (mb) 优酷 18 720p 2.45 5.6 抖音 15 540p 1.11 1.8 快手 20 720p 2.07 5.0

五、优化策略

视频起播耗时，主要有两个方面，一个是播放器准备耗时，一个是从网络加载视频流耗时。所以优化原则简单粗暴，就是在播放前，想尽一切办法，准备好播放器和将视频流加载到本地。

1. 下拉刷新优化

feed 视频列表请求成功后，扣留列表中最后一个视频到内存中，然后预加载其视频流；下拉刷新时，将上次扣留到内存中的视频放在下拉刷新列表的第一个位置，同时扣留下拉刷新列表的最后一个视频，如此往复，保证下拉刷新播放的视频是本地起播。

feed 场景下，向下滑动出来的视频都是算法推荐，没有传统列表的分页概念。所以 feed 场景下，用户通常是一直向下滑动以获取新的推荐内容，用户没有下拉刷新的心智，故此优化项在此业务场景下收益甚微。

1. 按需预加载视频流

现有预加载模块，如果业务方不设置预加载 buffer 大小，则统一为 400k，通过线上开关控制。优化后，业务方动态计算预加载 buffer 大小，计算原则就是预加载 3 秒的视频流。如果在视频播放时，3 秒视频流全部加载到本地，则既能保证起播，又能保证起播后的顺畅。

此项优化，收效同样甚微，按需预加载，只在一定程度上避免造成预加载任务阻塞，并没有从根本上提高预加载效率。

1. 闲时任务

在视频播放超过 5 秒或者重复播放时，认为当前播放的视频流已全部加载完成，此时网络是空闲的，利用此网络空闲的时间，串行预加载后面的视频。

小视频业务大盘数据统计用户平均每个视频的消费时长为 6 秒，加上 1/3 的播放为重复播放，所以此优化项对于缓存命中率有较大提升。

1. 预加载时机提前

利用滑动切换视频时，在滑动松手到滑动停止这段时间（300 毫秒），在保证滑动帧率的前提下，开启子线程预加载后面的视频，利用这 300 毫秒，预加载后面的视频流，保证本地起播。相比原先预加载时机是在滑动停止，当前视频起播后才预加载后面的视频，假设视频起播时间为 500 毫秒，则相比优化前，预加载时机提前了至少 800 毫秒，这是非常可观的提升。最后测试下来，也是此优化项对于缓存命中率的提升是最为明显的。

至此，关于缓存命中率的优化已经收尾，上线后大盘数据也验证了优化的效果，缓存命中率提升了 38%。

1. 双播放器

上述的四项优化，都是业务层在有限的时间和空间里抠细节，在预加载策略上做文章，经过一系列优化手段，缓存命中率达成目标。

虽然缓存命中率完成目标了，但是核心的技术指标秒播率并没有完成，距离目标还有一定差距。这时候我们只能硬着头皮，想平时不敢想，做平时不敢做的，开始实施双播放器方案，空间换时间。双播放器方案原理比较简单，就是在当前视频起播之后，预准备下一个视频的播放器，两个播放器循环使用。

下一个视频的播放器一旦准备好，加上视频流已加载到本地，则起播非常快，几乎是视频直出的效果。但由于播放器准备更耗时，用户滑到下一个视频时，并不能百分百保证此视频的播放器已准备好。双播放器方案上线后，效果显著，200 毫秒秒播率提升 178%，400200 毫秒秒播率提升 29%。

至此，缓存命中率和秒播率圆满完成任务。

注解

1）秒播：1 秒内完成播放，后来常用于泛指起播速度；

2）秒播率：指定时间内起播的次数占全部播放次数的比例，比如 200 毫秒秒播率指的就是 200 毫秒内起播的次数占全部播放次数的比例；

3）缓存命中率：开始播放时，本地有播放视频的视频流，哪怕本地缓存的视频流只有一个字节，也认为是缓存命中，缓存命中率指的就是缓存命中的播放次数占全部播放次数的比例；

4）编码格式：又称视频编码规范，视频压缩格式。通常原始视频非常大，不方便存储和传输，所以需要将原始视频进行压缩。视频编码格式很多，这里不累述，优酷场主要的视频编码格式有 H.264 和 H.265，H.264 和 H.265 的详细区别这里也不累述，总的来说就是，H.265 的压缩效率更高，传输码率更低，视频画质也更清晰。

作者 | 阿里文娱高级开发工程师 乐想