我把数据复盘了一遍：你以为新91视频只是界面不同？其实缓存管理才是关键（建议收藏）
最近把新91视频的一批播放日志、埋点和网络抓包数据复盘了一遍。结论超出预期：很多人把体验差归咎于界面改动或播放器逻辑，实际上影响最大、最被忽视的，是客户端与 CDN/缓存之间的“缓存管理”策略。下面把复盘过程、关键发现和可立刻落地的优化拆成清晰的步骤，方便产品和工程团队作为排查与改进清单收藏使用。
一、我怎么做的（简要复盘方法）
- 数据范围：分析了近 30 天的播放日志，覆盖约 50 万次播放会话、若干条 CDN 和原点日志，以及设备端抓包样本。
- 会话重构：把播放流程切分为事件流（请求 manifest / init segment / media segment / seek / pause / resume），计算每一类请求的响应时间、缓存命中率与失败率。
- 关键指标：首帧时间（TTFF）、首次缓冲时间、重缓比（rebuffer ratio）、平均码率、缓存命中率（client-cache + CDN-cache）、重复下载量（同一分段重复请求次数）。
- 工具链：日志 + BigQuery（或类似的 OLAP）、Chrome/Charles 抓包、Android Profiler、服务器端 CDN 报表、Grafana 做趋势展示。
二、最重要的发现（核心结论） 1) 缓存命中率与体验直接相关：命中率高的会话，TTFF 中位数接近 1s，重缓次数极低；命中率低的会话，TTFF 翻倍甚至更多，重缓显著上升。 2) 问题并非只在 UI 新旧：即便旧 UI 的播放逻辑保留，一旦缓存策略被改得更频繁清理或忽略了分段缓存优势，播放体验也会变差。 3) 客户端碎片化缓存与错误的失效策略导致大量重复下载：同一视频的同一分段，在短时间内被多次下载，浪费网络并增加 CDN 成本。 4) Manifest / init-segment 与媒体分段采用不同缓存策略，但实现上却被统一化处理，结果是关键小文件被过度淘汰，导致频繁重新解析与下载。
三、常见的“踩坑”场景（从数据看出来）
- 小文件（manifest、init）被频繁剔除：这些文件一旦缺失，播放器需要重新发起多次请求，增加延迟。
- 缓存粒度不合理：按整片文件缓存（而非按段）会导致 seek/预取效率低；按段但没有合理的索引/元数据，会导致碎片化与 metadata overhead。
- 忽视 HTTP 缓存头：CDN 与客户端使用不一致的 Cache-Control/ETag 策略，导致客户端不走本地缓存而频繁向 CDN 验证。
- 待机或低存储设备被动清理：系统清理缓存时没有区分重要性，播放关键段被误删。
- 预取策略泛滥或缺失：不恰当的预取既浪费流量，又增加了缓存压力；缺乏优先级则导致播放关键段未优先缓存。
四、从工程角度可落地的优化（优先级排序） 1) 立刻可做的“快赢”（1–2 周）
- 优先缓存播放关键文件：manifest、init segment 与播放前 1–2 个媒体分段应使用更高的缓存保留优先级。
- 确保统一的 HTTP 缓存头策略：Manifest 可使用较短但可验证的 TTL（例如 60s）并结合 ETag；媒体分段使用较长的 TTL + content-versioning（URL 含版本号）以避免频繁校验。
- 启用/优化 DiskLruCache（或等效库）：控制磁盘缓存上限、最小保留单位为分段、使用 LRU 并记录访问热度。
- 避免重复下载：未完成下载的临时文件要支持断点续传与原子替换，避免同一分段并发重复请求。
- 客户端对外暴露“清缓存”入口并做提示：在存储稀缺时优先剔除非播放关键资源。
2) 中期改进（1–2 个月）
- 分段优先级策略：播放器在后台预取时应优先获取下 N 个分段（保证连续播放），非关键分段放到低优先级队列。
- 缓存分区（content-type / hotness）：将 manifest/init、头部若干分段、远端分段分为不同目录或命名空间，分别设置限额与淘汰策略。
- CDN + 客户端协作：在 CDN 边缘配置 stale-while-revalidate，客户端在失败时尽量读取 stale 数据并异步验证更新。
- 采样落地指标：把缓存命中率、重复下载次数、分段重传率纳入日常 Dashboard。
3) 高级进阶（3 个月以上）
- 智能预热：基于用户行为与推荐热度对热门内容做局部预热（仅限在 Wi‑Fi & 空闲时），并记录预热命中对 KPI 的提升。
- 细粒度缓存感知 ABR：结合缓存状况调整初始码率与预缓冲长度；在设备缓存充足时可提高初始码流以减少切换。
- 边缘侧优化：在 CDN 侧做 segment-level cache analytics，针对热门分段提前扩容或锁定到内存层。
- 考虑 P2P/边缘协同（谨慎）：在合规与隐私允许下，探索局域网/同城 P2P 分段共享以降低 origin 压力。
五、示例策略片段（伪代码思路）
- 缓存分级伪逻辑： 1) 请求 manifest -> 检查本地 manifest cache (age < 60s) -> 命中直接返回。 2) 请求 init/首段 -> 保持高优先级，若本地无则优先从网络获取并同步写入 cache。 3) 请求中间分段 -> 优先返回缓存，若缺失则并发请求前后分段以保证连续播放。 4) 系统清理时：先清理低优先级分段，再清理 manifest/init。
六、如何量化改进效果（推荐 KPI）
- 首帧时间（TTFF）中位数下降目标：30%+
- 重缓比降低：目标 20–50%（视当前基线）
- 客户端缓存命中率提升：目标从 50% 提升到 75%+
- 重复下载次数减少：目标每会话重复下载 < 1 次
- CDN 流量节省：按场景估算，命中率提升每提升 10% 可节省约 5–15% 的边缘流量（需结合内容长度与用户行为确认）
七、给产品/PM 的建议（3 点）
- 把缓存指标纳入体验评估：界面改动或功能发布前后，除了 UI 指标，也需要对缓存命中率、重传率、TTFF 做 A/B 对比。
- 不要把“清缓存”当成万能招：临时提升可用空间不能以牺牲 playback-critical 文件为代价。
- 版本与 URL 管理并重：通过版本号或签名让 CDN 与客户端正确区分“内容更新”与“可缓存内容”，避免暴力失效。
结语 界面看得见，改动容易被注意；缓存看不见，但它决定了体验的“连续性”和成本。把缓存管理当作产品体验的第一性问题来对待，从分段粒度、优先级、HTTP 策略和缓存监控这几方面入手，短期能拿到明显的体验和成本改善。建议把上面的检查点列进下一个迭代的验收清单里，优先做几项“快赢”，再推进中长期优化。
如果你想，我可以把其中某项（比如分段优先级实现、DiskLruCache 的工程实践或 CDN cache-head 策略）拆成更详细的技术实现文档或代码示例，方便工程落地。收藏起来，随时对接改进落地。
