江苏龙网

  1. 主页 > 生活百科 > >

Service Worker与缓存

Service Work

前言随着Service Worker（以下简称SW）的普及和规范，我们可以使用SW提供的缓存接口替代HTTP缓存 。当然SW的功能是强大的，除了缓存功能，还能够使用它来实现离线、数据同步、后台编译等等 。

Service Worker与缓存

文章插图
 
应用一个标配版的sw缓存工代代码应该有以下的片段：
const version = '2';self.addEventListener('install', event => { event.waitUntil( caches.open(`static-${version}`) .then(cache => cache.addAll([ '/styles.css', '/script.js' ])) );});self.addEventListener('fetch', event => { event.respondWith( caches.match(event.request) .then(response => response || fetch(event.request)) );});首先你要明白的前提是，网络请求首先到达的是SW脚本中，如果未命中再转发给HTTP缓存 。
这段代码的意思是，在SW的install阶段我们将script.js和styles.css放入缓存中；而在请求发起的fetch阶段，通过资源的URL去缓存内查找匹配，成功后立刻返回，否则走正常的网络请求流程 。
但你有没有考虑过，在install阶段的资源内容是哪里来的？仍然是从HTTP缓存中 。这样SW缓存机制又有可能随着HTTP缓存陷入了之前所说的版本不一致的困境中 。
既然我们借助SW重写了缓存机制，所以也不想再受牵制于旧的HTTP缓存 。解决办法是让SW中的请求必须向服务端验证：
self.addEventListener('install', event => { event.waitUntil( caches.open(`static-${version}`) .then(cache => cache.addAll([ new Request('/styles.css', { cache: 'no-cache' }), new Request('/script.js', { cache: 'no-cache' }) ])) );});目前并非所有的浏览器都支持cache选项的配置 。但这个不是太大问题，我们可以通过添加随机数来保证每次请求的URL都不相同，间接的使得缓存失效：
self.addEventListener('install', event => { event.waitUntil( caches.open(`static-${version}`) .then(cache => Promise.all( [ '/styles.css', '/script.js' ].map(url => { // cache-bust using a random query string return fetch(`${url}?${Math.random()}`).then(response => { // fail on 404, 500 etc if (!response.ok) throw Error('Not ok'); return cache.put(url, response); }) }) )) );});上面的代码使用的是随机数作为文件版本，你当然可以使用更精确的方式，例如根据文件内容生成md5值来作为版本信息，而这个思维模式就是模块sw-precache模块的背后哲学 。
sw-precache
想象一下现在我们需要实施上述绕过http缓存的解决方案 。首先我们需要知道究竟站点中有多少静态资源，然后设定版本号的生成规则，接着根据静态资源再具体的编写我们的SW脚本 。
不难看出，上面描述的过程可以是机械化自动化的，包括识别静态资源，生成SW脚本等 。而类库sw-precache则可以帮我们完成这些工作 。尤其是在构建阶段配合Gulp或者Grunt使用，具体用法我们可以摘录它官网的一段DEMO：
gulp.task('generate-service-worker', function(callback) { var swPrecache = require('sw-precache'); var rootDir = 'App'; swPrecache.write(`${rootDir}/service-worker.js`, { staticFileGlobs: [rootDir + '/**/*.{js,html,css,png,jpg,gif,svg,eot,ttf,woff}'], stripPrefix: rootDir }, callback);});这段脚本注册了一个名为generate-service-worker的任务，用于在根目录生成一个名为service-worker.js的sw脚本，而这个脚本缓存的资源呢，则是目录下的所有脚本、样式、图片、字体等几乎所有的静态文件 。
浏览器的整体缓存机制除了HTTP标准缓存以外，浏览器还有可能存在标准以外的缓存机制 。对于Chrome浏览器而言还存在Memory Cache、Push “Cache” 。一个请求在查找资源的过程中经过的缓存顺序是Memory Cache、Service Worker、HTTP Cache、Push “Cache” 。HTTP Cache和Service Worker已经介绍过了，接下来简单介绍Memory Cache和Push Cache
Memory Cache
“内存缓存”中主要包含的是当前文档中页面中已经抓取到的资源 。例如页面上已经下载的样式、脚本、图片等 。我们不排除页面可能会对这些资源再次发出请求，所以这些资源都暂存在内存中，当用户结束浏览网页并且关闭网页时，内存缓存的资源会被释放掉 。
这其中最重要的缓存资源其实是preloader相关指令（例如<link rel="prefetch">）下载的资源 。总所周知preloader的相关指令已经是页面优化的常见手段之一，而通过这些指令下载的资源也都会暂存到内存中 。根据一些材料，如果资源已经存在于缓存中，则可能不会再进行preload 。
需要注意的事情是，内存缓存在缓存资源时并不关心返回资源的HTTP缓存头Cache-Control是什么值，同时资源的匹配也并非仅仅是对URL做匹配，还可能会对Content-Type，CORS等其他特征做校验


推荐阅读


上一篇：大红袍口感特征大红袍的特点

下一篇：Docker命令行入门大全：这18条，你不得不知