提问
https://github.com/GoogleChromeLabs/sw-precache 是什么?
https://github.com/GoogleChrome/workbox 又是什么?
web 前端的各位同学可能或多或少听过 pwa, 听过 service worker https://w3c.github.io/ServiceWorker/ (后面简称为 SW), 也知道对应的生命周期. 知道了这些 API 后, 你还是不知道如何将 pwa 技术投入生产. 它不仅仅是个玩具, 它是一个 "神器", 是用来拉近 native 和 Web App 之间的差距. 当我们做 spa 项目越做越大的时候, JS bundle 会越来越大, 单页面不能承载那么多的逻辑, 我们可能会选择多个单页面(也就是多页面). 每次加载都会存在空白加载的情景, 虽然性能优化上, 我们能把这个时间减少到很少很少, 但是没法完全把它 "干掉".pwa 的 service-worker 技术很好地弥补这片 "空白"."app-shell" 也就是 Web App 中的应用壳将会缓存在浏览器端, 让它的加载速度更加快速. 而可变的内容则是异步加载.
历史背景
有很多文章把 pwa 技术和小程序技术放在一起比较. 谷歌浏览器至于 pwa, 微信至于小程序, 都是给网页应用提供了离线缓存静态资源文件的功能, 动静分离, native 的接口, 这些都是给网页应用提供更优质的加载性能. 但是小程序并没有 BOM 和 DOM, 意味着它对浏览器有着更深入的改造, 它并非纯正意义上的网页应用, 是对所有 Web 开发资源的一种限制.
相反, pwa 则不一样.
安卓的支持
浏览器的兼容性
考虑到 service worker 是一个新的接口本身, 肯定会存在兼容性问题. PWA 的意思在于 Progressive, 也就是支持 pwa 的页面则使用 SW 的缓存机制, 而不支持的页面使用原来的 HTTP 缓存机制. 由于 pwa 是谷歌的 "亲儿子", 所以它在新版本安卓的各大浏览器都有非常好的支持. 详情我们可以参考 lavas 的兼容性报告 https://lavas.baidu.com/ready/browser?lang=zh
重点的重点当然是微信浏览器对 pwa 的支持情况, 我们可以看到除了推送信息和支付接口之外基本已经实现支持(支付接口的支持应该是出于安全的考虑, 以及和 weixin-JS-sdk 重叠的原因, X5 浏览器支持它只是时间的问题). 如今我们更关心的是关于 SW-cache 这一部分, 换句话说, 我们可以放心在安卓微信上使用 SW-cache 的技术.
安卓微信浏览器的支持情况
iOS(苹果)的支持
《震惊! 苹果向开发者低头?!! 开始支持 Service Worker https://zhuanlan.zhihu.com/p/28293894 》一文中讲述了苹果的开发工程师开始完成研发, 并且在 2017 年底 Safari 桌面技术预览版上已经实现了 service worker 的相关 API, 从 In development 的状态转移到 Supported In Preview, 这意味着 service worker 极有可能在 IOS12 得到支持(详情 https://webkit.org/status ), 这也就意味着 pwa 的时代很快就会到来.
苹果 Safari 已开始支持 service worker
sw-precache 和 workbox
我们知道 vue-cli 打造出来的 pwa 模版, 使用的是 https://github.com/GoogleChromeLabs/sw-precache , 而 https://github.com/GoogleChrome/workbox 是它的取代品. 它们各自有一个 webpack 版的插件, 分别是和.
结合 Vue 笔记八: 多页面打包框架的多页面打包框架, 我添加上 precache 的功能(以后计划替换成为 workbox), 实现多页面的 service worker 框架, GitHub 的地址是 https://github.com/brandonxiang/mpa-pwa
我写了一个关于 workbox 在 vue-webpack 框架的脚手架, GitHub 的地址是, 大家可以参考一下.
它们之间的区别如下, 可以说非常相似:
中文说明 | workbox | 中文说明 | sw-precache |
---|---|---|---|
缓存的目录 | globDirectory | 缓存前缀 | stripPrefix |
缓存的静态文件类型 | globPatterns | 缓存的静态文件类型 | staticFileGlobs |
sw 文件路径 | swDest | sw 文件名 | filename |
让 sw 立即接管网页 | clientsClaim | (相同) | clientsClaim |
激活的等待 | skipWaiting | (相同) | skipWaiting |
动态请求 | runtimeCaching | (相同) | runtimeCaching |
sw-precache 的主要开发者 https://github.com/jeffposnick 也是 workbox 的主要开发者, 这说明了它们之间的关系, sw-precache 是为了满足 service worker 的 cache API 中的静态资源文件的注册作用. 而 workbox 是为了满足所有 pwa 的资源内容, 可以看作一个 "平台".
workbox package
workbox 中已经支持很多方面的内容, 当然, 还有很多内容有待开发.
缓存机制
Service Worker https://w3c.github.io/ServiceWorker/ 的出现很大程度, 改变了 Web App 的格局, HTTP cache 和 SW cache 有着天壤之别. 这样的 HTTP 缓存机制没法弥补网页跳转带来的白屏间隙, SW cache 由于优先缓存静态资源以及接口的机制, 大大减少了网络状况差 (甚至断网) 带来的白屏现象. 优先更新本地的同时, service worker 会和后端进行一次通信, 这次通信会告知静态资源是否被更改, 在下次刷新的时候更改内容.
动态接口方面则会采用 runtimeCaching 进行交互, 这部分也会进行动态内容的缓存, https://github.com/GoogleChromeLabs/sw-toolbox 的代码将会被引入你的 sw.JS 中, 它会利用正则表达式匹配到你请求的接口, 进行接口缓存, 当该接口出现内容变化时, SW 会和后端进行一次通讯保证下一次加载的数据是最新数据, 这样的更新机制分为 5 个类型.
- networkFirst
- cacheFirst
- fastest
- cacheOnly
- networkOnly
networkFirst 是显示完成后, SW 优先和后端通讯, 看接口是否更新, 下一次刷新则是采用最新数据内容. cacheFirst 则是优先考虑缓存, 如果缓存没有命中, 才会去请求接口拿新数据, 这个选型适合那种不经常更改的内容或者有别的更新机制. fastest 则是两个同时进行, 哪个快执行哪个. cacheOnly 和 networkOnly 比较不常用.
安全性
如何利用 / 防御 Service Worker http://mp.weixin.qq.com/s/_izQ1OeDONI8D4LPiPpVOQ
来源: http://www.jianshu.com/p/e91705b1a8ca