DFPlayer边下边播与断点续传的奥秘：AVAssetResourceLoader与Range请求深度剖析

DFPlayer边下边播与断点续传的奥秘：AVAssetResourceLoader与Range请求深度剖析

【免费下载链接】DFPlayer(已不维护)简单灵活的iOS音频播放组件。基于AVPlayer，支持本地和远程音频播放，具有缓存、耳机线控、锁屏和控制中心信息展示、单曲顺序随机播放、倍速播放、歌词同步等音频播放器功能，DFPlayer封装了缓冲条、进度条、播放暂停按钮、下一首按钮、上一首按钮、播放模式按钮、歌词同步的tableview等UI控件，一行代码布局即可实现相应功能。项目地址: https://gitcode.com/gh_mirrors/df/DFPlayer

DFPlayer 是一款简单灵活的 iOS 音频播放组件，基于 AVPlayer 打造，核心卖点之一就是边下边播与断点续传：网络音频无需等待下载完成即可开声，中途断网还能从上次位置继续下载。本文带你拆解这套机制背后的两大功臣——AVAssetResourceLoader协议和 HTTPRange请求，看看 DFPlayer 是如何用不到 500 行代码实现"即点即播 + 缓存 + 续传"的完整音频体验的。

🎯 什么是边下边播？为什么音频 App 都离不开它

想象一下：你点开一首 5MB 的网络歌曲，如果必须等下载完 100% 才能播放，弱网环境下可能要干等十几秒。而边下边播（Streaming Playback）的思路是——只下载前面一小段数据就开始解码播放，剩余数据在后台边下边补。

音频 App 里通常还要叠加两个需求：

• 断点续传：下载到 60% 时断网或切歌，下次继续时不应从头再下；
• 缓存复用：整首下载完成后存到本地，下次播放零流量。

DFPlayer 的 README 中明确将"边下边播""分账户缓存""断点续传"列为核心功能，下面逐一拆解其实现。

🔑 原理第一步：一个"假协议头"骗过 AVFoundation

要实现"我自己决定数据从哪来"，关键在于让 AVPlayer 的底层资产AVURLAsset主动把数据请求交给开发者处理。Apple 提供了标准方案：自定义 URL scheme +AVAssetResourceLoaderDelegate。

DFPlayer 的第一步非常巧妙，见 DFPlayerTool.m：

把真实地址https://xxx.com/a.mp3改写成https-streaming://xxx.com/a.mp3，再把这个"假地址"交给AVURLAsset创建播放资产。

AVFoundation 发现https-streaming不是它认识的协议，就会转而询问代理："这个资源的请求，你来负责吗？" 于是控制权就交到了 DFPlayer 手里，后续真正下载时再用originalURL:把协议头还原回真实的https地址。

在 DFPlayer.m 的loadAudioWithCachePath:方法中，可以看到完整的装配过程：创建DFPlayerResourceLoader→ 生成自定义 scheme 地址 → 创建AVURLAsset→ 将代理挂到asset.resourceLoader上。

⚡ 边下边播的核心链路：请求拦截与按需喂数据

拦截资源请求

当播放启动、AVPlayer 需要解码数据时，会回调代理方法resourceLoader:shouldWaitForLoadingOfRequestedResource:，见 DFPlayerResourceLoader.m。每次回调携带一个AVAssetResourceLoadingRequest，其中记录了"从哪个字节偏移、要多少字节"。

DFPlayer 把所有未完成的请求放进一个队列requestList，并立即创建一个下载任务去拉数据——注意此时只请求播放头需要的数据，并非整首歌。

边下载、边喂给播放器

真正的下载由 DFPlayerRequestManager.m 承担，它基于NSURLSessionDataDelegate逐块接收网络数据，并边收边写入本地临时文件（MusicTemp.mp4），逻辑见 DFPlayerFileManager.m。

每当磁盘上多出新的字节，DFPlayer 就会遍历请求队列，用NSFileHandle按偏移量读出所需区间，通过respondWithData:塞回给 AVPlayer，满足条件的请求调用finishLoading出队，核心逻辑见 DFPlayerResourceLoader.m：

• requestedOffset/requestedLength：播放器要的字节区间；
• cacheLength - requestedOffset：本地临时文件已就绪的数据量；
• 两者取小值后喂回，不足则留队等待下一批数据。

与此同时，DFPlayer 关闭了automaticallyWaitsToMinimizeStalling（见 DFPlayer.m），让 AVPlayer 少囤缓冲、更快起播——"下载 → 落盘 → 按需读盘 → 回喂"这条流水线的每一环都不等待彼此，这就是边下边播的全部奥秘。

🔁 断点续传：Range 请求与三个状态码的故事

首次下载：200 OK

第一次请求不带任何特殊头，服务器返回200和完整文件，DFPlayer 记录Content-Length作为fileLength，数据块持续追加写入临时文件。

中途断网：206 Partial Content + Range

这是断点续传的关键。DFPlayer 内置了网络状态监听（DFPlayerRequestManager.m 中的startMonitoringNetworkStatus），一旦检测到网络恢复，立即执行resumeRequestStart：

1. 把requestOffset设为当前已缓存长度cacheLength；
2. 在请求头中加上Range: bytes=已下载字节-文件总长（见 DFPlayerRequestManager.m）；
3. 服务器返回206 Partial Content，只传输剩余部分。

已落盘的字节一字节都不浪费，播放器甚至可能无感恢复——用户视角就是"卡了一下又继续了"。

二次播放：304 Not Modified + ETag 校验

若整首已缓存完成，下次播放时 DFPlayer 会把上次服务器返回的ETag和Last-Modified分别放进If-None-Match、If-Modified-Since请求头（见 DFPlayerRequestManager.m）：

状态码的分发逻辑集中在 DFPlayer.m 的checkStatusBlock中，一目了然。

📦 缓存体系：临时文件与分账户目录

下载过程中的"中转站"和最终"仓库"都由 DFPlayerFileManager.m 管理：

• 临时文件：所有未完成的下载先写到系统 Temp 目录的MusicTemp.mp4，天然支持按偏移随机读写，是边下边播的"缓冲区"；
• 正式缓存：下载完成后整体移动到沙盒Caches/DFPlayerCache/user_用户名/目录，按用户分账户隔离；
• 归档记录：ETag/Last-Modified等校验信息存入DFPlayer.archiver归档文件，供下次 304 校验使用（见 DFPlayerFileManager.m）。

此外还提供缓存大小统计、按单曲/按用户清除缓存等能力，方便 App 做存储管理界面。

📚 核心文件速查表

✨ 总结

回顾 DFPlayer 的音频下载播放方案，本质上是一条教科书级的流水线：

1. -streaming假协议触发AVAssetResourceLoader委托，把数据源控制权拿回来；
2. 请求队列 + 临时文件让"网络下载"与"解码播放"彻底解耦，实现边下边播；
3. Range头 + 206实现字节级断点续传，ETag+ 304实现缓存零流量复用；
4. 分账户缓存目录让数据管理清晰可控。

这套设计对想给 iOS 项目加网络音频能力的开发者极具参考价值：不用任何第三方网络库，仅凭AVAssetResourceLoader与 HTTP 标准头，就能构建出稳定、省流的"即点即播"音频体验。

【免费下载链接】DFPlayer(已不维护)简单灵活的iOS音频播放组件。基于AVPlayer，支持本地和远程音频播放，具有缓存、耳机线控、锁屏和控制中心信息展示、单曲顺序随机播放、倍速播放、歌词同步等音频播放器功能，DFPlayer封装了缓冲条、进度条、播放暂停按钮、下一首按钮、上一首按钮、播放模式按钮、歌词同步的tableview等UI控件，一行代码布局即可实现相应功能。项目地址: https://gitcode.com/gh_mirrors/df/DFPlayer