[TOC] # Service Workers 丰富的离线体验、定期的后台同步以及推送通知等通常需要将面向本机应用的功能将引入到网络应用中。service worker提供了所有这些功能所依赖的技术基础。 <br> ## 什么是service worker service worker是浏览器在后台独立于网页运行的脚本，它打开了通向不需要网页或用户交互的功能的大门。现在，它们已包括如推送通知和后台同步等功能。将来，service worker将会支持如定期同步或地理围栏等其他功能。本教程讨论的核心功能是拦截和处理网络请求，包括通过程序来管理缓存中的响应。 这个 API 之所以令人兴奋，是因为它可以支持离线体验，让开发者能够全面控制这一体验。 在service worker出现前，存在能够在网络上为用户提供离线体验的另一个 API，称为 AppCache。App Cache 的主要问题是，它具有相当多的缺陷，并且，虽然它对单页网络应用支持较好，但对多页网站来说则不尽人意。service worker则能很好地避免这些常见的难点。 service worker相关注意事项： * 它是一种 [JavaScript 工作线程](https://www.html5rocks.com/en/tutorials/workers/basics/)，无法直接访问 DOM。 service worker通过响应 [`postMessage`](https://html.spec.whatwg.org/multipage/workers.html#dom-worker-postmessage) 接口发送的消息来与其控制的页面通信，页面可在必要时对 DOM 执行操作。 * service worker是一种可编程网络代理，让您能够控制页面所发送网络请求的处理方式。 * 它在不用时会被中止，并在下次有需要时重启，因此，您不能依赖于service worker的 `onfetch` 和 `onmessage` 处理程序中的全局状态。如果存在您需要持续保存并在重启后加以重用的信息，service worker可以访问 [IndexedDB API](https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API)。 * service worker广泛地利用了 `promise`，因此如果您不熟悉 `promise`，则应停下阅读此内容，看一看 Promise 简介。 <br> ## service worker生命周期 service worker的生命周期完全独立于网页。 要为网站安装service worker，您需要先在页面的 JavaScript 中注册。 注册service worker将会导致浏览器在后台启动服务工作线程安装步骤。 在安装过程中，您通常需要缓存某些静态资源。如果所有文件均已成功缓存，那么service worker就安装完毕。如果任何文件下载失败或缓存失败，那么安装步骤将会失败，service worker就无法激活（也就是说，不会安装）。 如果发生这种情况，不必担心，它下次会再试一次。 但这意味着，如果安装完成，您可以知道您已在缓存中获得那些静态资源。 安装之后，接下来就是激活步骤，这是管理旧缓存的绝佳机会，我们将在service worker的更新部分对此详加介绍。 激活之后，service worker将会对其作用域内的所有页面实施控制，不过，首次注册该service worker的页面需要再次加载才会受其控制。service worker实施控制后，它将处于以下两种状态之一：service worker终止以节省内存，或处理获取和消息事件，从页面发出网络请求或消息后将会出现后一种状态。 以下是service worker初始安装时的简化生命周期。  <br> ## 先决条件 ### 浏览器支持 可用的浏览器日益增多。service worker受 Firefox 和 Opera 支持。 Microsoft Edge 现在[表示公开支持](https://developer.microsoft.com/en-us/microsoft-edge/platform/status/serviceworker/)。甚至 Safari 也暗示未来会进行相关开发。 您可以在 Jake Archibald 的 [is Serviceworker ready](https://jakearchibald.github.io/isserviceworkerready/) 网站上查看所有浏览器的支持情况。 ### 您需要 HTTPS 在开发过程中，可以通过 localhost 使用service worker，但如果要在网站上部署服务工作线程，需要在服务器上设置 HTTPS。 使用service worker，您可以劫持连接、编撰以及过滤响应。 这是一个很强大的工具。您可能会善意地使用这些功能，但中间人可会将其用于不良目的。 为避免这种情况，可仅在通过 HTTPS 提供的页面上注册service worker，如此我们便知道浏览器接收的service worker在整个网络传输过程中都没有被篡改。 Github 页面 通过 HTTPS 提供，因此这些页面是托管演示的绝佳位置。 如果想要向服务器添加 HTTPS，您需要获得 TLS 证书并在服务器上进行设置。 具体因您的设置而异，因此请查看服务器的文档，并务必查阅 [Mozilla SSL 配置生成器](https://mozilla.github.io/server-side-tls/ssl-config-generator/)，了解最佳做法。 <br> ## 注册service worker 要安装service worker，您需要通过在页面中对其进行**注册**来启动安装。 这将告诉浏览器service worker JavaScript 文件的位置。 ~~~ if ('serviceWorker' in navigator) { window.addEventListener('load', function() { navigator.serviceWorker.register('/sw.js').then(function(registration) { // Registration was successful console.log('ServiceWorker registration successful with scope: ', registration.scope); }).catch(function(err) { // registration failed :( console.log('ServiceWorker registration failed: ', err); }); }); } ~~~ 此代码用于检查 Service Worker API 是否可用，如果可用，则在页面加载后注册位于 /sw.js 的服务工作线程。。 每次页面加载无误时，即可调用 **register()** 浏览器将会判断 service worker 是否已注册并做出相应的处理。 有一个需要特别说明的是service worker文件的路径，你一定注意到了在这个例子中，service worker文件被放在这个域的根目录下，这意味着service worker和网站同源。换句话说，这个service work将会收到这个域下的所有fetch事件。如果我将service worker文件注册为/example/sw.js，那么，service worker只能收到/example/路径下的fetch事件（例如： /example/page1/, /example/page2/）。 现在，您可以通过转至 chrome://inspect/#service-workers 并寻找您的网站来检查 service worker 是否已启用。  首次执行 service worker 时，您还可以通过 chrome://serviceworker-internals 来查看服务工作线程详情。 如果只是想了解 service worker 的生命周期，这仍很有用，但是日后其很有可能被 chrome://inspect/#service-workers 完全取代。 您会发现，它还可用于测试隐身窗口中的 service worker ，您可以关闭 service worker 并重新打开，因为之前的 service worker 不会影响新窗口。从隐身窗口创建的任何注册和缓存在该窗口关闭后均将被清除。 <br> ## Service Worker的安装步骤 在页面上完成注册步骤之后，让我们把注意力转到service worker的脚本里来，在这里面，我们要完成它的安装步骤。 在最基本的例子中，你需要为install事件定义一个callback，并决定哪些文件你想要缓存。 ~~~ self.addEventListener('install', function(event) { // Perform install steps }); ~~~ 在我们的install callback中，我们需要执行以下步骤： 1. 开启一个缓存 2. 缓存我们的文件 3. 决定是否所有的资源是否要被缓存 ~~~ var CACHE_NAME = 'my-site-cache-v1'; var urlsToCache = [ '/', '/styles/main.css', '/script/main.js' ]; self.addEventListener('install', function(event) { // Perform install steps event.waitUntil( caches.open(CACHE_NAME) .then(function(cache) { console.log('Opened cache'); return cache.addAll(urlsToCache); }) ); }); ~~~ 上面的代码中，我们通过 `caches.open` 打开我们指定的cache文件名，然后我们调用 `cache.addAll` 并传入我们的文件数组。这是通过一连串 promise（ `caches.open` 和 `cache.addAll` ）完成的。`event.waitUntil` 拿到一个 promise 并使用它来获得安装耗费的时间以及是否安装成功。 如果所有的文件都被缓存成功了，那么 service worker 就安装成功了。如果任何一个文件下载失败，那么安装步骤就会失败。这个方式允许你依赖于你自己指定的所有资源，但是这意味着你需要非常谨慎地决定哪些文件需要在安装步骤中被缓存。指定了太多的文件的话，就会增加安装失败率。 上面只是一个简单的例子，你可以在install事件中执行其他操作或者甚至忽略install事件。 <br> ## 缓存和返回Request 你已经安装了service worker，你现在可以返回你缓存的请求了。 当service worker被安装成功并且用户浏览了另一个页面或者刷新了当前的页面，service worker将开始接收到 fetch 事件。下面是一个例子： ~~~ self.addEventListener('fetch', function(event) { event.respondWith( caches.match(event.request) .then(function(response) { // Cache hit - return response if (response) { return response; } return fetch(event.request); } ) ); }); ~~~ 上面的代码里我们定义了 fetch 事件，在 `event.respondWith()` 里，我们传入了一个由 `caches.match` 产生的 `promise.caches.match` 查找 reques t中被 service worker 缓存命中的 response。 如果我们有一个命中的 response，我们返回被缓存的值，否则我们返回一个实时从网络请求fetch的结果。这是一个非常简单的例子，使用所有在 install 步骤下被缓存的资源。 如果我们想要增量地缓存新的请求，我们可以通过处理fetch请求的response并且添加它们到缓存中来实现，例如： ~~~ self.addEventListener('fetch', function(event) { event.respondWith( caches.match(event.request) .then(function(response) { // 缓存命中 - 返回响应 if (response) { return response; } // 重要：克隆请求。   // 请求是一个流，只能被使用一次。   // 由于我们通过缓存消耗了一次，而浏览器获取用了一次，我们需要克隆响应。 var fetchRequest = event.request.clone(); return fetch(fetchRequest).then( function(response) { // 检查是否收到有效的 response if(!response || response.status !== 200 || response.type !== 'basic') { return response; } // 重要提示：克隆响应。 // 响应是一个流，因为我们希望浏览器使用响应以及消耗响应的缓存，我们需要克隆它以便我们有两个流 var responseToCache = response.clone(); caches.open(CACHE_NAME) .then(function(cache) { cache.put(event.request, responseToCache); }); return response; } ); }) ); }); ~~~ 代码里我们所做事情包括： 1. 添加一个callback到fetch请求的 .then 方法中 1.1. 一旦我们获得了一个response，我们进行如下的检查： 1.2. 确保response是有效的 1.3. 检查response的状态是否是200 2. 保证response的类型是**basic**，这表示请求本身是同源的，非同源（即跨域）的请求也不能被缓存。 3. 如果我们通过了检查，clone这个请求。这么做的原因是如果response是一个Stream，那么它的body只能被读取一次，所以我们得将它克隆出来，一份发给浏览器，一份发给缓存。 <br> ## 更新一个Service Worker 你的service worker总有需要更新的那一天。当那一天到来的时候，你需要按照如下步骤来更新： 1. 更新你的service worker的JavaScript文件。当用户浏览你的网站，浏览器尝试在后台下载service worker的脚本文件。只要服务器上的文件和本地文件有一个字节不同，它们就被判定为需要更新。 2. 更新后的service worker将开始运作，install event被重新触发。 3. 在这个时间节点上，当前页面生效的依然是老版本的service worker，新的servicer worker将进入”waiting”状态。 4. 当前页面被关闭之后，老的service worker进程被杀死，新的servicer worker正式生效。 5. 一旦新的service worker生效，它的activate事件被触发。 代码更新后，通常需要在activate的callback中执行一个管理cache的操作。因为你会需要清除掉之前旧的数据。我们在activate而不是install的时候执行这个操作是因为如果我们在install的时候立马执行它，那么依然在运行的旧版本的数据就坏了。 之前我们只使用了一个缓存，叫做my-site-cache-v1，其实我们也可以使用多个缓存的，例如一个给页面使用，一个给blog的内容提交使用。这意味着，在install步骤里，我们可以创建两个缓存，pages-cache-v1和blog-posts-cache-v1，在activite步骤里，我们可以删除旧的my-site-cache-v1。 下面的代码能够循环所有的缓存，删除掉所有不在白名单中的缓存。 ~~~ self.addEventListener('activate', function(event) { var cacheWhitelist = ['pages-cache-v1', 'blog-posts-cache-v1']; event.waitUntil( caches.keys().then(function(cacheNames) { return Promise.all( cacheNames.map(function(cacheName) { if (cacheWhitelist.indexOf(cacheName) === -1) { return caches.delete(cacheName); } }) ); }) ); }); ~~~ <br> ## 处理边界和填坑 这一节内容比较新，有很多待定细节。希望这一节很快就不需要讲了，但是现在，这些内容还是应该被提一下。 ### 如果安装失败了，没有很优雅的方式获得通知 如果一个worker被注册了，但是没有出现在 chrome://inspect/#service-workers 或 chrome://serviceworker-internals ，那么很可能因为异常而安装失败了，或者是产生了一个被拒绝的的 promise 给 `event.waitUtil`。 要解决这类问题，首先到 chrome://serviceworker-internals检查。打开开发者工具窗口准备调试，然后在你的install event代码中添加debugger;语句。这样，通过断点调试你更容易找到问题。 ### fetch()的默认参数 **默认情况下没有凭据** 当你使用fetch，缺省地，请求不会带上cookies等凭据，要想带上的话，需要： ~~~ fetch(url, { credentials: 'include' }) ~~~ 这样设计是有理由的，它比XHR的在同源下默认发送凭据，但跨域时丢弃凭据的规则要来得好。fetch的行为更像其他的CORS请求，例如 `<img crossorigin>` ，它默认不发送 cookies，除非你指定了`<img crossorigin="use-credentials">.`。 ### Non-CORS默认不支持 默认情况下，从第三方URL跨域得到一个资源将会失败，除非对方支持了CORS。你可以添加一个non-CORS选项到Request去避免失败。代价是这么做会返回一个“不透明”的response，意味着你不能得知这个请求究竟是成功了还是失败了。 ~~~ cache.addAll(urlsToPrefetch.map(function(urlToPrefetch) { return new Request(urlToPrefetch, { mode: 'no-cors' }); })).then(function() { console.log('All resources have been fetched and cached.'); }); ~~~ ### 处理响应式图片 `img` 的 `srcset` 属性或者`<picture>`标签会根据情况从浏览器或者网络上选择最合适尺寸的图片。 在service worker中，你想要在install步骤缓存一个图片，你有以下几种选择： * 安装所有的`<picture>`元素或者将被请求的srcset属性。 * 安装单一的low-res版本图片 * 安装单一的high-res版本图片 比较好的方案是2或3，因为如果把所有的图片都给下载下来存着有点浪费内存。 假设你将low-res版本在install的时候缓存了，然后在页面加载的时候你想要尝试从网络上下载high-res的版本，但是如果high-res版本下载失败的话，就依然用low-res版本。这个想法很好也值得去做，但是有一个问题： | Screen Density | Width | Height | |---|---|---| | 1x | 400 | 400 | | 2x | 800 | 800 | 在srcset图像中，我们有一些像这样的标记： ~~~ <img src="image-src.png" srcset="image-src.png 1x, image-2x.png 2x" /> ~~~ 如果我们在一个2x的显示模式下，浏览器会下载image-2x.png，如果我们离线，你可以读取之前缓存并返回image-src.png替代，如果之前它已经被缓存过。尽管如此，由于现在的模式是2x，浏览器会把400X400的图片显示成200X200，要避免这个问题就要在图片的样式上设置宽高。 ~~~ <img src="image-src.png" srcset="image-src.png 1x, image-2x.png 2x" style="width:400px; height: 400px;" /> ~~~ `<picture>`标签情况更复杂一些，难度取决于你是如何创建和使用的，但是可以通过与srcset类似的思路去解决。 ## 参考资料 [Service Worker入门](http://web.jobbole.com/82247/) [Service Workers: an Introduction](https://developers.google.com/web/fundamentals/primers/service-workers/)