永利402游戏网站

Service Worker入门

来源:http://www.xtcsyb.com 作者:永利402游戏网站-永利402com官方网站 时间:2019-10-04 21:01

Service Worker入门

2015/03/26 · JavaScript · Service Worker

原稿出处: Matt Gaunt   译文出处:[w3ctech

  • 十年踪迹]()   

原生App具有Web应用普通所不富有的富离线体验,定期的沉默更新,音信文告推送等职能。而新的Serviceworkers标准让在Web App上装有那些效应成为恐怕。

Service Worker初体验

2016/01/06 · JavaScript · Service Worker

原稿出处: AlloyTeam   

在2015年,W3C发布了service worker的草案,service worker提供了相当多新的力量,使得web app具有与native app一样的离线体验、音讯推送体验。
service worker是一段脚本,与web worker同样,也是在后台运转。作为三个单身的线程,运转条件与日常脚本差别,所以不可能直接参加web交互行为。native app能够成功离线使用、消息推送、后台自动更新,service worker的产出是幸而为了使得web app也得以享有类似的力量。

 

service worker可以:

  1. 后台音讯传递
  2. 互联网代理,转载呼吁,伪造响应
  3. 离线缓存
  4. 音讯推送
  5.  … …

正文以财富缓存为例,说惠氏下service worker是何许做事的。

Service Worker 是什么?

三个 service worker 是一段运行在浏览器后台进程里的台本,它独立于当下页面,提供了那个无需与web页面交互的效应在网页背后悄悄试行的力量。在今日,基于它可以完结消息推送,静默更新以及地理围栏等劳动,不过当前它首先要持有的法力是阻碍和拍卖网络央浼,富含可编制程序的响应缓存管理。

怎么说这一个API是贰个极其棒的API呢?因为它使得开拓者能够支持非常好的离线体验,它赋予开拓者完全调节离线数据的本领。

在service worker提出在此以前,其余贰个提供开辟者离线体验的API叫做App Cache。不过App Cache有个别局限性,举例它能够很轻便地消除单页应用的难题,然而在多页应用上会很辛勤,而Serviceworkers的出现正是为了消除App Cache的痛点。

下边详细说一下service worker有何样需求静心的地点:

  • 它是JavaScript Worker,所以它无法直接操作DOM。不过service worker能够透过postMessage与页面之间通讯,把音信文告给页面,借使供给的话,让页面本人去操作DOM。
  • Serviceworker是三个可编程的网络代理,允许开垦者调整页面上拍卖的互联网必要。
  • 在不被接纳的时候,它会本身终止,而当它再度被用到的时候,会被重复激活,所以您无法借助于service worker的onfecth和onmessage的管理函数中的全局状态。如果你想要保存一些长久化的音信,你能够在service worker里使用IndexedDB API。
  • Serviceworker多量使用promise,所以只要您不驾驭哪些是promise,那你要求先读书这篇文章。

生命周期

先来看一下三个service worker的运维周期

图片 1
上海教室是service worker生命周期,出处

图中得以观察,一个service worker要经历以下进程:

  1.  安装

2.  激活,激活成功以往,展开chrome://inspect/#service-workers能够查阅到当下运作的service worker

图片 2

  1. 监听fetch和message事件,下边三种事件会开展简易描述

  2. 销毁,是还是不是销毁由浏览器决定,假设三个service worker长时间不利用大概机器内部存款和储蓄器有数,则只怕会销毁这几个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初次安装的生命周期:

图片 3

fetch事件

在页面发起http恳求时,service worker能够通过fetch事件拦截央求,而且付诸自身的响应。
w3c提供了贰个新的fetch api,用于替代XMLHttpRequest,与XMLHttpRequest最大分歧有两点:

1. fetch()方法再次回到的是Promise对象,通过then方法开展接二连三调用,降低嵌套。ES6的Promise在成为标准未来,会越发便利开荒人士。

2. 提供了Request、Response对象,如若做过后端开荒,对Request、Response应该相比较纯熟。前端要提倡呼吁能够经过url发起,也得以利用Request对象发起,何况Request能够复用。可是Response用在哪儿啊?在service worker出现从前,前端确实不会和煦给和睦发新闻,可是有了service worker,就足以在阻止央浼之后依照须要发回自身的响应,对页面来讲,那几个普通的乞请结果并不曾不一样,这是Response的一处选用。

上边是在中,作者采纳fetch api通过fliker的公开api获取图片的事例,注释中详尽分解了每一步的效果:

JavaScript

/* 由于是get乞求,直接把参数作为query string传递了 */ var URL = ''; function fetchDemo() { // fetch(url, option)扶助多少个参数,option中能够安装header、body、method音讯fetch(UWranglerL).then(function(response) { // 通过promise 对象获得相应内容,而且将响应内容依据json格式转成对象,json()方法调用之后回来的依旧是promise对象 // 也足以把内容转化成arraybuffer、blob对象 return response.json(); }).then(function(json) { // 渲染页面 insertPhotos(json); }); } fetch德姆o();

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
/* 由于是get请求,直接把参数作为query string传递了 */
var URL = 'https://api.flickr.com/services/rest/?method=flickr.photos.search&api_key=your_api_key&format=json&nojsoncallback=1&tags=penguins';
 
function fetchDemo() {
  // fetch(url, option)支持两个参数,option中可以设置header、body、method信息
  fetch(URL).then(function(response) {
    // 通过promise 对象获得相应内容,并且将响应内容按照json格式转成对象,json()方法调用之后返回的依然是promise对象
    // 也可以把内容转化成arraybuffer、blob对象
    return response.json();
  }).then(function(json) {
    // 渲染页面
    insertPhotos(json);
  });
}
 
fetchDemo();

fetch api与XMLHttpRequest相比较,尤其简明,而且提供的功用更全面,能源获取情势比ajax更温婉。包容性方面:chrome 42上马援助,对于旧浏览器,能够通过法定维护的polyfill帮助。

在大家伊始写码在此之前

从这个品种地址拿到chaches polyfill。

这个polyfill支持CacheStorate.match,Cache.add和Cache.addAll,而现在Chrome M40实现的Cache API还尚未协理那个主意。

将dist/serviceworker-cache-polyfill.js放到你的网址中,在service worker中通过importScripts加载进来。被service worker加载的台本文件会被电动缓存。

JavaScript

importScripts('serviceworker-cache-polyfill.js');

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打探最棒施行。

message事件

页面和serviceWorker之间可以通过posetMessage()方法发送新闻,发送的音信能够透过message事件接收到。

那是多少个双向的经过,页面能够发消息给service worker,service worker也足以发送信息给页面,由于这么些特点,能够将service worker作为中间纽带,使得二个域名依旧子域名下的几个页面能够随便通讯。

此处是三个小的页面之间通讯demo

使用Service Worker

今昔我们有了polyfill,况且消除了HTTPS,让我们看看毕竟怎么用service worker。

使用service workder缓存文件

上面介绍一个运用service worker缓存离线文件的事例
预加防卫index.js,用于注册service-worker

JavaScript

if (navigator.serviceWorker) { navigator.serviceWorker.register('service-worker.js').then(function(registration) { console.log('service worker 注册成功'); }).catch(function (err) { console.log('servcie worker 注册战败') }); }

1
2
3
4
5
6
7
if (navigator.serviceWorker) {
    navigator.serviceWorker.register('service-worker.js').then(function(registration) {
        console.log('service worker 注册成功');
    }).catch(function (err) {
        console.log('servcie worker 注册失败')
    });
}

在上述代码中,注册了service-worker.js作为当前路径下的service worker。由于service worker的权杖异常高,全部的代码都急需是安全可相信的,所以只有https站点才方可采取service worker,当然localhost是二个特例。
注册停止,未来始发写service-worker.js代码。
基于前面包车型大巴生命周期图,在贰个新的service worker被注册之后,首先会触发install事件,在service-workder.js中,能够经过监听install事件进展一些初始化职业,也许如何也不做。
因为大家是要缓存离线文件,所以能够在install事件中初露缓存,但是只是将文件加到caches缓存中,真正想让浏览器选拔缓存文件要求在fetch事件中截留

JavaScript

var cacheFiles = [ 'about.js', 'blog.js' ]; self.addEventListener('install', function (evt) { evt.waitUntil( caches.open('my-test-cahce-v1').then(function (cache) { return cache.addAll(cacheFiles); }) ); });

1
2
3
4
5
6
7
8
9
10
11
var cacheFiles = [
    'about.js',
    'blog.js'
];
self.addEventListener('install', function (evt) {
    evt.waitUntil(
        caches.open('my-test-cahce-v1').then(function (cache) {
            return cache.addAll(cacheFiles);
        })
    );
});

率先定义了特需缓存的文书数组cacheFile,然后在install事件中,缓存这几个文件。
evt是贰个Install伊夫nt对象,继承自ExtendableEvent,在那之中的waitUntil()方法接收一个promise对象,直到这么些promise对象成功resolve之后,才会继续运转service-worker.js。
caches是三个CacheStorage对象,使用open()方法展开一个缓存,缓存通过名称进行区分。
得到cache实例之后,调用addAll()方法缓存文件。

那样就将文件增加到caches缓存中了,想让浏览器选用缓存,还索要拦截fetch事件

JavaScript

// 缓存图片 self.addEventListener('fetch', function (evt) { evt.respondWith( caches.match(evt.request).then(function(response) { if (response) { return response; } var request = evt.request.clone(); return fetch(request).then(function (response) { if (!response && response.status !== 200 && !response.headers.get('Content-type').match(/image/)) { return response; } var responseClone = response.clone(); caches.open('my-test-cache-v1').then(function (cache) { cache.put(evt.request, responseClone); }); return response; }); }) ) });

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// 缓存图片
self.addEventListener('fetch', function (evt) {
    evt.respondWith(
        caches.match(evt.request).then(function(response) {
            if (response) {
                return response;
            }
            var request = evt.request.clone();
            return fetch(request).then(function (response) {
                if (!response && response.status !== 200 && !response.headers.get('Content-type').match(/image/)) {
                    return response;
                }
                var responseClone = response.clone();
                caches.open('my-test-cache-v1').then(function (cache) {
                    cache.put(evt.request, responseClone);
                });
                return response;
            });
        })
    )
});

通过监听fetch事件,service worker能够再次回到自身的响应。

首先检缓存中是或不是曾经缓存了这几个诉求,如若有,就直接重回响应,就收缩了一次互联网央浼。否则由service workder发起须要,那时的service workder起到了贰当中级代理的效劳。

service worker央浼的进度通过fetch api落成,获得response对象今后举办过滤,查看是不是是图片文件,假如不是,就一贯再次来到恳求,不会缓存。

假诺是图片,要先复制一份response,原因是request或然response对象属于stream,只好动用三次,之后一份存入缓存,另一份发送给页面。
那便是service worker的强硬之处:拦截央浼,伪造响应。fetch api在此处也起到了一点都不小的效应。

 

service worker的更新不会细小略,只要service-worker.js的文件内容有立异,就能够利用新的台本。可是有好几要小心:旧缓存文件的解除、新文件的缓存要在activate事件中张开,因为大概旧的页面还在运用在此以前的缓存文件,清除之后会失掉成效。

 

在初次使用service worker的进度中,也遇上了部分主题素材,上面是内部八个

何以注册和安装service worker

要安装service worker,你须求在您的页面上注册它。那些手续告诉浏览器你的service worker脚本在哪个地方。

JavaScript

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); }); }

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是否对你的网站启用了。

图片 4

当service worker第一版被达成的时候,你也得以在chrome://serviceworker-internals中查看,它很有用,通过它可以最直观地熟悉service worker的生命周期,不过这个功能很快就会被移到chrome://inspect/#service-workers中。

您会发觉那一个作用可以很有利地在多个仿照窗口中测量试验你的service worker,那样你能够关闭和再度展开它,而不会潜濡默化到您的新窗口。任何成立在模仿窗口中的注册服务和缓存在窗口被关门时都将化为乌有。

难题1. 运作时刻

service worker并非间接在后台运维的。在页面关闭后,浏览器能够持续保证service worker运营,也足以关闭service worker,那决计于与浏览器本人的表现。所以不用定义一些全局变量,举例上边包车型大巴代码(来自):

JavaScript

var hitCounter = 0; this.addEventListener('fetch', function(event) { hitCounter++; event.respondWith( new Response('Hit number ' + hitCounter) ); });

1
2
3
4
5
6
7
8
var hitCounter = 0;
 
this.addEventListener('fetch', function(event) {
  hitCounter++;
  event.respondWith(
    new Response('Hit number ' + hitCounter)
  );
});

回来的结果大概是从未规律的:1,2,1,2,1,1,2….,原因是hitCounter并从未一向留存,假若浏览器关闭了它,后一次开发银行的时候hitCounter就赋值为0了
这般的事情导致调节和测量试验代码困难,当你更新二个service worker未来,唯有在开荒新页面现在才或许应用新的service worker,在调解进程中时时等上一两分钟才会动用新的,相比较抓狂。

Service Worker的安装步骤

在页面上产生登记手续之后,让我们把集中力转到service worker的本子里来,个中,大家要实现它的安装步骤。

在最中央的例子中,你供给为install事件定义贰个callback,并垄断哪些文件你想要缓存。

JavaScript

// 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 });

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. 操纵是不是具有的能源是或不是要被缓存

JavaScript

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); }) ); });

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事件。

标题2. 权力太大

当service worker监听fetch事件随后,对应的哀告都会因而service worker。通过chrome的network工具,能够见到此类诉求会标明:from service worker。如若service worker中冒出了难点,会招致全数央浼失败,满含日常的html文件。所以service worker的代码品质、容错性一定要很好技术担保web app寻常运作。

 

参照他事他说加以考察小说:

1. 

2. 

3. 

4. 

5. 

1 赞 3 收藏 评论

图片 5

怎么缓存和再次回到Request

您早已设置了service worker,你未来能够重返您缓存的乞请了。

当service worker被安装成功还要客户浏览了另一个页面只怕刷新了日前的页面,service worker将初叶接受到fetch事件。上边是二个事例:

JavaScript

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); } ) ); });

1
2
3
4
5
6
7
8
9
10
11
12
13
14
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 查找request中被service worker缓存命中的response。

假使大家有二个命中的response,大家回去被缓存的值,不然大家回去多少个实时从互连网乞求fetch的结果。那是三个特别轻巧的例子,使用全体在install步骤下被缓存的财富。

万一大家想要增量地缓存新的央浼,大家能够透过拍卖fetch要求的response並且拉长它们到缓存中来落到实处,举例:

JavaScript

self.addEventListener('fetch', function(event) { event.respondWith( caches.match(event.request) .then(function(response) { // Cache hit - return response if (response) { return response; } // IMPORTANT: Clone the request. A request is a stream and // can only be consumed once. Since we are consuming this // once by cache and once by the browser for fetch, we need // to clone the response var fetchRequest = event.request.clone(); return fetch(fetchRequest).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 2 stream. var responseToCache = response.clone(); caches.open(CACHE_NAME) .then(function(cache) { cache.put(event.request, responseToCache); }); return response; } ); }) ); });

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
self.addEventListener('fetch', function(event) {
  event.respondWith(
    caches.match(event.request)
      .then(function(response) {
        // Cache hit - return response
        if (response) {
          return response;
        }
 
        // IMPORTANT: Clone the request. A request is a stream and
        // can only be consumed once. Since we are consuming this
        // once by cache and once by the browser for fetch, we need
        // to clone the response
        var fetchRequest = event.request.clone();
 
        return fetch(fetchRequest).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 2 stream.
            var responseToCache = response.clone();
 
            caches.open(CACHE_NAME)
              .then(function(cache) {
                cache.put(event.request, responseToCache);
              });
 
            return response;
          }
        );
      })
    );
});

代码里大家所做作业富含:

  1. 累加叁个callback到fetch乞请的 .then 方法中
  2. 借使大家得到了一个response,大家实行如下的检讨:
    1. 担保response是有效的
    2. 检查response的状态是还是不是是200
    3. 担保response的体系是basic,那意味着央求笔者是同源的,非同源(即跨域)的需要也不可能被缓存。
  3. 要是大家由此了自己谈论,clone其一必要。这么做的原因是一旦response是贰个Stream,那么它的body只可以被读取三次,所以大家得将它克隆出来,一份发给浏览器,一份发给缓存。

哪些翻新多个Service Worker

您的service worker总有亟待革新的那一天。当那一天来到的时候,你须要遵守如下步骤来更新:

  1. 立异您的service worker的JavaScript文件
    1. 当顾客浏览你的网址,浏览器尝试在后台下载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。

上边包车型客车代码能够循环全部的缓存,删除掉全数不在白名单中的缓存。

JavaScript

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); } }) ); }) ); });

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
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);
          }
        })
      );
    })
  );
});

拍卖边界和填坑

这一节内容相比新,有好多待定细节。希望这一节不慢就无需讲了(因为标准会管理那一个难题——译者注),不过今后,这一个剧情依旧应该被提一下。

假设设置战败了,未有异常高雅的主意获得通报

假使三个worker被注册了,不过并未有出现在chrome://inspect/#service-workers或chrome://serviceworker-internals,那么很可能因为异常而安装失败了,或者是产生了一个被拒绝的的promise给event.waitUtil。

要消除那类难点,首先到 chrome://serviceworker-internals检查。打开开发者工具窗口准备调试,然后在你的install event代码中添加debugger;语句。这样,通过断点调试你更容易找到问题。

fetch()近日仅支持Service Workers

fetch立时支持在页面上使用了,不过近年来的Chrome实现,它还只扶助service worker。cache API也快要在页面上被支持,可是如今结束,cache也还只可以在service worker中用。

fetch()的暗中同意参数

当你利用fetch,缺省级地区级,哀告不会带上cookies等凭证,要想带上的话,必要:

JavaScript

fetch(url, { credentials: 'include' })

1
2
3
fetch(url, {
  credentials: 'include'
})

如此那般设计是有理由的,它比XH陆风X8的在同源下暗中同意发送凭据,但跨域时甩掉凭据的条条框框要来得好。fetch的行为更像别的的CO库罗德S伏乞,例如<img crossorigin>,它默认不发送cookies,除非你指定了<img crossorigin="use-credentials">.。

Non-COEnclaveS暗中同意不援救

暗中同意意况下,从第三方U福睿斯L跨域获得三个财富将会退步,除非对方援助了CO福睿斯S。你能够增进一个non-COPRADOS选项到Request去防止退步。代价是如此做会回到叁个“不透明”的response,意味着你不可能得知那几个必要终究是打响了依旧败诉了。

JavaScript

cache.addAll(urlsToPrefetch.map(function(urlToPrefetch) { return new Request(urlToPrefetch, { mode: 'no-cors' }); })).then(function() { console.log('All resources have been fetched and cached.'); });

1
2
3
4
5
cache.addAll(urlsToPrefetch.map(function(urlToPrefetch) {
  return new Request(urlToPrefetch, { mode: 'no-cors' });
})).then(function() {
  console.log('All resources have been fetched and cached.');
});

fetch()不遵照30x重定向典型

不幸,重定向在fetch()中不会被触发,那是近期版本的bug;

拍卖响应式图片

img的srcset属性或许<picture>标签会根据情况从浏览器或者网络上选择最合适尺寸的图片。

在service worker中,你想要在install步骤缓存八个图形,你有以下两种选拔:

  1. 安装具备的<picture>元素或者将被请求的srcset属性。
  2. 设置单一的low-res版本图片
  3. 安装单一的high-res版本图片

正如好的方案是2或3,因为一旦把持有的图片都给下载下来存着有一点点浪费内部存款和储蓄器。

要是你将low-res版本在install的时候缓存了,然后在页面加载的时候你想要尝试从互联网上下载high-res的本子,可是只要high-res版本下载退步以来,就如故用low-res版本。这么些主张很好也值得去做,可是有三个难点:

只要大家有上面二种图片:

Screen Density Width Height
1x 400 400
2x 800 800

HTML代码如下:

JavaScript

<img src="image-src.png" srcset="image-src.png 1x, image-2x.png 2x" />

1
<img src="image-src.png" srcset="image-src.png 1x, image-2x.png 2x" />

如若大家在三个2x的来得情势下,浏览器会下载image-2x.png,要是大家离线,你能够读取以前缓存并重临image-src.png取代,假若此前它已经被缓存过。纵然如此,由于明天的方式是2x,浏览器会把400X400的图片展现成200X200,要幸免这些主题素材即就要图纸的样式上安装宽高。

JavaScript

<img src="image-src.png" srcset="image-src.png 1x, image-2x.png 2x" style="width:400px; height: 400px;" />

1
2
<img src="image-src.png" srcset="image-src.png 1x, image-2x.png 2x"
style="width:400px; height: 400px;" />

图片 6

<picture>标签情况更复杂一些,难度取决于你是如何创建和使用的,但是可以通过与srcset类似的思路去解决。

改变URL Hash的Bug

在M40版本中设有一个bug,它会让页面在更改hash的时候产生service worker结束职业。

你能够在那边找到越多相关的新闻: 

更加多内容

那边有局地有关的文书档案能够参谋:

获得扶持

一旦您遇见麻烦,请在Stackoverflow上发帖询问,使用‘service-worker’标签,以便于大家霎时跟进和尽或然支持你消除难题。

赞 2 收藏 评论

图片 7

本文由永利402游戏网站-永利402com官方网站发布于永利402游戏网站,转载请注明出处:Service Worker入门

关键词:

上一篇:渐进式Web应用(PWA)入门教程(下)

下一篇:没有了