PWA笔记二:离线缓存原理

ServiceWorker既然命名为worker,很大一部分原因就是它和WebWorker相关。它是在第二个线程完成缓存代理的任务,不会影响dom渲染的主线程,两个Worker之间的通讯是基于postMessage,两个线程是不能直接进行通讯。

这一点和小程序有点像,但是又不一样。 小程序是把渲染层和逻辑层用两个线程进行分离。逻辑层的报错,并不会影响渲染层的展示,具体这么做能够提升多少优化量,微信团队并没有给出一个很确切的数据统计。PWA使用worker更多是为了处理离线缓存的内容,并且会使用indexedDB来存缓存文件的版本编号,UI的渲染层和逻辑层(可以被称之为主线层)并没有得到分离。

前提条件

基于HTTPS

HTTPS 不仅仅可以保证你网页的安全性,还可以让一些比较敏感的 API 完美的使用。值得一提的是,SW 是基于 HTTPS 的,所以,如果你的网站不是 HTTPS,那么基本上你也别想了 SW。

Scope作用域

一个sw.js并不能接管一个站点所有的页面,它只能在所在路由底下起到作用。意思就是如果你在//example.com/foo/bar.js里注册了一个 SW,那么它默认的作用域为//example.com/foo/

SPA

虽然说PWA可以使用在多页面应用(MPA)上,一个sw文件和一个manifest文件主要的设计理念在于搭配着用在SPA,SW在SPA使用更合理。

生命周期

注册

ServiceWorker.js(又名sw.js)是一个独立js,页面注册在浏览器支持的情况下,注册sw.js来控制Service Worker缓存。register将会触发安装声明周期,所有的源码都是有原生浏览器实现。

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js').then(function(registration) {
    console.log('ServiceWorker registration successful with scope: ',    registration.scope);
  }).catch(function(err) {
    console.log('ServiceWorker registration failed: ', err);
  });
}

install

注册完成后会出发安装的生命周期,把设置好的静态文件,采用Service Worker的缓存方式,使用了Cache API来将资源缓存起来,同时使用e.waitUntil接手一个Promise来等待资源缓存成功,等到这个Promise状态成功后,ServiceWorker进入installed状态,意味着安装完毕。这时候主线程中返回的registration.waiting属性代表进入installed状态的ServiceWorker。

var CACHE_NAME = "my_cache";
var urlsToCache = [
  '/index.html',
  '/css/style.css',
  '/js/script.js'
];
//这里的self代表ServiceWorkerGlobalScope
self.addEventListener('install', function(event) {
//这里的waitUtil会在安装成功之前执行一些预装的操作,但是只建议做一些轻量级和非常重要资源的缓存,减少安装失败的概率。安装成功
//后ServiceWorker状态会从installing变为installed 
event.waitUntil(
        caches.open(CACHE_NAME).then(function(cache) {
             console.log('Opendhe : ',cache);
            return cache.addAll(urlsToCache);
      })
    );
});

skipWaiting

skipWaiting()意味着新 SW 控制了之前用旧 SW 获取的页面,也就是说你的页面有一部分资源是通过旧 SW 获取,剩下一部分是通过新 SW 获取.

activate

安装完,则会进入激活状态。如果之前已有ServiceWorker,这个版本只是对ServiceWorker进行了更新。如果你在event.waitUntil()中传入了一个 Promise,SW 将会缓存住功能性事件(fetch,push,sync等等),直到 Promise 返回 resolve 的时候再触发,也就是说,当你的fetch事件被触发的时候,SW 已经被完全激活了。

self.addEventListener('activate', event => {
  event.waitUntil(
    caches.keys().then(keys => Promise.all(
      keys.map(key => {
        if (!expectedCaches.includes(key)) {
          return caches.delete(key);
        }
      })
    )).then(() => {
      // V2控制缓存
    })
  );
});

fetch

fetch请求是有别于xhr请求,sw提供监听拦截fetch的事件,对于命中缓存的数据可以直接返回请求。当接受到 fetch 请求时,会直接返回event.respondWith 得到Promise 结果。这样我们可以捕获页面所有的 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);
      }
    )
  );
});

redundant

Service Worker 可能以下之一的原因而被废弃(redundant,原意为“多余的,累赘的”)——

  • installing 事件失败
  • activating 事件失败
  • 新的 Service Worker 替换其成为激活态 worker

调试方法

方法一

chrome://inspect/#service-workers 就可以查看当前浏览器正在注册的 SW,并且可以对它们进行调试和结束进程。调试会直接在service worker线程进行,不用理会主线层的逻辑。

调试Service worker

方法二

另外,还有 chrome://serviceworker-internals,用来查看当前浏览器中所有注册过的 SW。输入这个地址就像打开新世界的大门,原来你访问那么多PWA页面。

所有注册过的service worker

方法三

在打开chrome的调试面板devtools,Application tab里面有个service workers页面,可以针对该页面的SW,进行缓存调试以及消息推送,在这里也可以看到SW所在的生命周期,大大提高SW的调试效率。

chrome查看缓存情况

更新问题

浏览器获取了新版本的ServiceWorker代码,如果浏览器本身对sw.js进行缓存的话,也不会得到最新代码,所有代码会变成死代码无法更新。这里有两种解决方案:

  1. 在ngnix或cdn的缓存配置中,sw文件最好配置成cache-control: no-cache
  2. 采用sw-register-webpack-plugin来处理sw文件的更新问题。

参考