本文的主要内容 

• 理解 AVAssetResourceLoaderDelegate 的使用 

• 缓存下载的实现 

• VIMediaCache 提供了哪些 API

接下来会介绍通过使用 AVAssetResourceLoader，在不改变 AVPlayer API 的情况下，对播放的音视频进行缓存。

前戏

现在市场上各种各样的应用，充满了多媒体信息，而声音和视频又是体积最大的文件，如果直接使用 URL 通过 AVPlayer 播放，系统并不会做缓存处理，等下次再播又要重新下载，对网络状况差的用户来说这就是灾难。若是下载好再播，同样要等待全部下载完成，也是很痛苦。

我们最理想的缓存方案是：边播放，边缓存。

我在早期加入美拍团队的时候，实际上已经有了边下边播的功能，当时选择了使用 HTTPServer，在本地开启一个 http 服务器，把需要缓存的请求地址指向本地服务器，并带上真正的 url 地址。

早期的美拍都是不到 20s 的短视频，后面加长了视频时间，但考虑到用户设备容量问题，我们只对短视频做视频缓存。一直发展到现在，平台上现在大多数的视频都是长视频，真正使用到缓存功能的频率已经很低。那么问题就来了，HTTPServer 不管我们有没有使用缓存功能，都要在应用打开的时候默默开启，这真的是很浪费了。并且我们引入 HTTPServer 库也会增加一些包体积。

理解 AVAssetResourceLoaderDelegate 的使用

那么在一段寻觅之下，发现了最适合做边下边播缓存的工具。AVAssetResourceLoaderDelegate：一个 iOS 6 就被开放出来，专门用来处理 AVAsset 加载的工具。

AVURLAsset *urlAsset = ...
[urlAsset.resourceLoader setDelegate:<AVAssetResourceLoaderDelegate> queue:dispatch_get_main_queue()];

只要找一个对象实现了 AVAssetResourceLoaderDelegate 这个协议的方法，丢给 asset，再把 asset 丢给 AVPlayer，AVPlayer 在执行播放的时候就会去问这个 delegate：喂，你能不能播放这个 url 啊？然后会触发下面这个方法：

- (BOOL)resourceLoader:(AVAssetResourceLoader *)resourceLoader shouldWaitForLoadingOfRequestedResource:(AVAssetResourceLoadingRequest *)loadingRequest 

我们在这个方法中看看 request 里面的 url 是不是我们支持的，如果能支持就返回 YES！然后就可以开心的一边下视频数据，一边塞数据给 AVPlayer 让它显示视频画面。

先不管下载和缓存，实现上，可以分为两步：1. 需要知道如何请求数据，url 是什么，下载多少数据。2. 下载好的数据怎么塞给 AVPlayer

1. 如何请求数据

在上面的回调方法中，会得到一个 AVAssetResourceLoadingRequest 对象，它里面的属性和方法不多，为了减少干扰，我精简了一下这个类的头文件，只留下我们会用到以及需要解释的属性和方法：

@interface AVAssetResourceLoadingRequest : NSObject 
 
 @property (nonatomic, readonly) NSURLRequest *request;
 
 @property (nonatomic, readonly, nullable) AVAssetResourceLoadingContentInformationRequest *contentInformationRequest NS_AVAILABLE(10_9, 7_0);
 
 @property (nonatomic, readonly, nullable) AVAssetResourceLoadingDataRequest *dataRequest NS_AVAILABLE(10_9, 7_0);
 
 - (void)finishLoading NS_AVAILABLE(10_9, 7_0);
 
 - (void)finishLoadingWithError:(nullable NSError *)error;
 
 @end 

在 AVAssetResourceLoadingRequest 里面，request 代表原始的请求，由于 AVPlayer 是会触发分片下载的策略，还需要从dataRequest 中得到请求范围的信息。有了请求地址和请求范围，我们就可以重新创建一个设置了请求 Range 头的 NSURLRequest 对象，让下载器去下载这个文件的 Range 范围内的数据。

2. 塞数据给 AVPlayer

当 AVPlayer 触发下载时，总是会先发起一个 Range 为 0-2 的数据请求，这个请求的作用其实是用来确认视频数据的信息，如文件类型、文件数据长度。当下载器发起这个请求，收到服务端返回的 response 后，我们要把视频的信息填充到  AVAssetResourceLoadingRequest 的 contentInformationRequest 属性中，告知下载的视频格式以及视频长度。

AVAssetResourceLoadingRequest 在 - (void)finishLoading 的时候，会根据 contentInformationRequest 中的信息，去判断接下去要怎么处理。例如：下载 AVURLAsset 中 URL 指向的文件，获取到的文件的 contentType 是系统不支持的类型，这个 AVURLAsset 将无法正常播放。

获取完视频信息后，会收到刚才指定的 2 Byte 的 data 数据，下载到的数据怎么办？ 可以塞给 AVAssetResourceLoadingRequest 里的 dataRequest 。 dataRequest 里面用 - (void)respondWithData:(NSData *)data; 专门用来接收下载的数据，这个方法可以调用多次，接收增量连续的 data 数据。

当 AVAssetResourceLoadingRequest 要求的所有数据都下载完毕，调用 - (void)finishLoading 完成下载，AVAssetResourceLoader 会继续发起之后的数据片段的请求。如果本次请求失败，可以直接调用 - (void)finishLoadingWithError:(nullable NSError *)error; 结束下载。

流程图

完整实现的主流程是这样的

重试机制

在实际的测试中，发现AVAssetResourceLoader 在执行加载的时候，会时不时的触发取消下载调用 - (void)resourceLoader:(AVAssetResourceLoader *)resourceLoader didCancelLoadingRequest:(AVAssetResourceLoadingRequest *)loadingRequest，然后重新发起加载请求的策略。如果下载了部分，那么重新发起的下载请求会从还没有下载的部分开始。

AVAssetResourceLoaderDelegate 中还有 3 个方法可以针对特殊场景做处理，不过在目前的环境中都用不到所以可以选择不实现这些方法。

缓存下载的实现

我们已经知道 AVAssetResourceLoaderDelegate 的实现机制，当 AVAsset 需要加载数据时会通过 delegate 告诉外部，外部接管整个视频下载过程。

接管了视频下载，便可以对视频数据做任何事情。比如：缓存、记录下载速度、获得下载进度等等。

实现一个下载器，就是用 URLSession 开启一个 DataTask 请求数据，把接收到的数据塞给 DataRequest 并写入本地磁盘。在实现下载器时主要有三个注意的点：1. Range 请求  2. 可取消下载  3. 分片缓存

1. Range 请求

每次得到的 LoadingRequest 带有请求数据范围的信息，比如期望请求第 100 字节到 500 字节，在创建 URLRequest 时需要设置 HTTPHeader 的 Range 值。

NSString *range = [NSString stringWithFormat:@"bytes=%lld-%lld", fromOffset, endOffset];
[request setValue:range forHTTPHeaderField:@"Range"];

2. 可取消下载

AVAsset 在加载视频时，经常会在某次数据请求还没有完成时触发取消下载，然后发起一个新的 LoadingReqeust。这个机制是 AVAsset 里的黑盒，具体逻辑无法得知，比较像是 AVAsset 的一种重试机制。 作为下载器，在收到取消通知时，需要立刻停止下载。由于 DataRequest 的 cancel 操作是异步的，就有可能在 cancel 还未完成时，下一个 LoadingRequest 就已经到来，所以还需要需要保证同一个 URL 只能同时存在一个下载器在下载，否则会出现数据混乱的问题。

3. 分片缓存

如果只是单纯的下载视频，数据单调递增，缓存处理还是比较容易。然而现实是用户对 player 的 seek 操作给视频的缓存管理带来了巨大的挑战，一旦涉及到用户操作，可能性就越多，复杂度也会越高。

没有 seek 的情况：网速正常时缓存数据比播放时间走得开，正常播放；网速慢时，播放器 loading，直到有足够的数据量进行播放，如果网速一直很慢就会播几秒卡一下。

当加入 seek 后会有三种可能：

• 视频完全下载好，这时 seek 只需读取相应缓存

• 视频下载一半，用户 seek 到未下载部分，LoadingRequest 请求的部分全部都是未下载的数据。这时需要取消正在下载的数据，然后从 seek 的点开始下载数据。为了支持 seek 操作，下载器就需要支持分片缓存。目前使用的解决方案是下载的视频数据会根据请求的 Range 值，把数据存储到文件中对应的偏移值位置，并且每个视频文件都会另外再保存一个与之对应的下载信息文件。这个信息文件会记录当前下载了多少数据，总共有多少数据，下载了哪些片段的数据等信息，之后的缓存管理会非常依赖这个配置文件。

• 视频被 seek 了多次，用户 seek 到一个时间点，LoadingRequest 请求的部分包含了已下载和未下载的部分。

这种情况是最复杂的！简单的做法是，当成上面的情况来处理，全部都重新下载，虽然逻辑简单，但这个方案会下载多次同样的数据，不是最最优解。 

我的目标当然是做最优的解决方案，但也是复杂高很多的解决方案。

在收到 LoadingRequest 的请求范围后，下载器会先获取已经下载的数据信息，把已下载的分片信息分别创建一个 action，再把需要远程下载的分片数据分别创建一个 action。最终组合就可能是 LocalAction(50-100 bytes) + RemoteAction(101-200 bytes) + LocalAction(201-300 bytes) + RemoteAction(300-400 bytes)。每一个 action 会按顺序获取数据再返回给 LoadingRequest。

VIMediaCache 提供了哪些 API

基本使用

VIMediaCache 主要提供了 VIResourceLoaderManager，这个类实现了 AVAssetResourceLoaderDelegate，并且提供了初始化一个 AVPlayerItem 的方法，平时使用时，只需用 VIResourceLoaderManager 创建一个 AVPlayerItem ，AVPlayer 再用这个 playerItem 初始化，AVPlayer 在播放的时候就会自动缓存了。

VIResourceLoaderManager *resourceLoaderManager = [VIResourceLoaderManager new];
self.resourceLoaderManager = resourceLoaderManager;
AVPlayerItem *playerItem = [resourceLoaderManager playerItemWithURL:url];
AVPlayer *player = [AVPlayer playerWithPlayerItem:playerItem];

缓存管理

所有缓存相关的信息都在 VICacheManager 类中。目前提供了下载进度通知、修改缓存目录、根据 url 获取缓存地址、根据 url 获取缓存信息、计算缓存大小、清除缓存等功能。详情可看头文件

错误回调 

在下载视频时，出现错误无法正常下载是比较容易出现的。我们自己实现了 AVAssetResourceLoaderDelegate 在第一次请求就抛出错误的话，播放器会马上提示错误状态，而如果是已经响应了部分数据，再抛错误，AVAssetResourceLoader 会忽略错误而一直处于 loading，直到超时。这种情况就比较尴尬，所以 VIResourceLoaderManager 提供了 delegate，如果内部出现错误，就会抛出错误，再又外部业务决定是如何处理。

注意：同一时间同一个 url 不能有多次下载： 由于缓存内部实现是对每一个 url 都共用同一个下载配置文件，如果同时有多次对同一个 url 进行下载，这个文件下载信息会被同时修改，下载信息会变得混乱。 MediaCache 内部做了简单的处理，如果正在下载某 url，这时再想尝试下载同样的 url 会直接抛出错误，提示无法开始下载。

已知问题

播到一半声音停了，视频正常播

比较低概率，在美拍上测试时有短视频会出现

弱网下一直loading到超时，但是文件都是已经下载好了

没有调用 AVPlayer 的 play 在弱网下会造成，AVPlayerLayer 一直无法达到 readyForDisplay 的情况

以上问题暂时没有很好的解决方案，因为 ResourceLoader 的实现只能做到控制缓存，但 AVPlayer 内的具体实现机制并不清楚，在缓存没有问题的情况下出现问题，很难去追根溯源寻找问题的根本原因。

吐槽

在实现 AVAssetResourceLoaderDelegate 的时候，文档非常少，几乎只能一边看头文件中的文档一边运行测试才能知道  AVAssetResourceLoaderDelegate 真正的运行机制。

另外最大的坑是 AVAssetResourceLoaderDelegate 的内部机制是个沙盒， 因为这个沙盒里面做了很多视频播放处理，导致遇到播放时出问题很难排查是什么原因引起，只能不断尝试去找规律....

小结

回顾全文，理解 AVAssetResourceLoaderDelegate 的原理和实现机制，再到自己实现一个 Downloader，讲了会遇到的几个坑以及如何解决，最后简单介绍了 MTMediaCache 如何使用。

完整的项目地址：https://github.com/vitoziv/VIMediaCache

更全的文章,里面有多做方案的对比,写的很好 : https://blog.csdn.net/kyl282889543/article/details/104354112

---

DNS对AVPlayer的解析, 部分地址是https的,替换成ip后会变成https://192.168.1.1/xxx.mp3, 系统校验https的证书校验不通过, 自动拦截不安全的请求 ,

可以给AVPlayer设置请求头(https://blog.csdn.net/weixin_33872660/article/details/86085136), 然后在自定义https的验证(https://blog.csdn.net/kyl282889543/article/details/104354112), https://blog.csdn.net/kyl282889543/article/details/102877244 ,

然后经过检查,发现HTTP的请求, 会被系统屏蔽,无法进入到delegate中 (https://stackoverflow.com/questions/60179072/avplayer-url-custom-loading-for-https , https://www.it1352.com/918282.html), 如果还想要进入到AVAssetResourceLoaderDelegate的delegate中, 就需要把请求的https改成自定义的scheme,比如https://xxx.mp3 -> ULhttps://xxx.mp3, 这样是太麻烦而且改动太大,所以就去掉AVPlayer下https情况下的DNS解析功能.