原生App拥有Web应用通常所不具备的富离线体验，定时的静默更新，消息通知推送等功能。而新的Service workers标准让在Web App上拥有这些功能成为可能。
Service Worker 是什么？
一个 service worker 是一段运行在浏览器后台进程里的脚本，它独立于当前页面，提供了那些不需要与web页面交互的功能在网页背后悄悄执行的能力。在将来，基于它可以实现消息推送，静默更新以及地理围栏等服务，但是目前它首先要具备的功能是拦截和处理网络请求，包括可编程的响应缓存管理。
为什么说这个API是一个非常棒的API呢？因为它使得开发者可以支持非常好的离线体验，它给予开发者完全控制离线数据的能力。
在service worker提出之前，另外一个提供开发者离线体验的API叫做App Cache。然而App Cache有些局限性，例如它可以很容易地解决单页应用的问题，但是在多页应用上会很麻烦，而Service workers的出现正是为了解决App Cache的痛点。
下面详细说一下service worker有哪些需要注意的地方：
- 它是JavaScript Worker，所以它不能直接操作DOM。但是service worker可以通过postMessage与页面之间通信，把消息通知给页面，如果需要的话，让页面自己去操作DOM。
- Service worker是一个可编程的网络代理，允许开发者控制页面上处理的网络请求。
- 在不被使用的时候，它会自己终止，而当它再次被用到的时候，会被重新激活，所以你不能依赖于service worker的onfecth和onmessage的处理函数中的全局状态。如果你想要保存一些持久化的信息，你可以在service worker里使用IndexedDB API。
- Service worker大量使用promise，所以如果你不了解什么是promise，那你需要先阅读这篇文章。
Service Worker的生命周期
Service worker拥有一个完全独立于Web页面的生命周期。
要让一个service worker在你的网站上生效，你需要先在你的网页中注册它。注册一个service worker之后，浏览器会在后台默默启动一个service worker的安装过程。
在安装过程中，浏览器会加载并缓存一些静态资源。如果所有的文件被缓存成功，service worker就安装成功了。如果有任何文件加载或缓存失败，那么安装过程就会失败，service worker就不能被激活（也即没能安装成功）。如果发生这样的问题，别担心，它会在下次再尝试安装。
当安装完成后，service worker的下一步是激活，在这一阶段，你还可以升级一个service worker的版本，具体内容我们会在后面讲到。
在激活之后，service worker将接管所有在自己管辖域范围内的页面，但是如果一个页面是刚刚注册了service worker，那么它这一次不会被接管，到下一次加载页面的时候，service worker才会生效。
当service worker接管了页面之后，它可能有两种状态：要么被终止以节省内存，要么会处理fetch和message事件，这两个事件分别产生于一个网络请求出现或者页面上发送了一个消息。
下图是一个简化了的service worker初次安装的生命周期：
在我们开始写码之前
从这个项目地址拿到chaches polyfill。
这个polyfill支持CacheStorate.match，Cache.add和Cache.addAll，而现在Chrome M40实现的Cache API还没有支持这些方法。
将dist/serviceworker-cache-polyfill.js放到你的网站中，在service worker中通过importScripts加载进来。被service worker加载的脚本文件会被自动缓存。
|
1 |
importScripts('serviceworker-cache-polyfill.js'); |
需要HTTPS
在开发阶段，你可以通过localhost使用service worker，但是一旦上线，就需要你的server支持HTTPS。
你可以通过service worker劫持连接，伪造和过滤响应，非常逆天。即使你可以约束自己不干坏事，也会有人想干坏事。所以为了防止别人使坏，你只能在HTTPS的网页上注册service workers，这样我们才可以防止加载service worker的时候不被坏人篡改。（因为service worker权限很大，所以要防止它本身被坏人篡改利用——译者注）
Github Pages正好是HTTPS的，所以它是一个理想的天然实验田。
如果你想要让你的server支持HTTPS，你需要为你的server获得一个TLS证书。不同的server安装方法不同，阅读帮助文档并通过Mozilla’s SSL config generator了解最佳实践。
使用Service Worker
现在我们有了polyfill，并且搞定了HTTPS，让我们看看究竟怎么用service worker。
如何注册和安装service worker
要安装service worker，你需要在你的页面上注册它。这个步骤告诉浏览器你的service worker脚本在哪里。
|
1 2 3 4 5 6 7 8 9 |
if ('serviceWorker' in navigator) { 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是否可用，如果可用，service worker /sw.js 被注册。
如果这个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的脚本里来，在这里面，我们要完成它的安装步骤。
在最基本的例子中，你需要为install事件定义一个callback，并决定哪些文件你想要缓存。
|
1 2 3 4 5 6 7 8 9 10 11 |
// The files we want to cache var urlsToCache = [ '/', '/styles/main.css', '/script/main.js' ]; // Set the callback for the install step self.addEventListener('install', function(event) { // Perform install steps }); |
在我们的install callback中，我们需要执行以下步骤：
- 开启一个缓存
- 缓存我们的文件
- 决定是否所有的资源是否要被缓存
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
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事件。
怎样缓存和返回Request
你已经安装了service worker，你现在可以返回你缓存的请求了。
当service worker被安装成功并且用户浏览了另一个页面或者刷新了当前的页面，service worker将开始接收到fetch事件。下面是一个例子：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
self.addEventListener('fetch',e"> self.addEventListener('fetch',ܟ
一个 service worker 是一段运行在浏览器后台进程里的脚本，它独立于当前页面，提供了那些不需要与web页面交互的功能在网页背后悄悄执行的能力。在将来，基于它可以实现消息推送，静默更新以及地理围栏等服务，但是目前它首先要具备的功能是拦截和处理网络请求，包括可编程的响应缓存管理。 为什么说这个API是一个非常棒的API呢？因为它使得开发者可以支持非常好的离线体验，它给予开发者完全控制离线数据的能力。 在service worker提出之前，另外一个提供开发者离线体验的API叫做App Cache。然而App Cache有些局限性，例如它可以很容易地解决单页应用的问题，但是在多页应用上会很麻烦，而Service workers的出现正是为了解决App Cache的痛点。 下面详细说一下service worker有哪些需要注意的地方：
Service Worker的生命周期Service worker拥有一个完全独立于Web页面的生命周期。 要让一个service worker在你的网站上生效，你需要先在你的网页中注册它。注册一个service worker之后，浏览器会在后台默默启动一个service worker的安装过程。 在安装过程中，浏览器会加载并缓存一些静态资源。如果所有的文件被缓存成功，service worker就安装成功了。如果有任何文件加载或缓存失败，那么安装过程就会失败，service worker就不能被激活（也即没能安装成功）。如果发生这样的问题，别担心，它会在下次再尝试安装。 当安装完成后，service worker的下一步是激活，在这一阶段，你还可以升级一个service worker的版本，具体内容我们会在后面讲到。 在激活之后，service worker将接管所有在自己管辖域范围内的页面，但是如果一个页面是刚刚注册了service worker，那么它这一次不会被接管，到下一次加载页面的时候，service worker才会生效。 当service worker接管了页面之后，它可能有两种状态：要么被终止以节省内存，要么会处理fetch和message事件，这两个事件分别产生于一个网络请求出现或者页面上发送了一个消息。 下图是一个简化了的service worker初次安装的生命周期：
在我们开始写码之前从这个项目地址拿到chaches polyfill。 这个polyfill支持CacheStorate.match，Cache.add和Cache.addAll，而现在Chrome M40实现的Cache API还没有支持这些方法。 将dist/serviceworker-cache-polyfill.js放到你的网站中，在service worker中通过importScripts加载进来。被service worker加载的脚本文件会被自动缓存。
需要HTTPS 在开发阶段，你可以通过localhost使用service worker，但是一旦上线，就需要你的server支持HTTPS。 你可以通过service worker劫持连接，伪造和过滤响应，非常逆天。即使你可以约束自己不干坏事，也会有人想干坏事。所以为了防止别人使坏，你只能在HTTPS的网页上注册service workers，这样我们才可以防止加载service worker的时候不被坏人篡改。（因为service worker权限很大，所以要防止它本身被坏人篡改利用——译者注） Github Pages正好是HTTPS的，所以它是一个理想的天然实验田。 如果你想要让你的server支持HTTPS，你需要为你的server获得一个TLS证书。不同的server安装方法不同，阅读帮助文档并通过Mozilla’s SSL config generator了解最佳实践。 使用Service Worker现在我们有了polyfill，并且搞定了HTTPS，让我们看看究竟怎么用service worker。 如何注册和安装service worker要安装service worker，你需要在你的页面上注册它。这个步骤告诉浏览器你的service worker脚本在哪里。
上面的代码检查service worker API是否可用，如果可用，service worker 如果这个service worker已经被注册过，浏览器会自动忽略上面的代码。 有一个需要特别说明的是service worker文件的路径，你一定注意到了在这个例子中，service worker文件被放在这个域的根目录下，这意味着service worker和网站同源。换句话说，这个service work将会收到这个域下的所有fetch事件。如果我将service worker文件注册为 现在你可以到
当service worker第一版被实现的时候，你也可以在 你会发现这个功能能够很方便地在一个模拟窗口中测试你的service worker，这样你可以关闭和重新打开它，而不会影响到你的新窗口。任何创建在模拟窗口中的注册服务和缓存在窗口被关闭时都将消失。 Service Worker的安装步骤在页面上完成注册步骤之后，让我们把注意力转到service worker的脚本里来，在这里面，我们要完成它的安装步骤。 在最基本的例子中，你需要为install事件定义一个callback，并决定哪些文件你想要缓存。
在我们的install callback中，我们需要执行以下步骤：
上面的代码中，我们通过caches.open打开我们指定的cache文件名，然后我们调用cache.addAll并传入我们的文件数组。这是通过一连串promise（caches.open 和 cache.addAll）完成的。event.waitUntil拿到一个promise并使用它来获得安装耗费的时间以及是否安装成功。 如果所有的文件都被缓存成功了，那么service worker就安装成功了。如果任何一个文件下载失败，那么安装步骤就会失败。这个方式允许你依赖于你自己指定的所有资源，但是这意味着你需要非常谨慎地决定哪些文件需要在安装步骤中被缓存。指定了太多的文件的话，就会增加安装失败率。 上面只是一个简单的例子，你可以在install事件中执行其他操作或者甚至忽略install事件。 怎样缓存和返回Request你已经安装了service worker，你现在可以返回你缓存的请求了。 当service worker被安装成功并且用户浏览了另一个页面或者刷新了当前的页面，service worker将开始接收到fetch事件。下面是一个例子： |
