Service Worker初体验

Service Worker入门

2015/03/26 · JavaScript
· Service Worker

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

  • 十年踪迹]()   

原生App拥有Web应用通常所不具备的富离线体验,定时的静默更新,消息通知推送等功能。而新的Service
workers标准让在Web App上拥有这些功能成为可能。

连不上网?英国卫报的个性离线页面是这样做的

2015/11/20 · HTML5 · Service
Worker,
离线页面

本文由 伯乐在线 –
Erucy
翻译,weavewillg
校稿。未经许可,禁止转载!
英文出处:Oliver
Ash。欢迎加入翻译组。

我们是如何使用 service worker 来为 theguardian.com
构建一个自定义的离线页面。

图片 1

theguardian.com 的离线页面。插图:Oliver Ash

你正在通往公司路上的地铁里,在手机上打开了
Guardian
应用。地铁被隧道包围着,不过这个应用可以如常运行,即使没有网络连接,你也能获得完整的功能,除了显示的内容可能有点旧。如果你尝试在网站上也这么干,可惜它完全没法加载:

图片 2

安卓版 Chrome 的离线页面

Chrome 中的这个彩蛋,很多人都不知道》

Chrome
在离线页面上有个隐藏的游戏(桌面版上按空格键,手机版上点击那只恐龙),这多少能减轻一点你的烦躁。不过我们可以做得更好。

Service
workers
允许网站作者拦截自己站点的所有网络请求,这也就意味着我们可以提供完善的离线体验,就像原生应用一样。在
Guardian
网站,我们最近上线了一个自定义的离线体验功能。当用户离线的时候,他们会看到一个带有
Guardian
标识的页面,上面带有一个简短的离线提示,还有一个填字游戏,他们可以在等待网络连接的时候玩玩这个找点乐子。这篇博客解释了我们是如何构建它的,不过在开始之前,你可以先自己试试看。

使用 Service Worker 做一个 PWA 离线网页应用

2017/10/09 · JavaScript
· PWA, Service
Worker

原文出处:
人人网FED博客   

在上一篇《我是怎样让网站用上HTML5
Manifest》介绍了怎么用Manifest做一个离线网页应用,结果被广大网友吐槽说这个东西已经被deprecated,移出web标准了,现在被Service
Worker替代了,不管怎么样,Manifest的一些思想还是可以借用的。笔者又将网站升级到了Service
Worker,如果是用Chrome等浏览器就用Service
Worker做离线缓存,如果是Safari浏览器就还是用Manifest,读者可以打开这个网站感受一下,断网也是能正常打开。

Service Worker初体验

2016/01/06 · JavaScript
· Service Worker

原文出处: AlloyTeam   

在2014年,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是如何工作的。

渐进式Web应用(PWA)入门教程(下)

2018/05/25 · 基础技术 ·
PWA

原文出处: Craig
Buckler   译文出处:葡萄城控件   

上篇文章我们对渐进式Web应用(PWA)做了一些基本的介绍。

渐进式Web应用(PWA)入门教程(上)

在这一节中,我们将介绍PWA的原理是什么,它是如何开始工作的。

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 和 fetch
API 的浏览器。截止到本文编写时只有
Chrome(手机版和桌面版)同时支持这两种 API(译者注:Opera
目前也支持这两者),不过 Firefox
很快就要支持了(在每日更新的版本中已经支持了),除了 Safari
之外的所有浏览器也都在跃跃欲试。此外,service worker 只能注册在使用了
HTTPS 的网站上,theguardian.com
已经开始逐步迁移到 HTTPS,所以我们只能在网站的 HTTPS
部分提供离线体验。就目前来说,我们选择了 开发者博客 作为我们用来测试的地方。所以如果你是在我们网站的 开发者博客 部分阅读这篇文章的话,很走运。

当你使用支持的浏览器访问我们的 开发者博客 中的页面的时候,一切就准备妥当了。断开你的网络连接,然后刷新一下页面。如果你自己没条件尝试的话,可以看一下这段 演示视频(译者注:需梯子)。

1. 什么是Service Worker

Service Worker是谷歌发起的实现PWA(Progressive Web
App)的一个关键角色,PWA是为了解决传统Web APP的缺点:

(1)没有桌面入口

(2)无法离线使用

(3)没有Push推送

那Service Worker的具体表现是怎么样的呢?如下图所示:

图片 3

Service
Worker是在后台启动的一条服务Worker线程,上图我开了两个标签页,所以显示了两个Client,但是不管开多少个页面都只有一个Worker在负责管理。这个Worker的工作是把一些资源缓存起来,然后拦截页面的请求,先看下缓存库里有没有,如果有的话就从缓存里取,响应200,反之没有的话就走正常的请求。具体来说,Service
Worker结合Web App Manifest能完成以下工作(这也是PWA的检测标准):

图片 4

包括能够离线使用、断网时返回200、能提示用户把网站添加一个图标到桌面上等。

生命周期

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

图片 5
上图是service
worker生命周期,出处

图中可以看到,一个service worker要经历以下过程:

  1.  安装

2.
 激活,激活成功之后,打开chrome://inspect/#service-workers可以查看到当前运行的service
worker

图片 6

  1. 监听fetch和message事件,下面两种事件会进行简要描述

  2. 销毁,是否销毁由浏览器决定,如果一个service
    worker长期不使用或者机器内存有限,则可能会销毁这个worker

第一步:使用HTTPS

渐进式Web应用程序需要使用HTTPS连接。虽然使用HTTPS会让您服务器的开销变多,但使用HTTPS可以让您的网站变得更安全,HTTPS网站在Google上的排名也会更靠前。

由于Chrome浏览器会默认将localhost以及127.x.x.x地址视为测试地址,所以在本示例中您并不需要开启HTTPS。另外,出于调试目的,您可以在启动Chrome浏览器的时候使用以下参数来关闭其对网站HTTPS的检查:

  • –user-data-dir
  • –unsafety-treat-insecure-origin-as-secure

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初次安装的生命周期:

图片 7

工作原理

通过一段简单的
JavaScript,我们可以指示浏览器在用户访问页面的时候立即注册我们自己的
service worker。目前支持 service worker
的浏览器很少,所以为了避免错误,我们需要使用特性检测。

JavaScript

if (navigator.serviceWorker) {
navigator.serviceWorker.register(‘/service-worker.js’); }

1
2
3
if (navigator.serviceWorker) {
    navigator.serviceWorker.register(‘/service-worker.js’);
}

Service worker
安装事件的一部分,我们可以使用 新的缓存
API 来缓存我们网站中的各种内容,比如
HTML、CSS 和
JavaScript:

JavaScript

var staticCacheName = ‘static’; var version = 1; function updateCache()
{ return caches.open(staticCacheName + version) .then(function (cache) {
return cache.addAll([ ‘/offline-page.html’, ‘/assets/css/main.css’,
‘/assets/js/main.js’ ]); }); }; self.addEventListener(‘install’,
function (event) { event.waitUntil(updateCache()); });

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
var staticCacheName = ‘static’;
var version = 1;
 
function updateCache() {
    return caches.open(staticCacheName + version)
        .then(function (cache) {
            return cache.addAll([
                ‘/offline-page.html’,
                ‘/assets/css/main.css’,
                ‘/assets/js/main.js’
            ]);
        });
};
 
self.addEventListener(‘install’, function (event) {
    event.waitUntil(updateCache());
});

当安装完成后,service worker
可以监听和控制 fetch
事件,让我们可以完全控制之后网站中产生的所有网络请求。

JavaScript

self.addEventListener(‘fetch’, function (event) {
event.respondWith(fetch(event.request)); });

1
2
3
self.addEventListener(‘fetch’, function (event) {
    event.respondWith(fetch(event.request));
});

在这里我们有很灵活的空间可以发挥,比如下面这个点子,可以通过代码来生成我们自己的请求响应:

JavaScript

self.addEventListener(‘fetch’, function (event) { var response = new
Response(‘<h1>Hello, World!</h1>’, { headers: {
‘Content-Type’: ‘text/html’ } }); event.respondWith(response); });

1
2
3
4
5
self.addEventListener(‘fetch’, function (event) {
    var response = new Response(‘&lt;h1&gt;Hello, World!&lt;/h1&gt;’,
        { headers: { ‘Content-Type’: ‘text/html’ } });
    event.respondWith(response);
});

还有这个,如果在缓存中找到了请求相应的缓存,我们可以直接从缓存中返回它,如果没找到的话,再通过网络获取响应内容:

JavaScript

self.addEventListener(‘fetch’, function (event) { event.respondWith(
caches.match(event.request) .then(function (response) { return response
|| fetch(event.request); }) ); });

1
2
3
4
5
6
7
8
self.addEventListener(‘fetch’, function (event) {
    event.respondWith(
        caches.match(event.request)
            .then(function (response) {
                return response || fetch(event.request);
            })
    );
});

那么我们如何使用这些功能来提供离线体验呢?

首先,在 service worker
安装过程中,我们需要把离线页面需要的 HTML 和资源文件通过 service worker
缓存下来。在缓存中,我们加载了自己开发的 填字游戏 的
React应用 页面。之后,我们会拦截所有访问
theguardian.com
网络请求,包括网页、以及页面中的资源文件。处理这些请求的逻辑大致如下:

  1. 当我们检测到传入请求是指向我们的 HTML
    页面时,我们总是会想要提供最新的内容,所以我们会尝试把这个请求通过网络发送给服务器。

    1. 当我们从服务器得到了响应,就可以直接返回这个响应。
    2. 如果网络请求抛出了异常(比如因为用户掉线了),我们捕获这个异常,然后使用缓存的离线
      HTML 页面作为响应内容。
  2. 否则,当我们检测到请求的不是 HTML
    的话,我们会从缓存中查找响应的请求内容。

    1. 如果找到了缓存内容,我们可以直接返回缓存的内容。
    2. 否则,我们会尝试把这个请求通过网络发送给服务器。

在代码中,我们使用了 新的缓存
API(它是 Service Worker API 的一部分)以及
fetch
功能(用于生成网络请求),如下所示:

JavaScript

var doesRequestAcceptHtml = function (request) { return
request.headers.get(‘Accept’) .split(‘,’) .some(function (type) { return
type === ‘text/html’; }); }; self.addEventListener(‘fetch’, function
(event) { var request = event.request; if
(doesRequestAcceptHtml(request)) { // HTML pages fallback to offline
page event.respondWith( fetch(request) .catch(function () { return
caches.match(‘/offline-page.html’); }) ); } else { // Default fetch
behaviour // Cache first for all other requests event.respondWith(
caches.match(request) .then(function (response) { return response ||
fetch(request); }) ); } });

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
var doesRequestAcceptHtml = function (request) {
    return request.headers.get(‘Accept’)
        .split(‘,’)
        .some(function (type) { return type === ‘text/html’; });
};
 
self.addEventListener(‘fetch’, function (event) {
    var request = event.request;
    if (doesRequestAcceptHtml(request)) {
        // HTML pages fallback to offline page
        event.respondWith(
            fetch(request)
                .catch(function () {
                    return caches.match(‘/offline-page.html’);
                })
        );
    } else {
        // Default fetch behaviour
        // Cache first for all other requests
        event.respondWith(
            caches.match(request)
                .then(function (response) {
                    return response || fetch(request);
                })
        );
    }
});

就只需要这么多!theguardian.com
上的 所有代码都是在 GitHub
上开源 的,所以你可以去那儿查看我们的
service worker
的完整版本,或者直接从生产环境上访问

我们有充足的理由为这些新的浏览器技术欢呼喝彩,因为它可以用来让你的网站像今天的原生应用一样,拥有完善的离线体验。未来当
theguardian.com 完全迁移到 HTTPS
之后,离线页面的重要性会明显增加,我们可以提供更加完善的离线体验。设想一下你在上下班路上网络很差的时候访问
theguardian.com,你会看到专门为你订制的个性化内容,它们是在你之前访问网站时由浏览器缓存下来的。它在安装过程中也不会产生任何不便,你所需要的只是访问这个网站而已,不像原生应用,还需要用户有一个应用商店的账号才能安装。Service
worker
同样可以帮助我们提升网站的加载速度,因为网站的框架能够被可靠地缓存下来,就像原生应用一样。

如果你对 service worker
很感兴趣,想要了解更多内容的话,开发者 Matt
Gaunt(Chrome的忠实支持者)写了一篇更加详细地 介绍 Service
Worker的文章。

打赏支持我翻译更多好文章,谢谢!

打赏译者

2. Service Worker的支持情况

Service Worker目前只有Chrome/Firfox/Opera支持:

图片 8

Safari和Edge也在准备支持Service Worker,由于Service
Worker是谷歌主导的一项标准,对于生态比较封闭的Safari来说也是迫于形势开始准备支持了,在Safari
TP版本,可以看到:

图片 9

在实验功能(Experimental Features)里已经有Service
Worker的菜单项了,只是即使打开也是不能用,会提示你还没有实现:

图片 10

但不管如何,至少说明Safari已经准备支持Service
Worker了。另外还可以看到在今年2017年9月发布的Safari
11.0.1版本已经支持WebRTC了,所以Safari还是一个上进的孩子。

Edge也准备支持,所以Service Worker的前景十分光明。

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(URL).then(function(response) { // 通过promise
对象获得相应内容,并且将响应内容按照json格式转成对象,json()方法调用之后返回的依然是promise对象
// 也可以把内容转化成arraybuffer、blob对象 return response.json();
}).then(function(json) { // 渲染页面 insertPhotos(json); }); }
fetchDemo();

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支持。

第二步:创建一个应用程序清单(Manifest)

应用程序清单提供了和当前渐进式Web应用的相关信息,如:

  • 应用程序名
  • 描述
  • 所有图片(包括主屏幕图标,启动屏幕页面和用的图片或者网页上用的图片)

本质上讲,程序清单是页面上用到的图标和主题等资源的元数据。

程序清单是一个位于您应用根目录的JSON文件。该JSON文件返回时必须添加Content-Type: application/manifest+json 或者 Content-Type: application/jsonHTTP头信息。程序清单的文件名不限,在本文的示例代码中为manifest.json

{ “name” : “PWA Website”, “short_name” : “PWA”, “description” : “An
example PWA website”, “start_url” : “/”, “display” : “standalone”,
“orientation” : “any”, “background_color” : “#ACE”, “theme_color” :
“#ACE”, “icons”: [ { “src” : “/images/logo/logo072.png”, “sizes” :
“72×72”, “type” : “image/png” }, { “src” : “/images/logo/logo152.png”,
“sizes” : “152×152”, “type” : “image/png” }, { “src” :
“/images/logo/logo192.png”, “sizes” : “192×192”, “type” : “image/png” },
{ “src” : “/images/logo/logo256.png”, “sizes” : “256×256”, “type” :
“image/png” }, { “src” : “/images/logo/logo512.png”, “sizes” :
“512×512”, “type” : “image/png” } ] }

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
{
  "name"              : "PWA Website",
  "short_name"        : "PWA",
  "description"       : "An example PWA website",
  "start_url"         : "/",
  "display"           : "standalone",
  "orientation"       : "any",
  "background_color"  : "#ACE",
  "theme_color"       : "#ACE",
  "icons": [
    {
      "src"           : "/images/logo/logo072.png",
      "sizes"         : "72×72",
      "type"          : "image/png"
    },
    {
      "src"           : "/images/logo/logo152.png",
      "sizes"         : "152×152",
      "type"          : "image/png"
    },
    {
      "src"           : "/images/logo/logo192.png",
      "sizes"         : "192×192",
      "type"          : "image/png"
    },
    {
      "src"           : "/images/logo/logo256.png",
      "sizes"         : "256×256",
      "type"          : "image/png"
    },
    {
      "src"           : "/images/logo/logo512.png",
      "sizes"         : "512×512",
      "type"          : "image/png"
    }
  ]
}

程序清单文件建立完之后,你需要在每个页面上引用该文件:

<link rel=”manifest” href=”/manifest.json”>

1
<link rel="manifest" href="/manifest.json">

以下属性在程序清单中经常使用,介绍说明如下:

  • name: 用户看到的应用名称
  • short_name: 应用短名称。当显示应用名称的地方不够时,将使用该名称。
  • description: 应用描述。
  • start_url: 应用起始路径,相对路径,默认为/。
  • scope: URL范围。比如:如果您将“/app/”设置为URL范围时,这个应用就会一直在这个目录中。
  • background_color: 欢迎页面的背景颜色和浏览器的背景颜色(可选)
  • theme_color: 应用的主题颜色,一般都会和背景颜色一样。这个设置决定了应用如何显示。
  • orientation: 优先旋转方向,可选的值有:any, natural, landscape,
    landscape-primary, landscape-secondary, portrait, portrait-primary,
    and portrait-secondary
  • display: 显示方式——fullscreen(无Chrome),standalone(和原生应用一样),minimal-ui(最小的一套UI控件集)或者browser(最古老的使用浏览器标签显示)
  • icons: 一个包含所有图片的数组。该数组中每个元素包含了图片的URL,大小和类型。

在我们开始写码之前

从这个项目地址拿到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了解最佳实践。

打赏支持我翻译更多好文章,谢谢!

图片 11

1 赞 收藏
评论

3. 使用Service Worker

Service
Worker的使用套路是先注册一个Worker,然后后台就会启动一条线程,可以在这条线程启动的时候去加载一些资源缓存起来,然后监听fetch事件,在这个事件里拦截页面的请求,先看下缓存里有没有,如果有直接返回,否则正常加载。或者是一开始不缓存,每个资源请求后再拷贝一份缓存起来,然后下一次请求的时候缓存里就有了。

message事件

页面和serviceWorker之间可以通过posetMessage()方法发送消息,发送的消息可以通过message事件接收到。

这是一个双向的过程,页面可以发消息给service worker,service
worker也可以发送消息给页面,由于这个特性,可以将service
worker作为中间纽带,使得一个域名或者子域名下的多个页面可以自由通信。

这里是一个小的页面之间通信demo

第三步:创建一个 Service Worker

Service Worker
是一个可编程的服务器代理,它可以拦截或者响应网络请求。Service Worker
是位于应用程序根目录的一个个的JavaScript文件。

您需要在页面对应的JavaScript文件中注册该ServiceWorker:

if (‘serviceWorker’ in navigator) { // register service worker
navigator.serviceWorker.register(‘/service-worker.js’); }

1
2
3
4
if (‘serviceWorker’ in navigator) {
  // register service worker
  navigator.serviceWorker.register(‘/service-worker.js’);
}

如果您不需要离线的相关功能,您可以只创建一个 /service-worker.js文件,这样用户就可以直接安装您的Web应用了!

Service
Worker这个概念可能比较难懂,它其实是一个工作在其他线程中的标准的Worker,它不可以访问页面上的DOM元素,没有页面上的API,但是可以拦截所有页面上的网络请求,包括页面导航,请求资源,Ajax请求。

上面就是使用全站HTTPS的主要原因了。假设您没有在您的网站中使用HTTPS,一个第三方的脚本就可以从其他的域名注入他自己的ServiceWorker,然后篡改所有的请求——这无疑是非常危险的。

Service Worker 会响应三个事件:install,activate和fetch。

使用Service Worker

现在我们有了polyfill,并且搞定了HTTPS,让我们看看究竟怎么用service
worker。

关于作者:Erucy

图片 12

曾经的SharePoint喵星程序猿(暂时还挂着微软MVP的名头),现在的Azure/.Net/MongoDB/Cordova/前端程序猿,偶尔写小说

个人主页 ·
我的文章 ·
46 ·
  

图片 13

(1)注册一个Service Worker

Service Worker对象是在window.navigator里面,如下代码:

JavaScript

window.addEventListener(“load”, function() { console.log(“Will the
service worker register?”); navigator.serviceWorker.register(‘/sw-3.js’)
.then(function(reg){ console.log(“Yes, it did.”); }).catch(function(err)
{ console.log(“No it didn’t. This happened: “, err) }); });

1
2
3
4
5
6
7
8
9
window.addEventListener("load", function() {
    console.log("Will the service worker register?");
    navigator.serviceWorker.register(‘/sw-3.js’)
    .then(function(reg){
        console.log("Yes, it did.");
    }).catch(function(err) {
        console.log("No it didn’t. This happened: ", err)
    });
});

在页面load完之后注册,注册的时候传一个js文件给它,这个js文件就是Service
Worker的运行环境,如果不能成功注册的话就会抛异常,如Safari
TP虽然有这个对象,但是会抛异常无法使用,就可以在catch里面处理。这里有个问题是为什么需要在load事件启动呢?因为你要额外启动一个线程,启动之后你可能还会让它去加载资源,这些都是需要占用CPU和带宽的,我们应该保证页面能正常加载完,然后再启动我们的后台线程,不能与正常的页面加载产生竞争,这个在低端移动设备意义比较大。

还有一点需要注意的是Service
Worker和Cookie一样是有Path路径的概念的,如果你设定一个cookie假设叫time的path=/page/A,在/page/B这个页面是不能够获取到这个cookie的,如果设置cookie的path为根目录/,则所有页面都能获取到。类似地,如果注册的时候使用的js路径为/page/sw.js,那么这个Service
Worker只能管理/page路径下的页面和资源,而不能够处理/api路径下的,所以一般把Service
Worker注册到顶级目录,如上面代码的”/sw-3.js”,这样这个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是一个InstallEvent对象,继承自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的过程中,也遇到了一些问题,下面是其中两个

Install事件

该事件将在应用安装完成后触发。我们一般在这里使用Cache
API缓存一些必要的文件。

首先,我们需要提供如下配置

  1. 缓存名称(CACHE)以及版本(version)。应用可以有多个缓存存储,但是在使用时只会使用其中一个缓存存储。每当缓存存储有变化时,新的版本号将会指定到缓存存储中。新的缓存存储将会作为当前的缓存存储,之前的缓存存储将会被作废。
  2. 一个离线的页面地址(offlineURL):当用户访问了之前没有访问过的地址时,该页面将会显示。
  3. 一个包含了所有必须文件的数组,包括保障页面正常功能的CSS和JavaScript。在本示例中,我还添加了主页和logo。当有不同的URL指向同一个资源时,你也可以将这些URL分别写到这个数组中。offlineURL将会加入到这个数组中。
  4. 我们也可以将一些非必要的缓存文件(installFilesDesirable)。这些文件在安装过程中将会被下载,但如果下载失败,不会触发安装失败。

// 配置文件 const version = ‘1.0.0’, CACHE = version + ‘::PWAsite’,
offlineURL = ‘/offline/’, installFilesEssential = [ ‘/’,
‘/manifest.json’, ‘/css/styles.css’, ‘/js/main.js’,
‘/js/offlinepage.js’, ‘/images/logo/logo152.png’ ].concat(offlineURL),
installFilesDesirable = [ ‘/favicon.ico’, ‘/images/logo/logo016.png’,
‘/images/hero/power-pv.jpg’, ‘/images/hero/power-lo.jpg’,
‘/images/hero/power-hi.jpg’ ];

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// 配置文件
const
  version = ‘1.0.0’,
  CACHE = version + ‘::PWAsite’,
  offlineURL = ‘/offline/’,
  installFilesEssential = [
    ‘/’,
    ‘/manifest.json’,
    ‘/css/styles.css’,
    ‘/js/main.js’,
    ‘/js/offlinepage.js’,
    ‘/images/logo/logo152.png’
  ].concat(offlineURL),
  installFilesDesirable = [
    ‘/favicon.ico’,
    ‘/images/logo/logo016.png’,
    ‘/images/hero/power-pv.jpg’,
    ‘/images/hero/power-lo.jpg’,
    ‘/images/hero/power-hi.jpg’
  ];

installStaticFiles() 方法使用基于Promise的方式使用Cache
API将文件存储到缓存中。

// 安装静态资源 function installStaticFiles() { return
caches.open(CACHE) .then(cache => { // 缓存可选文件
cache.addAll(installFilesDesirable); // 缓存必须文件 return
cache.addAll(installFilesEssential); }); }

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// 安装静态资源
function installStaticFiles() {
  return caches.open(CACHE)
    .then(cache => {
      // 缓存可选文件
      cache.addAll(installFilesDesirable);
      // 缓存必须文件
      return cache.addAll(installFilesEssential);
    });
}

最后,我们添加一个install的事件监听器。waitUntil方法保证了service
worker不会安装直到其相关的代码被执行。这里它会执行installStaticFiles()方法,然后self.skipWaiting()方法来激活service
worker:

// 应用安装 self.addEventListener(‘install’, event => {
console.log(‘service worker: install’); // 缓存主要文件 event.waitUntil(
installStaticFiles() .then(() => self.skipWaiting()) ); });

1
2
3
4
5
6
7
8
9
10
11
12
// 应用安装
self.addEventListener(‘install’, event => {
  console.log(‘service worker: install’);
  // 缓存主要文件
  event.waitUntil(
    installStaticFiles()
    .then(() => self.skipWaiting())
  );
});

如何注册和安装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是否对你的网站启用了。

图片 14

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

你会发现这个功能能够很方便地在一个模拟窗口中测试你的service
worker,这样你可以关闭和重新打开它,而不会影响到你的新窗口。任何创建在模拟窗口中的注册服务和缓存在窗口被关闭时都将消失。

(2)Service Worker安装和激活

注册完之后,Service
Worker就会进行安装,这个时候会触发install事件,在install事件里面可以缓存一些资源,如下sw-3.js:

JavaScript

const CACHE_NAME = “fed-cache”; this.addEventListener(“install”,
function(event) { this.skipWaiting(); console.log(“install service
worker”); // 创建和打开一个缓存库 caches.open(CACHE_NAME); // 首页 let
cacheResources = [“];
event.waitUntil( // 请求资源并添加到缓存里面去
caches.open(CACHE_NAME).then(cache => {
cache.addAll(cacheResources); }) ); });

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
const CACHE_NAME = "fed-cache";
this.addEventListener("install", function(event) {
    this.skipWaiting();
    console.log("install service worker");
    // 创建和打开一个缓存库
    caches.open(CACHE_NAME);
    // 首页
    let cacheResources = ["https://fed.renren.com/?launcher=true"];
    event.waitUntil(
        // 请求资源并添加到缓存里面去
        caches.open(CACHE_NAME).then(cache => {
            cache.addAll(cacheResources);
        })
    );
});

通过上面的操作,创建和添加了一个缓存库叫fed-cache,如下Chrome控制台所示:

图片 15

Service
Worker的API基本上都是返回Promise对象避免堵塞,所以要用Promise的写法。上面在安装Service
Worker的时候就把首页的请求给缓存起来了。在Service
Worker的运行环境里面它有一个caches的全局对象,这个是缓存的入口,还有一个常用的clients的全局对象,一个client对应一个标签页。

在Service
Worker里面可以使用fetch等API,它和DOM是隔离的,没有windows/document对象,无法直接操作DOM,无法直接和页面交互,在Service
Worker里面无法得知当前页面打开了、当前页面的url是什么,因为一个Service
Worker管理当前打开的几个标签页,可以通过clients知道所有页面的url。还有可以通过postMessage的方式和主页面互相传递消息和数据,进而做些控制。

install完之后,就会触发Service Worker的active事件:

JavaScript

this.addEventListener(“active”, function(event) { console.log(“service
worker is active”); });

1
2
3
this.addEventListener("active", function(event) {
    console.log("service worker is active");
});

Service
Worker激活之后就能够监听fetch事件了,我们希望每获取一个资源就把它缓存起来,就不用像上一篇提到的Manifest需要先生成一个列表。

你可能会问,当我刷新页面的时候不是又重新注册安装和激活了一个Service
Worker?虽然又调了一次注册,但并不会重新注册,它发现”sw-3.js”这个已经注册了,就不会再注册了,进而不会触发install和active事件,因为当前Service
Worker已经是active状态了。当需要更新Service
Worker时,如变成”sw-4.js”,或者改变sw-3.js的文本内容,就会重新注册,新的Service
Worker会先install然后进入waiting状态,等到重启浏览器时,老的Service
Worker就会被替换掉,新的Service
Worker进入active状态,如果不想等到重新启动浏览器可以像上面一样在install里面调skipWaiting:

JavaScript

this.skipWaiting();

1
this.skipWaiting();

问题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,在调试过程中经常等上一两分钟才会使用新的,比较抓狂。

Activate 事件

这个事件会在service
worker被激活时发生。你可能不需要这个事件,但是在示例代码中,我们在该事件发生时将老的缓存全部清理掉了:

// clear old caches function clearOldCaches() { return caches.keys()
.then(keylist => { return Promise.all( keylist .filter(key => key
!== CACHE) .map(key => caches.delete(key)) ); }); } // application
activated self.addEventListener(‘activate’, event => {
console.log(‘service worker: activate’); // delete old caches
event.waitUntil( clearOldCaches() .then(() => self.clients.claim())
); });

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
// clear old caches
function clearOldCaches() {
  return caches.keys()
    .then(keylist => {
      return Promise.all(
        keylist
          .filter(key => key !== CACHE)
          .map(key => caches.delete(key))
      );
    });
}
// application activated
self.addEventListener(‘activate’, event => {
  console.log(‘service worker: activate’);
    // delete old caches
  event.waitUntil(
    clearOldCaches()
    .then(() => self.clients.claim())
    );
});

注意self.clients.claim()执行时将会把当前service
worker作为被激活的worker。

Fetch 事件
该事件将会在网络开始请求时发起。该事件处理函数中,我们可以使用respondWith()方法来劫持HTTP的GET请求然后返回:

  1. 从缓存中取到的资源文件
  2. 如果第一步失败,资源文件将会从网络中使用Fetch API来获取(和service
    worker中的fetch事件无关)。获取到的资源将会加入到缓存中。
  3. 如果第一步和第二步均失败,将会从缓存中返回正确的资源文件。

// application fetch network data self.addEventListener(‘fetch’, event
=> { // abandon non-GET requests if (event.request.method !== ‘GET’)
return; let url = event.request.url; event.respondWith(
caches.open(CACHE) .then(cache => { return cache.match(event.request)
.then(response => { if (response) { // return cached file
console.log(‘cache fetch: ‘ + url); return response; } // make network
request return fetch(event.request) .then(newreq => {
console.log(‘network fetch: ‘ + url); if (newreq.ok)
cache.put(event.request, newreq.clone()); return newreq; }) // app is
offline .catch(() => offlineAsset(url)); }); }) ); });

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
40
41
// application fetch network data
self.addEventListener(‘fetch’, event => {
  // abandon non-GET requests
  if (event.request.method !== ‘GET’) return;
  let url = event.request.url;
  event.respondWith(
    caches.open(CACHE)
      .then(cache => {
        return cache.match(event.request)
          .then(response => {
            if (response) {
              // return cached file
              console.log(‘cache fetch: ‘ + url);
              return response;
            }
            // make network request
            return fetch(event.request)
              .then(newreq => {
                console.log(‘network fetch: ‘ + url);
                if (newreq.ok) cache.put(event.request, newreq.clone());
                return newreq;
              })
              // app is offline
              .catch(() => offlineAsset(url));
          });
      })
  );
});

offlineAsset(url)方法中使用了一些helper方法来返回正确的数据:

// 是否为图片地址? let iExt = [‘png’, ‘jpg’, ‘jpeg’, ‘gif’, ‘webp’,
‘bmp’].map(f => ‘.’ + f); function isImage(url) { return
iExt.reduce((ret, ext) => ret || url.endsWith(ext), false); } //
return 返回离线资源 function offlineAsset(url) { if (isImage(url)) { //
返回图片 return new Response( ‘<svg role=”img” viewBox=”0 0 400 300″
xmlns=”
d=”M0 0h400v300H0z” fill=”#eee” /><text x=”200″ y=”150″
text-anchor=”middle” dominant-baseline=”middle” font-family=”sans-serif”
font-size=”50″ fill=”#ccc”>offline</text></svg>’, {
headers: { ‘Content-Type’: ‘image/svg+xml’, ‘Cache-Control’: ‘no-store’
}} ); } else { // return page return caches.match(offlineURL); } }

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
// 是否为图片地址?
let iExt = [‘png’, ‘jpg’, ‘jpeg’, ‘gif’, ‘webp’, ‘bmp’].map(f => ‘.’ + f);
function isImage(url) {
  
  return iExt.reduce((ret, ext) => ret || url.endsWith(ext), false);
  
}
  
  
// return 返回离线资源
function offlineAsset(url) {
  
  if (isImage(url)) {
  
    // 返回图片
    return new Response(
      ‘<svg role="img" viewBox="0 0 400 300" xmlns="http://www.w3.org/2000/svg"><title>offline</title><path d="M0 0h400v300H0z" fill="#eee" /><text x="200" y="150" text-anchor="middle" dominant-baseline="middle" font-family="sans-serif" font-size="50" fill="#ccc">offline</text></svg>’,
      { headers: {
        ‘Content-Type’: ‘image/svg+xml’,
        ‘Cache-Control’: ‘no-store’
      }}
    );
  
  }
  else {
  
    // return page
    return caches.match(offlineURL);
  
  }
  
}

offlineAsset()方法检查请求是否为一个图片,然后返回一个带有“offline”文字的SVG文件。其他请求将会返回
offlineURL 页面。

Chrome开发者工具中的ServiceWorker部分提供了关于当前页面worker的信息。其中会显示worker中发生的错误,还可以强制刷新,也可以让浏览器进入离线模式。

Cache Storage
部分例举了当前所有已经缓存的资源。你可以在缓存需要更新的时候点击refresh按钮。

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

(3)fetch资源后cache起来

如下代码,监听fetch事件做些处理:

JavaScript

this.addEventListener(“fetch”, function(event) { event.respondWith(
caches.match(event.request).then(response => { // cache hit if
(response) { return response; } return
util.fetchPut(event.request.clone()); }) ); });

1
2
3
4
5
6
7
8
9
10
11
12
this.addEventListener("fetch", function(event) {
    event.respondWith(
        caches.match(event.request).then(response => {
            // cache hit
            if (response) {
                return response;
            }
            return util.fetchPut(event.request.clone());
        })
    );
});

先调caches.match看一下缓存里面是否有了,如果有直接返回缓存里的response,否则的话正常请求资源并把它放到cache里面。放在缓存里资源的key值是Request对象,在match的时候,需要请求的url和header都一致才是相同的资源,可以设定第二个参数ignoreVary:

JavaScript

caches.match(event.request, {ignoreVary: true})

1
caches.match(event.request, {ignoreVary: true})

表示只要请求url相同就认为是同一个资源。

上面代码的util.fetchPut是这样实现的:

JavaScript

let util = { fetchPut: function (request, callback) { return
fetch(request).then(response => { // 跨域的资源直接return if
(!response || response.status !== 200 || response.type !== “basic”) {
return response; } util.putCache(request, response.clone()); typeof
callback === “function” && callback(); return response; }); }, putCache:
function (request, resource) { // 后台不要缓存,preview链接也不要缓存 if
(request.method === “GET” && request.url.indexOf(“wp-admin”) < 0 &&
request.url.indexOf(“preview_id”) < 0) {
caches.open(CACHE_NAME).then(cache => { cache.put(request,
resource); }); } } };

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
let util = {
    fetchPut: function (request, callback) {
        return fetch(request).then(response => {
            // 跨域的资源直接return
            if (!response || response.status !== 200 || response.type !== "basic") {
                return response;
            }
            util.putCache(request, response.clone());
            typeof callback === "function" && callback();
            return response;
        });
    },
    putCache: function (request, resource) {
        // 后台不要缓存,preview链接也不要缓存
        if (request.method === "GET" && request.url.indexOf("wp-admin") < 0
              && request.url.indexOf("preview_id") < 0) {
            caches.open(CACHE_NAME).then(cache => {
                cache.put(request, resource);
            });
        }
    }
};

需要注意的是跨域的资源不能缓存,response.status会返回0,如果跨域的资源支持CORS,那么可以把request的mod改成cors。如果请求失败了,如404或者是超时之类的,那么也直接返回response让主页面处理,否则的话说明加载成功,把这个response克隆一个放到cache里面,然后再返回response给主页面线程。注意能放缓存里的资源一般只能是GET,通过POST获取的是不能缓存的,所以要做个判断(当然你也可以手动把request对象的method改成get),还有把一些个人不希望缓存的资源也做个判断。

这样一旦用户打开过一次页面,Service
Worker就安装好了,他刷新页面或者打开第二个页面的时候就能够把请求的资源一一做缓存,包括图片、CSS、JS等,只要缓存里有了不管用户在线或者离线都能够正常访问。这样我们自然会有一个问题,这个缓存空间到底有多大?上一篇我们提到Manifest也算是本地存储,PC端的Chrome是5Mb,其实这个说法在新版本的Chrome已经不准确了,在Chrome
61版本可以看到本地存储的空间和使用情况:

图片 16

其中Cache Storage是指Service
Worker和Manifest占用的空间大小和,上图可以看到总的空间大小是20GB,几乎是unlimited,所以基本上不用担心缓存会不够用。

问题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 收藏
评论

图片 13

第四步:创建可用的离线页面

离线页面可以是静态的HTML,一般用于提醒用户当前请求的页面暂时无法使用。然而,我们可以提供一些可以阅读的页面链接。

Cache
API可以在main.js中使用。然而,该API使用Promise,在不支持Promise的浏览器中会失败,所有的JavaScript执行会因此受到影响。为了避免这种情况,在访问/js/offlinepage.js的时候我们添加了一段代码来检查当前是否在离线环境中:

/js/offlinepage.js 中以版本号为名称保存了最近的缓存,获取所有URL,删除不是页面的URL,将这些URL排序然后将所有缓存的URL展示在页面上:

// cache name const CACHE = ‘::PWAsite’, offlineURL = ‘/offline/’, list
= document.getElementById(‘cachedpagelist’); // fetch all caches
window.caches.keys() .then(cacheList => { // find caches by and order
by most recent cacheList = cacheList .filter(cName =>
cName.includes(CACHE)) .sort((a, b) => a – b); // open first cache
caches.open(cacheList[0]) .then(cache => { // fetch cached pages
cache.keys() .then(reqList => { let frag =
document.createDocumentFragment(); reqList .map(req => req.url)
.filter(req => (req.endsWith(‘/’) || req.endsWith(‘.html’)) &&
!req.endsWith(offlineURL)) .sort() .forEach(req => { let li =
document.createElement(‘li’), a =
li.appendChild(document.createElement(‘a’)); a.setAttribute(‘href’,
req); a.textContent = a.pathname; frag.appendChild(li); }); if (list)
list.appendChild(frag); }); }) });

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
40
41
42
43
44
45
// cache name
const
  CACHE = ‘::PWAsite’,
  offlineURL = ‘/offline/’,
  list = document.getElementById(‘cachedpagelist’);
// fetch all caches
window.caches.keys()
  .then(cacheList => {
    // find caches by and order by most recent
    cacheList = cacheList
      .filter(cName => cName.includes(CACHE))
      .sort((a, b) => a – b);
    // open first cache
    caches.open(cacheList[0])
      .then(cache => {
        // fetch cached pages
        cache.keys()
          .then(reqList => {
            let frag = document.createDocumentFragment();
            reqList
              .map(req => req.url)
              .filter(req => (req.endsWith(‘/’) || req.endsWith(‘.html’)) && !req.endsWith(offlineURL))
              .sort()
              .forEach(req => {
                let
                  li = document.createElement(‘li’),
                  a = li.appendChild(document.createElement(‘a’));
                  a.setAttribute(‘href’, req);
                  a.textContent = a.pathname;
                  frag.appendChild(li);
              });
            if (list) list.appendChild(frag);
          });
      })
  });

怎样缓存和返回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只能被读取一次,所以我们得将它克隆出来,一份发给浏览器,一份发给缓存。

(4)cache html

上面第(3)步把图片、js、css缓存起来了,但是如果把页面html也缓存了,例如把首页缓存了,就会有一个尴尬的问题——Service
Worker是在页面注册的,但是现在获取页面的时候是从缓存取的,每次都是一样的,所以就导致无法更新Service
Worker,如变成sw-5.js,但是PWA又要求我们能缓存页面html。那怎么办呢?谷歌的开发者文档它只是提到会存在这个问题,但并没有说明怎么解决这个问题。这个的问题的解决就要求我们要有一个机制能知道html更新了,从而把缓存里的html给替换掉。

Manifest更新缓存的机制是去看Manifest的文本内容有没有发生变化,如果发生变化了,则会去更新缓存,Service
Worker也是根据sw.js的文本内容有没有发生变化,我们可以借鉴这个思想,如果请求的是html并从缓存里取出来后,再发个请求获取一个文件看html更新时间是否发生变化,如果发生变化了则说明发生更改了,进而把缓存给删了。所以可以在服务端通过控制这个文件从而去更新客户端的缓存。如下代码:

JavaScript

this.addEventListener(“fetch”, function(event) { event.respondWith(
caches.match(event.request).then(response => { // cache hit if
(response) { //如果取的是html,则看发个请求看html是否更新了 if
(response.headers.get(“Content-Type”).indexOf(“text/html”) >= 0) {
console.log(“update html”); let url = new URL(event.request.url);
util.updateHtmlPage(url, event.request.clone(), event.clientId); }
return response; } return util.fetchPut(event.request.clone()); }) );
});

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
this.addEventListener("fetch", function(event) {
 
    event.respondWith(
        caches.match(event.request).then(response => {
            // cache hit
            if (response) {
                //如果取的是html,则看发个请求看html是否更新了
                if (response.headers.get("Content-Type").indexOf("text/html") >= 0) {
                    console.log("update html");
                    let url = new URL(event.request.url);
                    util.updateHtmlPage(url, event.request.clone(), event.clientId);
                }
                return response;
            }
 
            return util.fetchPut(event.request.clone());
        })
    );
});

通过响应头header的content-type是否为text/html,如果是的话就去发个请求获取一个文件,根据这个文件的内容决定是否需要删除缓存,这个更新的函数util.updateHtmlPage是这么实现的:

JavaScript

let pageUpdateTime = { }; let util = { updateHtmlPage: function (url,
htmlRequest) { let pageName = util.getPageName(url); let jsonRequest =
new Request(“/html/service-worker/cache-json/” + pageName + “.sw.json”);
fetch(jsonRequest).then(response => { response.json().then(content
=> { if (pageUpdateTime[pageName] !== content.updateTime) {
console.log(“update page html”); // 如果有更新则重新获取html
util.fetchPut(htmlRequest); pageUpdateTime[pageName] =
content.updateTime; } }); }); }, delCache: function (url) {
caches.open(CACHE_NAME).then(cache => { console.log(“delete cache “

  • url); cache.delete(url, {ignoreVary: true}); }); } };
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
let pageUpdateTime = {
 
};
let util = {
    updateHtmlPage: function (url, htmlRequest) {
        let pageName = util.getPageName(url);
        let jsonRequest = new Request("/html/service-worker/cache-json/" + pageName + ".sw.json");
        fetch(jsonRequest).then(response => {
            response.json().then(content => {
                if (pageUpdateTime[pageName] !== content.updateTime) {
                    console.log("update page html");
                    // 如果有更新则重新获取html
                    util.fetchPut(htmlRequest);
                    pageUpdateTime[pageName] = content.updateTime;
                }
            });
        });
    },
    delCache: function (url) {
        caches.open(CACHE_NAME).then(cache => {
            console.log("delete cache " + url);
            cache.delete(url, {ignoreVary: true});
        });
    }
};

代码先去获取一个json文件,一个页面会对应一个json文件,这个json的内容是这样的:

JavaScript

{“updateTime”:”10/2/2017, 3:23:57 PM”,”resources”: {img: [], css:
[]}}

1
{"updateTime":"10/2/2017, 3:23:57 PM","resources": {img: [], css: []}}

里面主要有一个updateTime的字段,如果本地内存没有这个页面的updateTime的数据或者是和最新updateTime不一样,则重新去获取
html,然后放到缓存里。接着需要通知页面线程数据发生变化了,你刷新下页面吧。这样就不用等用户刷新页面才能生效了。所以当刷新完页面后用postMessage通知页面:

JavaScript

let util = { postMessage: async function (msg) { const allClients =
await clients.matchAll(); allClients.forEach(client =>
client.postMessage(msg)); } }; util.fetchPut(htmlRequest, false,
function() { util.postMessage({type: 1, desc: “html found updated”, url:
url.href}); });

1
2
3
4
5
6
7
8
9
let util = {
    postMessage: async function (msg) {
        const allClients = await clients.matchAll();
        allClients.forEach(client => client.postMessage(msg));
    }
};
util.fetchPut(htmlRequest, false, function() {
    util.postMessage({type: 1, desc: "html found updated", url: url.href});
});

并规定type: 1就表示这是一个更新html的消息,然后在页面监听message事件:

JavaScript

if(“serviceWorker” in navigator) {
navigator.serviceWorker.addEventListener(“message”, function(event) {
let msg = event.data; if (msg.type === 1 && window.location.href ===
msg.url) { console.log(“recv from service worker”, event.data);
window.location.reload(); } }); }

1
2
3
4
5
6
7
8
9
if("serviceWorker" in navigator) {
    navigator.serviceWorker.addEventListener("message", function(event) {
        let msg = event.data;
        if (msg.type === 1 && window.location.href === msg.url) {
            console.log("recv from service worker", event.data);
            window.location.reload();
        }  
    });
}

然后当我们需要更新html的时候就更新json文件,这样用户就能看到最新的页面了。或者是当用户重新启动浏览器的时候会导致Service
Worker的运行内存都被清空了,即存储页面更新时间的变量被清空了,这个时候也会重新请求页面。

需要注意的是,要把这个json文件的http
cache时间设置成0,这样浏览器就不会缓存了,如下nginx的配置:

JavaScript

location ~* .sw.json$ { expires 0; }

1
2
3
location ~* .sw.json$ {
    expires 0;
}

因为这个文件是需要实时获取的,不能被缓存,firefox默认会缓存,Chrome不会,加上http缓存时间为0,firefox也不会缓存了。

还有一种更新是用户更新的,例如用户发表了评论,需要在页面通知service
worker把html缓存删了重新获取,这是一个反过来的消息通知:

JavaScript

if (“serviceWorker” in navigator) {
document.querySelector(“.comment-form”).addEventListener(“submit”,
function() { navigator.serviceWorker.controller.postMessage({ type: 1,
desc: “remove html cache”, url: window.location.href} ); } }); }

1
2
3
4
5
6
7
8
9
10
if ("serviceWorker" in navigator) {
    document.querySelector(".comment-form").addEventListener("submit", function() {
            navigator.serviceWorker.controller.postMessage({
                type: 1,
                desc: "remove html cache",
                url: window.location.href}
            );
        }
    });
}

Service Worker也监听message事件:

JavaScript

const messageProcess = { // 删除html index 1: function (url) {
util.delCache(url); } }; let util = { delCache: function (url) {
caches.open(CACHE_NAME).then(cache => { console.log(“delete cache “

  • url); cache.delete(url, {ignoreVary: true}); }); } };
    this.addEventListener(“message”, function(event) { let msg = event.data;
    console.log(msg); if (typeof messageProcess[msg.type] === “function”)
    { messageProcess[msg.type](msg.url); } });
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
const messageProcess = {
    // 删除html index
    1: function (url) {
        util.delCache(url);
    }
};
 
let util = {
    delCache: function (url) {
        caches.open(CACHE_NAME).then(cache => {
            console.log("delete cache " + url);
            cache.delete(url, {ignoreVary: true});
        });
    }
};
 
this.addEventListener("message", function(event) {
    let msg = event.data;
    console.log(msg);
    if (typeof messageProcess[msg.type] === "function") {
        messageProcess[msg.type](msg.url);
    }
});

根据不同的消息类型调不同的回调函数,如果是1的话就是删除cache。用户发表完评论后会触发刷新页面,刷新的时候缓存已经被删了就会重新去请求了。

这样就解决了实时更新的问题。

开发者工具

Chrome浏览器提供了一系列的工具来帮助您来调试Service
Worker,日志也会直接显示在控制台上。

您最好使用匿名模式来进行开发工作,这样可以排除缓存对开发的干扰。

最后,Chrome的Lighthouse扩展也可以为您的渐进式Web应用提供一些改进信息。

如何更新一个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);
          }
        })
      );
    })
  );
});

4. Http/Manifest/Service Worker三种cache的关系

要缓存可以使用三种手段,使用Http
Cache设置缓存时间,也可以用Manifest的Application Cache,还可以用Service
Worker缓存,如果三者都用上了会怎么样呢?

会以Service Worker为优先,因为Service
Worker把请求拦截了,它最先做处理,如果它缓存库里有的话直接返回,没有的话正常请求,就相当于没有Service
Worker了,这个时候就到了Manifest层,Manifest缓存里如果有的话就取这个缓存,如果没有的话就相当于没有Manifest了,于是就会从Http缓存里取了,如果Http缓存里也没有就会发请求去获取,服务端根据Http的etag或者Modified
Time可能会返回304 Not
Modified,否则正常返回200和数据内容。这就是整一个获取的过程。

所以如果既用了Manifest又用Service
Worker的话应该会导致同一个资源存了两次。但是可以让支持Service
Worker的浏览器使用Service Worker,而不支持的使用Manifest.

渐进式Web应用的要点

渐进式Web应用是一种新的技术,所以使用的时候一定要小心。也就是说,渐进式Web应用可以让您的网站在几个小时内得到改善,并且在不支持渐进式Web应用的浏览器上也不会影响网站的显示。

但是我们需要考虑以下几点:

处理边界和填坑

这一节内容比较新,有很多待定细节。希望这一节很快就不需要讲了(因为标准会处理这些问题——译者注),但是现在,这些内容还是应该被提一下。

5. 使用Web App Manifest添加桌面入口

注意这里说的是另外一个Manifest,这个Manifest是一个json文件,用来放网站icon名称等信息以便在桌面添加一个图标,以及制造一种打开这个网页就像打开App一样的效果。上面一直说的Manifest是被废除的Application
Cache的Manifest。

这个Maifest.json文件可以这么写:

JavaScript

{ “short_name”: “人人FED”, “name”: “人人网FED,专注于前端技术”,
“icons”: [ { “src”: “/html/app-manifest/logo_48.png”, “type”:
“image/png”, “sizes”: “48×48” }, { “src”:
“/html/app-manifest/logo_96.png”, “type”: “image/png”, “sizes”: “96×96”
}, { “src”: “/html/app-manifest/logo_192.png”, “type”: “image/png”,
“sizes”: “192×192” }, { “src”: “/html/app-manifest/logo_512.png”,
“type”: “image/png”, “sizes”: “512×512” } ], “start_url”:
“/?launcher=true”, “display”: “standalone”, “background_color”:
“#287fc5”, “theme_color”: “#fff” }

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
{
  "short_name": "人人FED",
  "name": "人人网FED,专注于前端技术",
  "icons": [
    {
      "src": "/html/app-manifest/logo_48.png",
      "type": "image/png",
      "sizes": "48×48"
    },
    {
      "src": "/html/app-manifest/logo_96.png",
      "type": "image/png",
      "sizes": "96×96"
    },
    {
      "src": "/html/app-manifest/logo_192.png",
      "type": "image/png",
      "sizes": "192×192"
    },
    {
      "src": "/html/app-manifest/logo_512.png",
      "type": "image/png",
      "sizes": "512×512"
    }
  ],
  "start_url": "/?launcher=true",
  "display": "standalone",
  "background_color": "#287fc5",
  "theme_color": "#fff"
}

icon需要准备多种规格,最大需要512px *
512px的,这样Chrome会自动去选取合适的图片。如果把display改成standalone,从生成的图标打开就会像打开一个App一样,没有浏览器地址栏那些东西了。start_url指定打开之后的入口链接。

然后添加一个link标签指向这个manifest文件:

JavaScript

<link rel=”manifest” href=”/html/app-manifest/manifest.json”>

1
<link rel="manifest" href="/html/app-manifest/manifest.json">

这样结合Service Worker缓存:
图片 18把start_url指向的页面用Service
Worker缓存起来,这样当用户用Chrome浏览器打开这个网页的时候,Chrome就会在底部弹一个提示,询问用户是否把这个网页添加到桌面,如果点“添加”就会生成一个桌面图标,从这个图标点进去就像打开一个App一样。感受如下:

图片 19

比较尴尬的是Manifest目前只有Chrome支持,并且只能在安卓系统上使用,IOS的浏览器无法添加一个桌面图标,因为IOS没有开放这种API,但是自家的Safari却又是可以的。

综上,本文介绍了怎么用Service Worker结合Manifest做一个PWA离线Web
APP,主要是用Service
Worker控制缓存,由于是写JS,比较灵活,还可以与页面进行通信,另外通过请求页面的更新时间来判断是否需要更新html缓存。Service
Worker的兼容性不是特别好,但是前景比较光明,浏览器都在准备支持。现阶段可以结合offline
cache的Manifest做离线应用。

相关阅读:

  1. 为什么要把网站升级到HTTPS
  2. 怎样把网站升级到http/2
  3. 我是怎样让网站用上HTML5
    Manifest

1 赞 1 收藏
评论

图片 13

URL隐藏

当您的应用就是一个单URL的应用程序时(比如游戏),我建议您隐藏地址栏。除此之外的情况我并不建议您隐藏地址栏。在Manifest中,display: minimal-ui 或者 display: browser对于大多数情况来说足够用了。

如果安装失败了,没有很优雅的方式获得通知

如果一个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中用。

缓存刷新

示例代码中在发起请求之前会先查询缓存。当用户处于离线状态时,这很好,但是如果用户处于在线状态,那他只会浏览到比较老旧的页面。

各种资源比如图片和视频不会改变,所以一般都把这些静态资源设置为长期缓存。这些资源可以直接缓存一年(31,536,000秒)。在HTTP
Header中,就是:

Cache-Control: max-age=31536000

1
Cache-Control: max-age=31536000

页面,CSS和脚本文件可能变化的更频繁一些,所以你可以设置一个比较小的缓存超时时间(24小时),并确保在用户网络连接恢复时再次从服务器请求:

Cache-Control: must-revalidate, max-age=86400

1
Cache-Control: must-revalidate, max-age=86400

你也可以在每次网站发布时,通过改名的方式强制浏览器重新请求资源。

fetch()的默认参数

当你使用fetch,缺省地,请求不会带上cookies等凭据,要想带上的话,需要:

JavaScript

fetch(url, { credentials: ‘include’ })

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

这样设计是有理由的,它比XHR的在同源下默认发送凭据,但跨域时丢弃凭据的规则要来得好。fetch的行为更像其他的CORS请求,例如<img crossorigin>,它默认不发送cookies,除非你指定了<img crossorigin="use-credentials">.。

小结

至此,相信你如果按照本文一步一步操作下来,你也可以很快把自己的Web应用转为PWA。在转为了PWA后,如果有使用满足
PWA
模型的前端控件的需求,你可以试试纯前端表格控件SpreadJS,适用于
.NET、Java 和移动端等平台的表格控件一定不会令你失望的。

原文链接:

1 赞 1 收藏
评论

图片 13

Non-CORS默认不支持

默认情况下,从第三方URL跨域得到一个资源将会失败,除非对方支持了CORS。你可以添加一个non-CORS选项到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;" />

图片 22

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

改变URL Hash的Bug

在M40版本中存在一个bug,它会让页面在改变hash的时候导致service
worker停止工作。

你可以在这里找到更多相关的信息: 

更多内容

这里有一些相关的文档可以参考:

获得帮助

如果你遇到麻烦,请在Stackoverflow上发帖询问,使用‘service-worker’标签,以便于我们及时跟进和尽可能帮助你解决问题。

赞 2 收藏
评论

图片 13

网站地图xml地图