网站首页 > 博客文章正文

使用Service Worker让你的 Web 应用如虎添翼(上)「干货」

baijin 2024-11-07 09:41:08 博客文章 5 ℃ 0 评论

作者：网易@brizer

转发链接：https://github.com/omnipotent-front-end/blog/issues/2

前言

本文首先会简单介绍下前端的常见缓存方式，再引入serviceworker的概念，针对其原理和如何运用进行介绍。然后基于google推出的第三方库workbox，在产品中进行运用实践，并对其原理进行简要剖析。

前端缓存简介

先简单介绍一下现有的前端缓存技术方案，主要分为http缓存和浏览器缓存。

http缓存

http缓存都是第二次请求时开始的，这也是个老生常谈的话题了。无非也是那几个http头的问题：

Expires

HTTP1.0的内容，服务器使用Expires头来告诉Web客户端它可以使用当前副本，直到指定的时间为止。

Cache-Control

HTTP1.1引入了Cathe-Control，它使用max-age指定资源被缓存多久，主要是解决了Expires一个重大的缺陷，就是它设置的是一个固定的时间点，客户端时间和服务端时间可能有误差。

所以一般会把两个头都带上，这种缓存称为强缓存，表现形式为：

Last-Modified / If-Modified-Since

Last-Modified是服务器告诉浏览器该资源的最后修改时间，If-Modified-Since是请求头带上的，上次服务器给自己的该资源的最后修改时间。然后服务器拿去对比。

若资源的最后修改时间大于If-Modified-Since，说明资源又被改动过，则响应整片资源内容，返回状态码200；

若资源的最后修改时间小于或等于If-Modified-Since，说明资源无新修改，则响应HTTP 304，告知浏览器继续使用当前版本。

Etag / If-None-Match

前面提到由文件的修改时间来判断文件是否改动，还是会带来一定的误差，比如注释等无关紧要的修改等。所以推出了新的方式。

Etag是由服务端特定算法生成的该文件的唯一标识，而请求头把返回的Etag值通过If-None-Match再带给服务端，服务端通过比对从而决定是否响应新内容。这也是304缓存。

浏览器缓存

storage

简单的缓存方式有cookie，localStorage和sessionStorage。这里就不详细介绍它们的区别了，这里说下通过localStorage来缓存静态资源的优化方案。

localStorage通常有5MB的存储空间，我们以微信文章页为例。

查看请求发现，基本没有js和css的请求，因为它把全部的不需要改动的资源都放到了localStorage中：

所以微信的文章页加载非常的快。

前端数据库

前端数据库有WebSql和IndexDB，其中WebSql被规范废弃，他们都有大约50MB的最大容量，可以理解为localStorage的加强版。

应用缓存

应用缓存主要是通过manifest文件来注册被缓存的静态资源，已经被废弃，因为它的设计有些不合理的地方，它在缓存静态文件的同时，也会默认缓存html文件。这导致页面的更新只能通过manifest文件中的版本号来决定。所以，应用缓存只适合那种常年不变化的静态网站。如此的不方便，也是被废弃的重要原因。

PWA也运用了该文件，不同于manifest简单的将文件通过是否缓存进行分类，PWA用manifest构建了自己的APP骨架，并运用Servie Worker来控制缓存，这也是今天的主角。

Service Worker

Service Worker本质上也是浏览器缓存资源用的，只不过它不仅仅是cache，也是通过worker的方式来进一步优化。

他基于h5的web worker，所以绝对不会阻碍当前js线程的执行，sw最重要的工作原理就是

1、后台线程：独立于当前网页线程；

2、网络代理：在网页发起请求时代理，来缓存文件；

兼容性

可以看到，基本上新版浏览器还是兼容滴。之前是只有chrome和firefox支持，现在微软和苹果也相继支持了。

成熟程度

判断一个技术是否值得尝试，肯定要考虑下它的成熟程度，否则过一段时间又和应用缓存一样被规范抛弃就尴尬了。

所以这里我列举了几个使用Service Worker的页面：

淘宝

网易新闻

考拉

所以说还是可以尝试下的。

调试方法

一个网站是否启用Service Worker，可以通过开发者工具中的Application来查看：

被Service Worker缓存的文件，可以在Network中看到Size项为 from ServiceWorker：

也可以在Application的Cache Storage中查看缓存的具体内容：

如果是具体的断点调试，需要使用对应的线程，不再是main线程了，这也是webworker的通用调试方法：

使用条件

sw 是基于 HTTPS 的，因为service worker中涉及到请求拦截，所以必须使用HTTPS协议来保障安全。如果是本地调试的话，localhost是可以的。

而我们刚好全站强制https化，所以正好可以使用。

生命周期

大概可以用如下图片来解释：

注册

要使用Service worker，首先需要注册一个sw，通知浏览器为该页面分配一块内存，然后sw就会进入安装阶段。

一个简单的注册方式：

(function() {
    if('serviceWorker' in navigator) {
        navigator.serviceWorker.register('./sw.js');
    }
})()

当然也可以考虑全面点，参考网易新闻的注册方式：

"serviceWorker" in navigator && window.addEventListener("load",
    function() {
        var e = location.pathname.match(/\/news\/[a-z]{1,}\//)[0] + "article-sw.js?v=08494f887a520e6455fa";
        navigator.serviceWorker.register(e).then(function(n) {
            n.onupdatefound = function() {
                var e = n.installing;
                e.onstatechange = function() {
                    switch (e.state) {
                        case "installed":
                            navigator.serviceWorker.controller ? console.log("New or updated content is available.") : console.log("Content is now available offline!");
                            break;
                        case "redundant":
                            console.error("The installing service worker became redundant.")
                    }
                }
            }
        }).
        catch(function(e) {
            console.error("Error during service worker registration:", e)
        })
    })

前面提到过，由于sw会监听和代理所有的请求，所以sw的作用域就显得额外的重要了，比如说我们只想监听我们专题页的所有请求，就在注册时指定路径：

navigator.serviceWorker.register('/topics/sw.js');

这样就只会对topics/下面的路径进行优化。

installing

我们注册后，浏览器就会开始安装sw，可以通过事件监听：

//service worker安装成功后开始缓存所需的资源
var CACHE_PREFIX = 'cms-sw-cache';
var CACHE_VERSION = '0.0.20';
var CACHE_NAME = CACHE_PREFIX+'-'+CACHE_VERSION;
var allAssets = [
    './main.css'
];
self.addEventListener('install', function(event) {

    //调试时跳过等待过程
    self.skipWaiting();


    // Perform install steps
    //首先 event.waitUntil 你可以理解为 new Promise，
    //它接受的实际参数只能是一个 promise，因为,caches 和 cache.addAll 返回的都是 Promise，
    //这里就是一个串行的异步加载，当所有加载都成功时，那么 SW 就可以下一步。
    //另外，event.waitUntil 还有另外一个重要好处，它可以用来延长一个事件作用的时间，
    //这里特别针对于我们 SW 来说，比如我们使用 caches.open 是用来打开指定的缓存，但开启的时候，
    //并不是一下就能调用成功，也有可能有一定延迟，由于系统会随时睡眠 SW，所以，为了防止执行中断，
    //就需要使用 event.waitUntil 进行捕获。另外，event.waitUntil 会监听所有的异步 promise
    //如果其中一个 promise 是 reject 状态，那么该次 event 是失败的。这就导致，我们的 SW 开启失败。
    event.waitUntil(
        caches.open(CACHE_NAME)
            .then(function(cache) {
                console.log('[SW]: Opened cache');
                return cache.addAll(allAssets);
            })
    );

});

安装时，sw就开始缓存文件了，会检查所有文件的缓存状态，如果都已经缓存了，则安装成功，进入下一阶段。

activated

如果是第一次加载sw，在安装后，会直接进入activated阶段，而如果sw进行更新，情况就会显得复杂一些。流程如下：

首先老的sw为A，新的sw版本为B。B进入install阶段，而A还处于工作状态，所以B进入waiting阶段。只有等到A被terminated后，B才能正常替换A的工作。

这个terminated的时机有如下几种方式：

1、关闭浏览器一段时间；

2、手动清除serviceworker；

3、在sw安装时直接跳过waiting阶段

//service worker安装成功后开始缓存所需的资源
self.addEventListener('install', function(event) {
    //跳过等待过程
    self.skipWaiting();
});

然后就进入了activated阶段，激活sw工作。

activated阶段可以做很多有意义的事情，比如更新存储在cache中的key和value：

var CACHE_PREFIX = 'cms-sw-cache';
var CACHE_VERSION = '0.0.20';
/**
 * 找出对应的其他key并进行删除操作
 * @returns {*}
 */
function deleteOldCaches() {
    return caches.keys().then(function (keys) {
        var all = keys.map(function (key) {
            if (key.indexOf(CACHE_PREFIX) !== -1 && key.indexOf(CACHE_VERSION) === -1){
                console.log('[SW]: Delete cache:' + key);
                return caches.delete(key);
            }
        });
        return Promise.all(all);
    });
}
//sw激活阶段,说明上一sw已失效
self.addEventListener('activate', function(event) {


    event.waitUntil(
        // 遍历 caches 里所有缓存的 keys 值
        caches.keys().then(deleteOldCaches)
    );
});

idle

这个空闲状态一般是不可见的，这种一般说明sw的事情都处理完毕了，然后处于闲置状态了。

浏览器会周期性的轮询，去释放处于idle的sw占用的资源。

fetch

该阶段是sw最为关键的一个阶段，用于拦截代理所有指定的请求，并进行对应的操作。

所有的缓存部分，都是在该阶段，这里举一个简单的例子：

//监听浏览器的所有fetch请求，对已经缓存的资源使用本地缓存回复
self.addEventListener('fetch', function(event) {
    event.respondWith(
        caches.match(event.request)
            .then(function(response) {
                //该fetch请求已经缓存
                if (response) {
                    return response;
                }
                return fetch(event.request);
                }
            )
    );
});

生命周期大概讲清楚了，我们就以一个具体的例子来说明下原生的serviceworker是如何在生产环境中使用的吧。

本篇文章未完结，请见下一篇

网站首页 > 博客文章正文

使用Service Worker让你的 Web 应用如虎添翼(上)「干货」

目录

前言

前端缓存简介

http缓存

Expires

Cache-Control

Last-Modified / If-Modified-Since

Etag / If-None-Match

浏览器缓存

storage

前端数据库

应用缓存

Service Worker

兼容性

成熟程度

调试方法

使用条件

生命周期

注册

installing

activated

idle

fetch

推荐JavaScript经典实例学习资料文章

猜你喜欢

本文暂时没有评论，来添加一个吧(●'◡'●)

取消回复欢迎你发表评论:

网站首页 > 博客文章 正文

使用Service Worker让你的 Web 应用如虎添翼(上)「干货」

目录

前言

前端缓存简介

http缓存

Expires

Cache-Control

Last-Modified / If-Modified-Since

Etag / If-None-Match

浏览器缓存

storage

前端数据库

应用缓存

Service Worker

兼容性

成熟程度

调试方法

使用条件

生命周期

注册

installing

activated

idle

fetch

推荐JavaScript经典实例学习资料文章

猜你喜欢

本文暂时没有评论，来添加一个吧(●'◡'●)

取消回复欢迎 你 发表评论:

网站首页 > 博客文章正文

取消回复欢迎你发表评论: