谨慎处理 Service Worker 的更新

今天要聊的话题是前端最近的一个更新方向 PWA 中的核心 Service Worker 的更新问题。这是一个很容易被开发者忽略的问题,因为绝大部分开发者可能对它还不太熟悉。

Service Worker 以其 异步安装持续运行 两个特点,决定了针对它的更新操作必须非常谨慎小心。因为它具有拦截并处理网络请求的能力,因此必须做到网页(主要是发出去的请求)和 Service Worker 版本一致才行,否则就会导致新版本的 Service Worker 处理旧版本的网页,或者一个网页先后由两个版本的 Service Worker 控制引发种种问题。

经过近 2 年的发展,PWA 在 WEB 圈的知名度已经大大提升,即便你没用过可能也至少听说过。Service Worker (以下简称 SW)是 PWA 中最复杂最核心的部分,其中涉及的主要有 Caches API (caches.put, caches.addAll 等), Service Worker API (self.addEventListener, self.skipWaiting 等) 和 Registration API (reg.installing, reg.onupdatefound 等)。

本文不再科普 SW 的基础,我主要想在这里谈一谈 SW 的更新问题。需要做到 SW 和页面的完全同步,其实并不容易。在此之前,我假设你已经了解了:

  1. SW 的作用
  2. SW 的注册方式 (navigator.serviceWorker.register)
  3. SW 的生命周期 (install -> waiting -> activate -> fetch)

组织 SW 的两大禁忌

在开始正式谈论 SW 的更新机制之前,我们有必要先确定组织 SW 时的两个禁忌。在将 SW 应用到自己的站点时,我们要避开这两种方法,他们是:

不要给 service-worker.js 设置不同的名字

一般针对静态文件,时下流行的做法是在每次构建时根据内容(或者当时的时间等随机因素)给它们一个唯一的命名,例如 index.[hash].js。因为这些文件不常修改,再配以长时间的强制缓存,能够大大降低访问它们的耗时。

可惜针对 SW,这种做法并不合适。我们假设一个项目

  1. 首页 index.html,底下包含了一段

你可能感兴趣的:(谨慎处理 Service Worker 的更新)