当下PWA比较火，而Service Worker是实现PWA的一项关键技术，今天我们一起了解下关于Service Worker的一些基础知识和适用场景。

什么是Server Worker

我们先来看一下官方文档中对于Server Worker的核心定义：

Service workers 本质上充当Web应用程序与浏览器之间的代理服务器，也可以在网络可用时作为浏览器和网络间的代理。

这是一条很准确的定义，但对于不了解Service Worker的同学来说可能并不形象，下面我们更形象的理解一下这个概念。我们以去银行取钱为例子，其过程大概如下图：

从上面的图中我们可以看到，银行的钱存在金库中，客户取钱时并不是直接去金库里拿，而是需要通过银行的工作人员，再告知银行工作人员需要多少钱，并出示相应凭证后，由银行工作人员从金库中拿出钱给客户，并从账户中减去相应金额。这么做的原因很容易理解，因为金库是公用的，所有客户的钱都放在里面，我们无法保证每个客户都能只拿走属于自己的钱，并按照实际情况更新金库记录。

我们的应用在请求服务器资源时，其过程也是类似的：

从上面的图可以看到，请求资源的过程中，HTTP协议充当了取钱过程中的银行工作人员，客户端应用需要的资源在服务器上，但应用却无法直接去服务器获取资源，而是通过HTTP协议进行，请求中指定的各种Header信息，就是取钱时的凭证。

而Service Worker可以理解成，在客户端创建了一个属于自己的金库，先看图：

当我们需要取钱或者获取资源时，可以先从本地的金库中拿，本地金库没有，再通过原来的流程获取。这时我们再回头看文章开始的定义，应该就能够理解了。

Service Worker与Cache的关系

正常情况下，客户端获取一个资源的过程有如下三步：

而关于请求资源的优化，一般也集中在这三步完成：

不发出请求就能够获得资源；
提高服务器查找资源的速度；
减小返回内容的体积；

看完上面的部分我们可以发现，当使用Service Worker中已有的资源时，客户端应用获取资源并没有进入HTTP请求的流程，也就是说，通过Service Worker，客户端应用可以在不发出请求的情况下获得资源，这很容易就让我们想到缓存，那么Service Worker和我们平时经常提到的强缓存和协商缓存等是什么关系呢？整理了一个图，可以先看下：

从整体上来说，应用获取一个资源的缓存类型分为上图中的四种，分别是Service Worker、Memory Cache、Disk Cache和No Cache。资源查找顺序为从左向右，找到资源则返回，未找到则继续寻找，直至最终获取资源。上面的图中可以清楚的看出Service Worker在缓存类型中的位置，也能看到跟平时经常提到的强缓存和协商缓存的关系。

Service Worker使用逻辑

在了解了Service Worker的概念后，我们看下Servise Worker的基本使用逻辑，使用它的基础过程是首先注册一个Woker，这时浏览器会在后台启动一个新的线程，在这个线程启动后，会按照Service Worker中的代码逻辑将一些资源缓存下来，缓存完毕后，启动对页面请求的监听，当监听到页面请求资源时可以做出相对应的响应，比如如果资源在Service Worker中缓存过了，就可以直接返回资源。

注册

Service Worker对象保存在window.navigator内，首先调用register方法进行注册，导入一个js文件，文件中是我们的Service Worker逻辑，代码如下：

navigator.serviceWorker.register('/sw.js')
.then(function(reg){
    console.log("success", reg);
}).catch(function(err) {
    console.log("error", err);
});

需要注意的是Service Worker是有作用域的，它的作用域为文件的当前路径，Service Worker文件只能管理自己作用下的资源，比如abcde.com/home/sw.js 的作用域为abcde.com/home/。

激活

注册后的Service Worker就能在调试工具中看到了，下面是一个chrome调试面板的截图：

画红框的内容是一些比较关键的信息，比如其中表明了Service Worker的文件名和路径，以及当前Service Worker的状态，Service Worker的状态分为几种，STOPPED（已停止）、STARTING（正在启动）、RUNNING（正在运行）和STOPPING（正在停止），比如上面的截图就处于RUNNING状态。

只有处于running状态的Service Worker才能生效，这就需要对注册后的Service Worker进行加载和激活，注册完毕后，Service Worker会自动开始下载，下载后会触发install事件，我们可以监听这个事件并进行下载资源的操作，代码如下：

const CACHE_NAME = "demo-a";
this.addEventListener("install", function(event) {
    console.log("install service worker success");
    caches.open(CACHE_NAME);
    let cacheResources = ["https://abcde.com/demo.js"];
    event.waitUntil(
        caches.open(CACHE_NAME).then(cache => {
            cache.addAll(cacheResources);
        })
    );
});

经过上面的代码，demo.js文件就被我们缓存下来了，下载完后Service Worker就会执行激活：

this.addEventListener("active", function(event) {
    console.log("service worker active success");
});

此时我们通过开发者工具就能看到一个激活的Service Worker了，整体梳理一下大概是下面的过程：

需要注意的是，图中灰色的部分是一个独立的特殊线程，并不是浏览器渲染页面执行js的线程，因此使用Service Worker的过程中无需担心会影响页面的渲染。

更新

我们注册了Service Worker后，还面临着更新的问题，当我们的业务迭代时必然要更新Service Worker，在我们理解了它的整个注册过程后，理解更新就很简单了，直接上图：

当应用加载时，会下载Service Worker文件，这是在浏览器中就会有两个文件，一个是当前正在使用的Service Worker，一个是新下载的Service Worker，当新下载的文件下载完毕后，浏览器会对两个文件进行Diff操作，如果发现文件没有更新，则会丢弃掉新下载的Service Worker文件，如果发现有变化，则会加载新的Service Worker，但新加载的Service Worker会处于wating状态，并不会实际发挥作用，只有当整个浏览器中对正在运行的Service Worker没有依赖时，才会将运行中的Service Worker抛弃，将新的Servier Worker置为激活状态。

常见使用场景

用于浏览器缓存，提高加载速度；
实现离线应用，最近PWA如此火爆；
实现消息的主动推送，为web应用增加一种给力的交互方式；

兼容性

我们了解一些Service Worker的基础知识，以及一些比较常见的使用场景，那么目前Service Worker的兼容性如何呢，看下图

目前主流的现代浏览器支持度还是不错的，但是到目前为止全系列的IE浏览器均不支持Service Worker，而且有一点感受很明显，在查资料的过程中，看了网上不少的博客，不同的博客上也有当时写博客时的Service Worker支持度，可以明显感觉到Service Worker的支持程度在快速提升，随着支持度的提升，相信会有越来越多的开发者在项目中使用这项技术。

借助Service Worker，真正让PWA应用变得流行，也许就在不久的将来。