——evilrescuer翻译自Matt Gaunt
写的[Service Workers: an Introduction]（收录于 谷歌开发者）(https://developers.google.com/web/fundamentals/primers/service-workers/)
一、缓存并返回请求
现在你已经安装了一个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。这个方法从任何你的service worker缓存的文件中查找结果。
如果我们有一个匹配上的response，就返回缓存的值，否则就返回调用fetch的结果，也就是发起网络请求，并返回收到的数据。
如果我们想累积缓存一个新的请求，可以处理fetch请求的response并把这个response加入缓存，就像下面这样：
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).then(
function(response) {
// Check if we received a valid response
if(!response || response.status !== 200 || response.type !== 'basic') {
return response;
}
// IMPORTANT: Clone the response. A response is a stream
// and because we want the browser to consume the response
// as well as the cache consuming the response, we need
// to clone it so we have two streams.
var responseToCache = response.clone();
caches.open(CACHE_NAME)
.then(function(cache) {
cache.put(event.request, responseToCache);
});
return response;
}
);
})
);
});
我们做了这些：
- 在
fetch请求上，给.then()增加一个 callback - 一旦我们收到一个响应, 我们做这些检查:
- 确认响应是合法的.
- 检查状态是
200. - 确认响应类型是 basic（说明是从我们的源发起的请求），也就是不缓存第三方文件发起的请求的响应.
- 如果通过测试，我们 克隆 一个响应。因为响应是一个 流，响应体只会被消耗一次。因为我们需要给浏览器返回响应，并且缓存起来以便将来使用, 所以我们需要克隆一下，一个用来发给浏览器，一个用来缓存起来。
二、更新一个service worker
有时你的service worker需要更新，此时你需要：
- 更新你的 service worker JavaScript 文件. 当用户来到你的网页，浏览器尝试重新下载这个JavaScript 文件。这个文件有任何改变，哪怕是一个字节，都会被认为是新的.
- 你的新 service worker 将会启动，install的事件会被触发.
- 旧的service worker还在控制当前页面，所以新的service worker会进入一个等待的状态。
- 当前打开的页面如果被关闭，旧的 service worker会被销毁，新的开始控制。
- 一旦新的service worker得到控制权，它的activate事件会被触发.
我们常常在activate的callback中处理缓存管理。注意：如果你在安装步骤清掉旧缓存，那些仍然有控制权的旧service worker，会立即停止那个缓存文件的工作，所以在这里做比较好。
比如说，我们有一个缓存叫 'my-site-cache-v1'，我们希望把这个缓存分割成两个，一个给页面用，一个给博客文章用。那在install(安装)步骤，我们创建两个缓存：'pages-cache-v1' 和 'blog-posts-cache-v1' ，然后在activate(激活)步骤，我们删掉我们的旧缓存'my-site-cache-v1'。
下面的代码会循环查看 service worker 的缓存，删掉那些不在白名单上的缓存。
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);
}
})
);
})
);
});
三、粗糙的边缘和陷阱
server worker是个新玩意儿。这里提一些问题，希望可以尽早被解决，但是现在还是需要注意一下。
1.安装失败的信息无法告知
如果你注册了一个service worker，但是没在chrome://inspect/#service-workers or chrome://serviceworker-internals中出现，那可能是因为抛出错误，或者一个可被传输到event.waitUntil()的rejected promise错误
为了解决这个问题，前往 chrome://serviceworker-internals 并打开谷歌开发工具，对安装事件进行调试。 以及配合这篇文章提到的： 《调试未捕获的异常》。
2.fetch的默认情况
2.1 没有credentials凭据
当你使用fetch时，默认情况下，请求是不带credentials凭据的（比如cookies），如果你需要凭据，可以这样使用：
fetch(url, {
credentials: 'include'
})
对于同源的URL来说，我们特意这么设置后, 会比 XHR复杂一些。fetch行为和其他的CORS 请求一样, 比如 <img crossorigin>, 如果你不设置<img crossorigin="use-credentials">，它是不会发cookies的。
2.2 非CORS默认安装失败
By default, fetching a resource from a third party URL will fail if it doesn't support CORS. You can add a no-CORS option to the Request to overcome this, although this will cause an 'opaque' response, which means you won't be able to tell if the response was successful or not.
默认情况下，由于没有CORS，从第三方URL获取一个资源会失败。你可以加上一个no-CORS，尽管这会导致一些不透明的响应，因为你不知道响应是否成功。做法如下：
cache.addAll(urlsToPrefetch.map(function(urlToPrefetch) {
return new Request(urlToPrefetch, { mode: 'no-cors' });
})).then(function() {
console.log('All resources have been fetched and cached.');
});
译者注：如果你不了解no-CORS，请查看 request模式-MDN
2.3 处理响应式图像
对于service worker来说，如果你想在安装步骤缓存一张图片，你有几种选择：
- 安装所有可能用到的图片
- 缓存低分辨率版本图片
- 缓存高分辨率版本图片
实际上你应该选择选项2或3，因为下载所有图像会浪费存储空间。
假设您在安装时选择低分辨率版本，并且您希望在加载页面时尝试从网络中检索更高分辨率的图像，但如果高分辨率图像失败，则回退到低分辨率版本。这看起来很好，但有一个问题。
比如我们有下面两张图片：
Screen Density Width Height
1x 400 400
2x 800 800
我们可能这么使用：
<img src="image-src.png" srcset="image-src.png 1x, image-2x.png 2x" />
如果我们在2x的显示器上，浏览器会去下载 image-2x.png，如果离线了，你可以用.catch() 缓存，并返回 image-src.png(如果已经缓存上的话)。
但是浏览器会期望图像考虑到2x屏幕上的额外像素，因此图像将显示为200x200 CSS像素而不是400x400 CSS像素。唯一的方法是在图像上设置固定的高度和宽度。
四、学习更多
这里有一系列关于 service worker 的文档： https://jakearchibald.github.io/isserviceworkerready/resources ，可能对你有用。
（完）
