视频缓存加速，2.5倍优化

1、背景

---

视频缓存已经成为各大视频App的标配，并且从功能使用数据来看，每个月使用的量都很大。所以，做好缓存功能的优化，对提升用户体验有非常重要的作用。

搜狐视频iOS端的缓存和爱奇艺的有区别，并没有多个视频同时缓存的产品功能，而且缓存分片是串行下载的。即m3u8文件缓存下来后，顺序下载ts地址对应的文件，导致网络利用率不高。

为了提升用户体验，提升缓存速度，我对缓存进行了速度优化，提升了网络利用率。具体方案如下。

2、方案设计

---

2.1、分析

缓存方案的核心在于，最大程度的提升网络利用率。但并非单纯的扩大并发缓存数量，这样会导致设备发烫、网络资源抢夺等很多问题。应该根据网速和设备性能等因素，动态决定分片数量。所以，设计一套合理的测速方案，以及缓存方案就非常重要。

由于我们的网络使用的quic协议，所以在网络层面已经没有太大的提升空间，只能通过上层进行优化。

2.2、缓存方案

如果是新建的缓存任务，没有测速数据或数据已过时。数据已过时指的是两次缓存不是连续的，例如暂停后再继续缓存，或重启后缓存。则根据网络环境做判断，来决定并行下载数量。流量环境并行数量为2，WiFi并行数量为4。这个值是测试的一个经验值。

并发数量并不是固定的，从第一次下载开始，每次缓存的过程都会进行测速，并根据测速结果动态修改并发数量，并且持续利用缓存的速度数据进行测速，来修改并发数量。当网络环境发生改变后，这时候需要重新进行测速，从第一步重新开始。

在网络的部分，底层quic使用的cronet库作为实现。cronet没有长连接的概念，是通过cronet线程处理的并发，同一端口最多6条线程，最多不超过16条线程。所以，需要上层逻辑控制并发数，并不能直接设置并发数。

由于项目中大多数的视频都是m3u8格式，缓存加速只对m3u8的视频缓存做了加速，drm和mp4格式的视频并没做处理。而且，drm和mp4目前是流式下载，如果想加速需要后端对视频文件做切片。

2.3、测速方案

测速需要考虑下面几个核心因素。

（1）网络环境，WiFi和流量的平均网速相差比较大，WiFi下可以更充分的利用网络资源。

（2）网速，最核心的因素，网速慢的话，什么方案都没用。