Service Worker 生命周期

install 事件是 SW 触发的第一个事件,并且仅触发一次。
  • installEvent.waitUntil() 接收一个 Promise 参数,用它来表示 SW 安装的成功与否。
  • SW 在安装成功并激活之前,不会响应 fetch 或 push 等事件。
  • 默认情况下,页面的请求(fetch)不会通过 SW,除非它本身是通过 SW 获取的,也就是说,在安装 SW 之后,需要刷新页面才能有效果。clients.claim() 可以改变这种默认行为。

  • install 是在 SW 控制 clients 之前处理缓存很好的时机。

    安装成功后并激活(activate)成功后,SW 就可以处理"功能性的事件"了,比如push,sync。但这并不代表调用 .register() 的页面会立即生效,你可以在 activate 事件中通过调用 clients.claim() 来让没被控制的 clients 受控。

    在同域的任何 URI 上添加 clear-site-data "storage" 响应头 unregister sw // 下次生效

    更新 Service Worker

    • 触发更新的几种情况:
      • 第一次导航到作用域范围内页面的时候
      • 更新 push 和 sync 等功能事件,除非在前 24 小时内进行了更新检查。
      • SW 的 URL 发生变化并调用.register()时
    • 当 SW 代码发生变化,SW 会做更新(还将包括引入的脚本)
    • 更新后的 SW 会和原始的 SW 共同存在,并运行它的install
    • 如果新的 SW 不是成功状态,比如 404,解析失败,执行中报错或者在 install 过程中被 reject,它将会被废弃,之前版本的 SW 还是激活状态不变。
    • 一旦新 SW 安装成功,它会进入wait状态直到原始 SW 不控制任何 clients。
    • self.skipWaiting() 可以阻止等待,让新 SW 安装成功后立即激活。

    触发更新算法后,浏览器会检查并遵循 sw.js 的文件缓存(HTTP 缓存)设置,比如 max-age。 这意味着:
    • 如果不设置 sw.js 的 HTTP 缓存,每次页面加载该文件都会被请求。
    • 如果设置了 10s 的缓存,则 10s 内浏览器不会再次访问服务器。
    • // 更新 sw 自身肯定不会通过 sw

    "尽管这个例子中你仅打开了一个 tab,但刷新页面并没有用,这是由于浏览器本身的机制,当你刷新的时候,当前页面不会离开,直到收到了一个响应头,而且即使这样,如果响应中包含Content-Disposition的话,当前页面还是不会离开。由于这个时间上的重叠,在刷新的时候当前的 SW 总是控制了一个 client。"

    Activate 在旧的 SW 离开时会被触发,在event.waitUntil()中传入了一个 Promise,SW 将会缓存住功能性事件(fetch,push,sync等等),直到 Promise 返回 resolve 的时候再触发,也就是说,当你的fetch事件被触发的时候,SW 已经被完全激活了。

    如果你强制刷新页面,那么会绕过 SW,变成不受控,这个功能已被定为规范,所以在其他支持 SW 的浏览器中也适用。

    Cache API 跟 HTTP 缓存控制互不相干, 更新 sw 是不能通过 sw 本身来代理的

    service worker 中的事件 sync push 等都能在被 kill 掉之后触发。

    更新完 sw 后 Client 会触发 controllerchange 事件

    给用户提示进行更新:
    1. 浏览器检测到存在新的(不同的)SW 时,安装并让它等待,同时触发 updatefound 事件
    2. 我们监听事件,弹出一个提示条,询问用户是不是要更新 SW
    3. 如果用户确认,则向处在等待的 SW 发送消息,要求其执行 skipWaiting 并取得控制权
    4. 因为 SW 的变化触发 controllerchange 事件,我们在这个事件的回调中刷新页面即可