PWA资料整理（二）：Service Worker 离线缓存

本篇是 PWA 资料整理的第二篇，主要介绍 Service Worker 所实现的离线缓存相关内容。

系列链接

1. Manifest 添加到桌面
2. Service Worker 离线缓存（本篇）
3. Service Worker 消息推送

HTML5 Manifest

说到离线缓存，那就不得不提到之前 W3C 标准的 HTML5 Manifest 的 App cache 离线缓存了。虽然是官方标准，但是一直都没什么热度，大家都不爱用，因此也没去尝试。
HTML5 Manifest 几个注意（坑）点大概如下：

• 站点离线存储的容量限制是5M
• 如果manifest文件，或者内部列举的某一个文件不能正常下载，整个更新过程将视为失败，浏览器继续全部使用老的缓存
• 引用manifest的html必须与manifest文件同源，在同一个域下
• 在manifest中使用的相对路径，相对参照物为manifest文件
• CACHE MANIFEST字符串应在第一行，且必不可少
• 系统会自动缓存引用清单文件的 HTML 文件
• manifest文件中CACHE则与NETWORK，FALLBACK的位置顺序没有关系，如果是隐式声明需要在最前面
• FALLBACK中的资源必须和manifest文件同源
• 当一个资源被缓存后，该浏览器直接请求这个绝对路径也会访问缓存中的资源。
• 站点中的其他页面即使没有设置manifest属性，请求的资源如果在缓存中也从缓存中访问
• 当manifest文件发生改变时，资源请求本身也会触发更新

Service Worker

Service Worker 可能是 PWA 相关技术中最重要的一个了，其可以充当Web应用程序与浏览器之间的代理服务器，也可以在网络可用时作为浏览器和网络间的代理。SW 能够创建有效的离线体验，拦截网络请求并基于网络是否可用以及更新的资源是否驻留在服务器上来采取适当的动作。
除了提供离线缓存的能力以外，SW 能够做的事情还很多，如：

• 预取用户可能需要的资源；
• 如 Web Worker 一样，负责处理密集的 CPU 计算，如地理位置和陀螺仪信息的计算；
• 后台数据同步；
• 消息推送；
• etc。

SW 的特点是套路非常固定，无侵入，直接复制粘贴就可以实现缓存和离线功能，纯前端，无需服务器配合。

Service Worker 生命周期

两张（偷来的）图，分别是 Service Worker 自身线程的生命周期：

以及Service Worker 线程与渲染主线程的交互过程：

SW 线程的生命周期包含安装、激活、等待、销毁四个阶段，具体如下：

1. 渲染主线程执行script中代码，其包含了对 sw api 的调用，并将用户编写的 sw.js 文件进行注册/parse/installing；
2. 主线程installing会触发 sw.js 中监听的 install 事件。使用Cache API来将资源缓存起来，同时使用e.waitUntil接收一个Promise来等待资源缓存成功，等到这个Promise状态成功后，ServiceWorker进入installed状态，意味着安装完毕；
3. 安装结束后当新的SW使用了self.skipWaiting()或者旧的的SW释放/过期了之后，主线程进入activating状态，sw线程触发到active事件。这个时候通常做一些缓存清理工作，当e.waitUntil接收的Promise进入成功状态后，ServiceWorker的生命周期则进入activated状态。注意：如果你的页面加载时没有 Service Worker，那么它当前加载过程中所依赖的其他资源请求也不会触发 fetch 事件。也就是说第一次加载不会触发 fetch 事件；
4. 到此一个ServiceWorker正式进入激活状态，可以拦截网络请求了。如果主线程有fetch方式请求资源，那么就可以在ServiceWorker代码中触发fetch事件；
5. 那么如果在install或者activ