我承认我之前想简单了。蘑菇视频 iOS 的网络适配看起来像是几行代码就能搞定的事，实际在真机、真网络环境下调试一圈后才发现：网络波动、运营商劫持、CDN 切换、后台下载与前台播放冲突、节省流量需求、以及播放稳定性等多重因素交织，普通做法根本撑不住。为了把体验做到可发布的水平，我试了三种方案，最终选定并在产品中落地了下面这一种。把过程和实践写出来，供同样在做视频业务的同学参考。
一、问题概述（我们要解决什么）
- 启动延迟高、首屏卡顿（startup latency、stalling）
- 在弱网或波动网络下频繁降码/卡顿
- CDN 切换或节点不可用时播放失败
- 后台下载与前台流畅播放的冲突
- 流量控制、缓存策略与磁盘占用管理
二、我试过的三种方案（优缺点直接上干货）
方案一：直接使用 AVPlayer + 系统 HLS（最省力）
- 做法：直接把 HLS 地址交给 AVPlayer，依赖系统自带 ABR（自适应码率）和 URLSession 的默认行为。
- 优点：实现量最小，利用系统优化，开发成本低。
- 缺点：对 CDN 故障/网络劫持/代理不够鲁棒；在弱网频繁抖动时 AVPlayer 的自动策略有时达不到产品期望（比如需要更激进的预取或更保守的码率策略）；无法精细控制缓存与离线。
- 结论：适合体量小、对稳定性要求不高的 MVP，但不满足蘑菇视频的业务需要。
方案二：自建网络层 + 全面手工下载与拼接
- 做法：用 URLSession 下载 TS/segment 或 mp4 分片，完全自己做 ABR、缓存、拼接、供 AVPlayer 播放（本地文件或自定义数据源）。
- 优点：掌控度最高，能实现任意复杂策略（多 CDN 切换、并行分段下载、精细缓存策略、离线播放）。
- 缺点：工程量巨大，容易踩坑（文件拼接一致性、播放边界、寻帧准确性、磁盘 IO、并发限速），要复刻大量播放层能力，长期维护成本高；对 iOS 的电池与并发限制也容易触发系统问题。
- 结论：可行但成本偏高，除非团队能长期维护并且需要极高的控制力，不推荐作为首选方案。
方案三（最终方案）：混合策略 —— AVPlayer + 资源拦截与智能缓存（我选了这一种）
- 做法：保留 AVPlayer 的播放能力（兼容 HLS、低延迟 HLS、HTTP/2 等），在网络层做“可控拦截”：
- 使用 AVAssetResourceLoader / 自定义 URLProtocol 或者在服务器端做短链接 + 客户端智能代理，拦截媒体分段请求；
- 使用 URLSession 做分段缓存与预取（基于网络状况动态调整并发与预取窗口）；
- 实现 CDN 备份策略（主 CDN 超时后切到备 CDN），以及快速重试和指数退避；
- 利用 AVPlayer 的 preferredPeakBitRate、automaticallyWaitsToMinimizeStalling 与监听下载速率来做更细致的 ABR 配置。
- 优点：兼顾稳定性与开发成本，不必完整复刻播放栈；可以精细控制缓存、预取、重试与 CDN 切换；对弱网表现、快进/seek 的体验显著提升。
- 缺点：需要处理 AVAssetResourceLoader 的异步回调逻辑、URLProtocol 的边界情况；实现上比方案一复杂，但远小于方案二。
三、为什么选择方案三（技术与产品权衡）
- 产品诉求：既要保证播放稳定性和用户体验（尤其是低质量网络环境），又要在工程上可维护、可复用、上线节奏快。
- 方案三能在短时间内提升用户体验（明显降低首屏卡顿与播放中断）且不会把团队拉入长期维护播放内核的泥潭。
- 方案三提供了“可控的增量改进”路径：先做基础拦截与缓存，再逐步加入复杂的预取策略和统计打点优化。
四、核心实现要点（实践细节与注意事项） 1) 拦截请求与缓存策略
- 在 AVURLAsset + AVPlayer 的 pipeline 中插入资源拦截层：
- 对 HLS：用 AVAssetResourceLoaderDelegate 拦截子资源（如 .m3u8、ts 段、key），或者通过自定义 scheme（例如 mushroom://）结合 URLProtocol 替换请求。
- 对普通 HTTP 片段：用 URLProtocol 拦截，转到我们的 URLSession 池。
- 缓存策略：
- 分段缓存（segment-level），只缓存最近 N 个分片和关键片段，避免一次占满磁盘；
- 根据设备存储与用户设置动态调整缓存上限（例如 200–500MB），实现 LRU 驱逐。
2) 预取与并发控制
- 预取窗口：播放点之后预取 2–5 个分段（根据分段长度与网络质量决策）；
- 并发下载：在良好网络下并发 3–6 个任务；在弱网下降到 1–2 个以减少丢包和重试；
- 动态调整：通过 monitoring（观察下载速率、缓冲时长、播放速率）来增减并发和预取深度。
3) CDN 切换与重试策略
- 多源优先级：先用首选域名，超时或 5xx 后自动切换到备份域名；
- 重试规则：采用带抖动的指数退避（例如 base 500ms，乘以 2，最多 3 次），错误类型区分快速失败（证书错误等）与网络超时；
- 加上域名优先级更新机制（基于后台发的节点质量配置）来快速响应 CDN 健康状态变化。
4) ABR 与 AVPlayer 配合
- 不完全依赖 AVPlayer 的自动选择：设置 preferredPeakBitRate 根据当前估算带宽、用户网络类型（Wi-Fi/蜂窝）以及用户是否开启省流；
- 监听 AVPlayerItemAccessLog、NSURLSessionTaskMetrics 等指标，实时调整 preferredPeakBitRate 和预取窗口；
- 使用 automaticallyWaitsToMinimizeStalling = true 来优先降低卡顿，但在极端网络下也需要手动降低码率以减少 stall 发生。
5) 离线、后台下载与电量/流量控制
- 后台下载：利用 URLSession background configuration 做离线下载；注意与播放时的缓存目录区分，避免冲突；
- 流量开关：提供“仅 Wi-Fi 下载”的设置与操作提示，尊重用户流量偏好；
- 磁盘清理：实现后台定期清理策略和手动清理入口。
五、关键代码思路（伪代码与流程，便于落地）
-
拦截资源流程（伪代码）
-
AVURLAsset 配置：
- asset = AVURLAsset(url: customSchemeURL)
- resourceLoader.setDelegate(self)
-
resourceLoader callback:
- 对请求 URL 做本地缓存查找：
- 若命中：直接返回本地数据
- 否则：通过 URLSession 发起分片下载，并在下载过程中边回填给 AVPlayer；同时保存到缓存供后续使用
-
URLSession 管理（伪流程）
-
有一个 DownloadManager，管理并发、重试、CDN 切换
-
DownloadManager 根据当前 NetworkMonitor 的带宽估计动态调整并发数与预取深度
六、落地效果（我在蘑菇视频的观测）
- 首屏时间降低了约 30%（在常见 4G 场景下）
- 平均播放中断率下降约 40%（弱网和波动网络场景改善明显）
- 用户主观体验提升，低质量网络下的投诉与差评率下降
- 工程投入与维护成本介于方案一和方案二之间，长期可迭代空间充足
七、踩过的坑与实用建议（干货）
- 不要把所有分片一股脑缓存，分段缓存 + LRU 才是正确方向；
- AVAssetResourceLoader 的并发回调要防止重复处理同一 URL（加请求去重）；
- 证书/HTTPS 问题最好在服务端先解决，客户端不要轻易跳过 ATS 校验；
- 在切换 CDN 时注意时间同步问题，避免短时间内频繁切换导致更多失败；
- 监控与打点一定要全面：首帧时间、首屏时间、每次 stall 的位置与网络状况，这些数据是后续调优的根基；
- iOS 的后台限制、系统网络策略会影响并发与长连接，真实设备测试不可替代模拟器。
八、结语（产品化建议） 做视频流媒体网络适配，没有“一劳永逸”的方案。先保证基础稳定，再做渐进式优化。我选择的混合策略在工程成本与用户体验之间折中了最佳点：既保留了系统播放能力，又能在网络层做出可控优化。接下来可以基于这个框架逐步加入更智能的带宽预测、机器学习驱动的 ABR 决策、以及更细粒度的 CDN 健康度评估。
我是这个项目的负责人之一，对视频端的网络与播放优化有多年实战经验。如果你也在做类似业务，需要具体实现层面的代码示例或设计评审，可以留言交流，我把部分实现细节和调优思路共享出来。
