蘑菇视频 iOS 的播放进度怎么配才省心又稳？很多同学要么只是把系统默认的进度条搬过来，要么做了半成品：拖动卡顿、缓冲不准、退出后不记位置、体验断层。下面给出一套实战可落地的配置和实现思路——面向产品与工程双端，简单、稳妥、用户体验好，不走弯路。
目标总结
- 进度显示精确且不卡顿（播放进度 + 缓冲进度）
- 拖动/跳转流畅，避免频繁创建播放器请求
- 退出再进可记住上次播放点并可选择继续/从头
- 在弱网/切换清晰度/切换视频时稳定可靠
- 易于统计与 AB 测试改进体验
总体思路（高层）
- 用 AVPlayer（或基于 AVFoundation 的封装）做播放核心
- 用 periodicTimeObserver 更新主进度，用 loadedTimeRanges 更新缓冲进度
- 拖动操作做节流 / debounce，减少频繁 seek
- 把播放位置（按视频 ID）写入本地（UserDefaults 或小型 DB），并在 loading 完毕后自动恢复
- 优先采用 HLS（m3u8）以获得自适应码率和更稳定的缓冲表现；若非 HLS，做好缓存与断点续传策略
具体实现要点（工程师能直接落地） 1) 精准、稳定的播放进度更新
- 使用 AVPlayer 的 addPeriodicTimeObserver(forInterval:queue:using:)，推荐间隔 0.5s（直播或实时场景可更短）
- 更新 UI 时只把关心的数据通过主线程传出去：总时长、当前时间、缓冲时间（后面说如何计算）
- 当前时间取 CMTimeGetSeconds(player.currentTime())，注意处理 duration 为 indefinite 的情况
2) 缓冲进度显示（用户感知很重要）
- 从 player.currentItem?.loadedTimeRanges 中取第一个 timeRange，计算缓冲到的秒数（CMTimeGetSeconds(timeRange.start) + CMTimeGetSeconds(timeRange.duration)）
- 用缓冲时间 / 总时长做缓冲条长度的估算。若使用 HLS，可更信赖 loadedTimeRanges；若是 progressive download，结合 HTTP head 做更保守的判断
3) 平滑拖动体验（避免卡顿或过多请求）
- 拖动时不要每次触发 seek。做“节流或 debounce”：用户在拖动过程中只更新 UI 的显示（时间标签、预览图），等拖动结束（touchUpInside/touchUpOutside）再触发一次 seek。
- 若需要精细拖动体验，可在拖动过程中每隔 300ms 发一次 seek（throttle），同时使用 seek(to:toleranceBefore:toleranceAfter:) 并给较大的 tolerance 在拖动阶段，求快速响应；拖动结束后再以 tolerance 为 0 精确跳转。
- 使用 setRate(0) 或 pause 配合 seek，确保状态可控。
4) 退出与恢复播放点（用户体验赢单）
- 在合适的时机（例如每隔 5-10 秒或离开播放页时）把当前播放时间写入本地：UserDefaults.standard.set(value, forKey: "position_(videoId)")
- 打开视频时，读取该值，若大于某阈值（例如 5s 且小于总时长 - 5s），提供“继续播放 / 从头开始”按钮或自动恢复到上次位置并提示用户
- 恢复 seek 的时机：等 player.currentItem?.status == .readyToPlay 之后再执行 seek。
5) 缩略图预览（拖动时的视觉反馈）
- 使用 AVAssetImageGenerator 生成缩略图，生成应异步并做缓存（内存或磁盘），并在拖动时先展示缓存缩略图，再异步生成未命中的图像
- 控制生成分辨率，避免生成过大图片影响性能
6) 弱网与切换清晰度
- 推荐使用 HLS：系统会自动进行 ABR（自适应码率），缓冲与切换更平滑
- 若需手动切换清晰度：先记录当前时间，stop currentItem，切换资源后在 readyToPlay 后 seek 到记录位置，期间用 loading 状态和占位图遮蔽突兀感
- 在弱网下可显示“低清/省流”提示，并提供一键切换
7) 缓存与离线
- 对短视频或重复访问的片段，可以用本地缓存。iOS 上常见方案：URLCache（适合小文件）、自建文件缓存 + HTTP Range、或 AVAssetDownloadURLSession（对 HLS 离线下载友好）
- 缓存策略要和 App 的存储清理策略配合：限制总大小、LRU 淘汰、按用户登录区分
8) 统计埋点与 A/B 测试
- 关键事件：播放开始、真实开始（first frame）、播放中断、seek 次数、拖动行为、切换清晰度、继续播放次数
- 埋点数据能帮助确定最佳的进度条刷新频率、缓冲展示策略与是否需要自动恢复
UI/产品细节建议（不止是技术）
- 进度条上同时展示：已播放（主色）、缓冲（淡色）、可视时间指示（当前时间/总时长）
- 拖动时显示时间提示和缩略图，结束后给明确的“继续/重头”选择
- 小而常用的控制：快退 10-15s、快进 10-15s，用户更喜欢这种短跳操作
- 对长视频加章节标记，点击章节可以直接跳转，同时在进度条上展示关键节点（比如广告点、精彩片段）
- 提供清晰的错误和重试机制（网络断开、404 等），让用户知道下一步可做什么
测试建议（少走弯路）
- 在真机上做弱网测试（2G/3G/Wi‑Fi 切换、丢包、延迟）并记录卡顿率
- 用工具模拟磁盘满、低内存场景，观察缓存及图片生成逻辑
- 做 AB 测试：比如把 periodicTimeObserver 频率从 0.2s 到 1s 做对比，衡量 UI 平滑感与 CPU 消耗的权衡
收尾（一句话总结） 按上面这套方法，播放进度会更精准、拖动更顺滑、退出恢复更友好，工程实现也好维护——省心又稳，别再走弯路。
需要我把关键代码片段整理成一个可复用的 Swift 模板（包括 periodicTimeObserver、seek 节流、缓存键值管理和恢复逻辑）吗？我可以把它写成一个小库级别的示例，方便直接集成。
