Service Worker
当下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应用变得流行,也许就在不久的将来。