Cache缓存如何提高移动端性能

移动端性能中的缓存体系概览

• 通过合理组合HTTP 缓存、Service Worker + Cache API、本地存储（LocalStorage/SessionStorage/IndexedDB）以及页面导航缓存（BFCache），可以显著降低首屏时间、减少网络往返与流量、提升弱网/离线体验与交互流畅度。
• 各层职责清晰：协议层负责“是否可用、是否新鲜”，脚本层负责“何时取、如何更新”，数据层负责“结构化与离线数据”，浏览器层负责“页面级状态复用”。

HTTP 缓存 强缓存与协商缓存

• 强缓存：使用Cache-Control: max-age=…（如max-age=31536000一年）或Expires直接复用本地副本，避免网络往返；适合长期不变的JS/CSS/图片/字体等静态资源。
• 协商缓存：缓存过期后用ETag/Last-Modified向服务器验证，未变更返回304 Not Modified，仅传输少量头信息，减少带宽与时延。
• 文件名指纹：为资源加上内容哈希/版本号（如common.a1b2c3.js），配合长max-age，实现“更新即换新名、未变更走本地”，既提升命中率又避免304往返。
• 移动端要点：弱网下304仍会产生一次往返；对体积较大的资源设置较长max-age并用指纹策略，命中率更高、体验更稳定。

Service Worker 与 Cache API 离线与网络弹性

• Cache API可将HTML/CSS/JS/图片/字体乃至API JSON存入名为Cache的集合，按名称管理多个缓存版本；与Service Worker配合可拦截请求并自定义响应策略。
• 常用策略与场景：
  • Cache First：优先本地，适合静态资源与稳定内容，最快首屏。
  • Network First：优先网络，适合强实时数据（如订单状态），失败再降级到缓存。
  • Stale-While-Revalidate：先秒开旧内容，同时在后台拉新并更新缓存，兼顾速度与新鲜度。
• 落地步骤：注册Service Worker → 安装阶段预缓存关键资源 → 激活阶段清理旧缓存 → 运行时按路由与资源类型选择策略 → 版本升级时增量更新并提示用户刷新。

本地存储 IndexedDB 与 Web Storage 的数据缓存

• LocalStorage/SessionStorage：键值对、同步、容量通常约5MB；适合主题/语言偏好、表单草稿等小数据。SessionStorage在页面会话结束即清除。
• IndexedDB：事务型、支持索引/查询/大量数据，适合离线文章/消息/图片元数据等结构化与频繁读写场景；容量显著高于Web Storage。
• 实践建议：按数据类型分层——配置类走LocalStorage，会话态走SessionStorage，结构化/大体积走IndexedDB；为缓存项设置TTL与版本，并做存储配额监控与淘汰（如LRU）。

导航与工程实践 提升命中率与可维护性

• BFCache（Back/Forward Cache）：现代浏览器会在后退/前进时保留页面DOM/JS 上下文与内存状态，实现瞬时返回；通过避免beforeunload副作用、减少全局状态副作用、稳定URL/查询参数来提升命中率。
• WebView 与混合应用：Android WebView同样遵循HTTP 缓存与存储配额规则；注意不同内核与版本的缓存容量/清理策略差异，必要时提供手动清理/离线包更新入口。
• 监控与迭代：用Lighthouse/DevTools评估FCP/TTI与缓存命中率，设定目标（如命中率≥0.8），按网络类型/设备与版本动态调整TTL/策略；避免缓存敏感数据或为其加密。