Service Worker：让你的 Web 应用牛逼起来

前言

本文首先会简单介绍下前端的常见缓存方式，再引入serviceworker的概念，针对其原理和如何运用进行介绍。然后基于google推出的第三方库workbox，在产品中进行运用实践，并对其原理进行简要剖析。

前端缓存简介

先简单介绍一下现有的前端缓存技术方案，主要分为http缓存和浏览器缓存。

http缓存

http缓存都是第二次请求时开始的，这也是个老生常谈的话题了。无非也是那几个http头的问题：

Expires

HTTP1.0的内容，服务器使用Expires头来告诉Web客户端它可以使用当前副本，直到指定的时间为止。

Cache-Control

HTTP1.1引入了Cathe-Control，它使用max-age指定资源被缓存多久，主要是解决了Expires一个重大的缺陷，就是它设置的是一个固定的时间点，客户端时间和服务端时间可能有误差。

所以一般会把两个头都带上，这种缓存称为强缓存，表现形式为：

Last-Modified / If-Modified-Since

Last-Modified是服务器告诉浏览器该资源的最后修改时间，If-Modified-Since是请求头带上的，上次服务器给自己的该资源的最后修改时间。然后服务器拿去对比。

若资源的最后修改时间大于If-Modified-Since，说明资源又被改动过，则响应整片资源内容，返回状态码200；

若资源的最后修改时间小于或等于If-Modified-Since，说明资源无新修改，则响应HTTP 304，告知浏览器继续使用当前版本。

Etag / If-None-Match

前面提到由文件的修改时间来判断文件是否改动，还是会带来一定的误差，比如注释等无关紧要的修改等。所以推出了新的方式。

Etag是由服务端特定算法生成的该文件的唯一标识，而请求头把返回的Etag值通过If-None-Match再带给服务端，服务端通过比对从而决定是否响应新内容。这也是304缓存。

浏览器缓存

storage

简单的缓存方式有cookie，localStorage和sessionStorage。这里就不详细介绍他们的区别了，这里说下通过localStorage来缓存静态资源的优化方案。

localStorage通常有5MB的存储空间，我们以微信文章页为例。

查看请求发现，基本没有js和css的请求，因为它把全部的不需要改动的资源都放到了localStorage中：

所以微信的文章页加载非常的快。

前端数据库

前端数据库有WebSql和IndexDB，其中WebSql被规范废弃，他们都有大约50MB的最大容量，可以理解为localStorage的加强版。

应用缓存

应用缓存主要是通过manifest文件来注册被缓存的静态资源，已经被废弃，因为他的设计有些不合理的地方，他在缓存静态文件的同时，也会默认缓存html文件。这导致页面的更新只能通过manifest文件中的版本号来决定。所以，应用缓存只适合那种常年不变化的静态网站。如此的不方便，也是被废弃的重要原因。

PWA也运用了该文件，不同于manifest简单的将文件通过是否缓存进行分类，PWA用manifest构建了自己的APP骨架，并运用Servie Worker来控制缓存，这也是今天的主角。

Service Worker

Service Worker本质上也是浏览器缓存资源用的，只不过他不仅仅是cache，也是通过worker的方式来进一步优化。

他基于h5的web worker，所以绝对不会阻碍当前js线程的执行，sw最重要的工作原理就是

1、后台线程：独立于当前网页线程；

2、网络代理：在网页发起请求时代理，来缓存文件；

兼容性

可以看到，基本上新版浏览器还是兼容滴。之前是只有chrome和firefox支持，现在微软和苹果也相继支持了。

成熟程度

判断一个技术是否值得尝试，肯定要考虑下它的成熟程度，否则过一段时间又和应用缓存一样被规范抛弃就尴尬了。

所以这里我列举了几个使用Service Worker的页面：

淘宝

网易新闻

考拉

所以说还是可以尝试下的。

调试方法

一个网站是否启用Service Worker，可以通过开发者工具中的Application来查看：

被Service Worker缓存的文件，可以在Network中看到Size项为 from ServiceWorker：

也可以在Application的Cache Storage中查看缓存的具体内容：

如果是具体的断点调试，需要使用对应的线程，不再是main线程了，这也是webworker的通用调试方法：

使用条件

sw 是基于 HTTPS 的，因为service worker中涉及到请求拦截，所以必须使用HTTPS协议来保障安全。如果是本地调试的话，localhost是可以的。

而我们刚好全站强制https化，所以正好可以使用。

生命周期

大概可以用如下图片来解释：

注册

要使用Service worker，首先需要注册一个sw，通知浏览器为该页面分配一块内存，然后sw就会进入安装阶段。

一个简单的注册方式：

(function() { if(‘serviceWorker’in navigator) { navigator.serviceWorker.register(’./sw.js’);}})()

当然也可以考虑全面点，参考网易新闻的注册方式：

“serviceWorker"innavigator &&window.addEventListener(“load”,function(){vare = location.pathname.match(//news/[a-z]{1,}//)[0] +“article-sw.js?v=08494f887a520e6455fa”; navigator.serviceWorker.register(e).then(function(n){ n.onupdatefound =function(){vare = n.installing; e.onstatechange =function(){switch(e.state) {case"installed”: navigator.serviceWorker.controller ?console.log(“New or updated content is available.”) :console.log(“Content is now available offline!”);break;case"redundant":console.error(“The installing service worker became redundant.”) } } } }).catch(function(e){console.error(“Error during service worker registration:”, e) }) })

前面提到过，由于sw会监听和代理所有的请求，所以sw的作用域就显得额外的重要了，比如说我们只想监听我们专题页的所有请求，就在注册时指定路径：

navigator.serviceWorker.register(’/topics/sw.js’);

这样就只会对topics/下面的路径进行优化。

installing

我们注册后，浏览器就会开始安装sw，可以通过事件监听：

//service worker安装成功后开始缓存所需的资源varCACHE_PREFIX =‘cms-sw-cache’;varCACHE_VERSION =‘0.0.20’;varCACHE_NAME = CACHE_PREFIX+’-’+CACHE_VERSION;varallAssets = [’./main.css’];self.addEventListener(‘install’,function(event){//调试时跳过等待过程self.skipWaiting();// Perform install steps//首先 event.waitUntil 你可以理解为 new Promise，//它接受的实际参数只能是一个 promise，因为,caches 和 cache.addAll 返回的都是 Promise，//这里就是一个串行的异步加载，当所有加载都成功时，那么 SW 就可以下一步。//另外，event.waitUntil 还有另外一个重要好处，它可以用来延长一个事件作用的时间，//这里特别针对于我们 SW 来说，比如我们使用 caches.open 是用来打开指定的缓存，但开启的时候，//并不是一下就能调用成功，也有可能有一定延迟，由于系统会随时睡眠 SW，所以，为了防止执行中断，//就需要使用 event.waitUntil 进行捕获。另外，event.waitUntil 会监听所有的异步 promise/