pwa再理解
Progressive Web App, 简称 PWA，是提升 Web App 的体验的一种新方法，能给用户原生应用的体验。
PWA 能做到原生应用的体验不是靠特指某一项技术，而是经过应用一些新技术进行改进，在安全、性能和体验三个方面都有很大提升，PWA 本质上是 Web App，借助一些新技术也具备了 Native App 的一些特性，兼具 Web App 和 Native App 的优点。
PWA 的主要特点包括下面三点：
- 可靠 - 即使在不稳定的网络环境下，也能瞬间加载并展现
- 体验 - 快速响应，并且有平滑的动画响应用户的操作
- 粘性 - 像设备上的原生应用，具有沉浸式的用户体验，用户可以添加到桌面
Web Worker
一直以来，一个网页只会有两个线程：GUI 渲染线程和 JS 引擎线程。即便你的 JS 写得再天花乱坠，也只能在一个进程里面执行。然而，JS 引擎线程和 GUI 渲染线程是互斥的，因此在 JS 执行的时候，UI 页面会被阻塞住。为了在进行高耗时 JS 运算时，UI 页面仍可用，那么就得另外开辟一个独立的 JS 线程来运行这些高耗时的 JS 代码，这就是 Web Worker。
Web Worker 有两个特点：
只能服务于新建它的页面，不同页面之间不能共享同一个 Web Worker。
当页面关闭时，该页面新建的 Web Worker 也会随之关闭，不会常驻在浏览器中。
PS：还有一个相关的概念：Shared Worker，不过这个东西比较复杂，我并未深入研究，感兴趣的读者可以了解，也可以看看 Shared Worker 跟 Service Worker 的区别。
Service Worker
Service Worker 在 Web Worker 的基础上加上了持久离线缓存能力
Service Worker 有以下功能和特性：
- 一个独立的 worker 线程，独立于当前网页进程，有自己独立的 worker context。
- 一旦被 install，就永远存在，除非被手动 unregister
- 用到的时候可以直接唤醒，不用的时候自动睡眠
- 可编程拦截代理请求和返回，缓存文件，缓存的文件可以被网页进程取到（包括网络离线状态）
- 离线内容开发者可控
- 能向客户端推送消息
- 不能直接操作 DOM
- 必须在 HTTPS 环境下才能工作
- 异步实现，内部大都是通过 Promise 实现
Service Worker 出于安全性和其实现原理，在使用的时候有一定的前提条件
- 由于 Service Worker 要求 HTTPS 的环境，我们通常可以借助于 github page 进行学习调试。当然一般浏览器允许调试 Service Worker 的时候 - host 为 localhost 或者 127.0.0.1 也是 ok 的。
- Service Worker 的缓存机制是依赖 Cache API 实现的
- 依赖 HTML5 fetch API
- 依赖 Promise 实现
pwa缓存和http缓存
如果使用 Service Worker + CacheStorage + Fetch 做离线应用，该如何处理资源的更新呢？
当有任何的资源（HTML、JS、Image、甚至是 sw.js 本身）需要更新时，都需要改变 sw.js。因为有了 sw.js，整个应用的入口变成了 sw.js，而非原先的 HTML。每当用户访问页面时，不管你当前是不是命中了缓存，浏览器都会请求 sw.js，然后将新旧 sw.js 进行字节对比，如果不一样，说明需要更新。因此，你能看到在 Demo 中，我们有一个 VERSION 字段，它不仅代表 sw.js 本身的版本，更代表整个应用的版本。
不要试图通过改变 sw.js 的名字（如改成 sw_v2.js）来触发浏览器的更新，因为 HTML 本身会被 sw.js 缓存，而缓存的 HTML 中永远都指向 sw.js，导致浏览器无法得知 sw_v2.js 的更新。虽然，你可以像上面提到的文章：使用Service Worker做一个PWA离线网页应用 那样，再结合其他的手段来判断 HTML 的更新状态，但是会更加复杂，官方并不推荐。
每次 sw.js 的更新，都会根据 VERSION 字段新建一个缓存空间，然后把新的资源缓存在里面。等到旧的 sw.js 所控制的网页全部关闭之后，新的 sw.js 会被激活，然后 在 activate 事件中删除旧缓存空间。这样既能保证在同时打开多个网页时更新 sw.js 不出差错，也能及时删除冗余的缓存。
初次访问不会触发 fetch 事件
按照官方给的 Demo，Service Worker 注册的代码是放在 HTML 的最后。但是，当我尝试把 Service Worker 的注册代码提到最开头，并且 console 出时间戳，我发现一个现象：即便 Service Worker 注册成功之后再请求资源，这些资源也不会触发 fetch 请求，只有再次访问页面才会触发 fetch 事件。这是为什么呢？后来我在官方文档中找到了答案：如果你的页面加载时没有 Service Worker，那么它所依赖的其他资源请求也不会触发 fetch 事件。
来源：https://developers.google.com/web/fundamentals/primers/service-workers/lifecycle#activate
cache.add VS cache.put
在 install 事件中用 cache.addAll，在 fetch 事件中用 cache.put，add 和 put 有什么区别吗？→ cache.add = fetch + cache.put
The add() method of the Cache interface takes a URL, retrieves it, and adds the resulting response object to the given cache. The add() method is functionally equivalent to the following:
fetch(url).then(function(response) {
if (!response.ok) {
throw new TypeError('bad response status');
}
return cache.put(url, response);
})
出处：https://developer.mozilla.org/en-US/docs/Web/API/Cache/add\
event.waitUntil 和 event.respondWith
先说 event.waitUntil
只能在 Service Worker 的 install 或者 activate 事件中使用；
看起来像是一个 callback，但是，即便你不使用它，程序也可能正常运行。如果你传递了一个 Promise 给它，那么只有当该 Promise resolved 时，Service Worker 才会完成 install；如果 Promise rejected 掉，那么整个 Service Worker 便会被废弃掉。因此，cache.addAll 里面，只要有一个资源获取失败，整个 Service Worker 便会失效。
再说 event.respondWith
只能在 Service Worker 的 fetch 事件中使用；
作用相当于一个 callback，当传入的 Promise resolved 之后，才会将对应的 response 返回给浏览器。
总之，虽然 event.waitUntil 和 event.respondWith 中的 event 都是继承于 Event 类，但是它们与常见的 event 对象差异很大，这些方法也只有在 Service Worker 的那些对应的事件中才存在。
参考:
网友评论