离线应用的核心是离线缓存技术,历史上曾先后出现2种离线离线缓存技术,它们分别是:
Service Workers 是一个在浏览器后台运行的脚本,它生命周期完全独立于网页。它无法直接访问 DOM,但可以通过 postMessage 接口发送消息来和 UI 进程通信。 拦截网络请求是 Service Workers 的一个重要功能,通过它能完成离线缓存、编辑响应、过滤响应等功能。
目前 Chrome、Firefox、Opera 都已经全面支持 Service Workers,但对于移动端浏览器就不太乐观了,只有高版本的 Android 支持。 由于 Service Workers 无法通过注入 polyfill
去实现兼容,所以在你打算使用它前请先调查清楚你的网页的运行场景。
判断浏览器是否支持 Service Workers 的最简单的方法是通过以下代码:
// 如果 navigator 对象上存在 serviceWorker 对象,就表示支持
if (navigator.serviceWorker) {
// 通过 navigator.serviceWorker 使用
}
要给网页接入 Service Workers,需要在网页加载后注册一个描述 Service Workers 逻辑的脚本。 代码如下:
if (navigator.serviceWorker) {
window.addEventListener('DOMContentLoaded',function() {
// 调用 serviceWorker.register 注册,参数 /sw.js 为脚本文件所在的 URL 路径
navigator.serviceWorker.register('/sw.js');
});
}
一旦这个脚本文件被加载,Service Workers 的安装就开始了。这个脚本被安装到浏览器中后,就算用户关闭了当前网页,它仍会存在。 也就是说第一次打开该网页时 Service Workers 的逻辑不会生效,因为脚本还没有被加载和注册,但是以后再次打开该网页时脚本里的逻辑将会生效。
在 Chrome 中可以通过打开网址 chrome://inspect/#service-workers
来查看当前浏览器中所有注册了的 Service Workers。
Service Workers 在注册成功后会在其生命周期中派发出一些事件,通过监听对应的事件在特点的时间节点上做一些事情。
在 Service Workers 脚本中,引入了新的关键字 self
代表当前的 Service Workers 实例。
在 Service Workers 安装成功后会派发出 install
事件,需要在这个事件中执行缓存资源的逻辑,实现代码如下:
// 当前缓存版本的唯一标识符,用当前时间代替
var cacheKey = new Date().toISOString();
// 需要被缓存的文件的 URL 列表
var cacheFileList = [
'/index.html',
'/app.js',
'/app.css'
];
// 监听 install 事件
self.addEventListener('install', function (event) {
// 等待所有资源缓存完成时,才可以进行下一步
event.waitUntil(
caches.open(cacheKey).then(function (cache) {
// 要缓存的文件 URL 列表
return cache.addAll(cacheFileList);
})
);
});
接下来需要监听网络请求事件去拦截请求,复用缓存,代码如下:
self.addEventListener('fetch', function(event) {
event.respondWith(
// 去缓存中查询对应的请求
caches.match(event.request).then(function(response) {
// 如果命中本地缓存,就直接返回本地的资源
if (response) {
return response;
}
// 否则就去用 fetch 下载资源
return fetch(event.request);
}
)
);
});
以上就实现了离线缓存。
线上的代码有时需要更新和重新发布,如果这个文件被离线缓存了,那就需要 Service Workers 脚本中有对应的逻辑去更新缓存。 这可以通过更新 Service Workers 脚本文件做到。
浏览器针对 Service Workers 有如下机制:
install
事件。新 Service Workers 线程中的 activate 事件就是最佳的清理旧缓存的时间点,代码如下:
// 当前缓存白名单,在新脚本的 install 事件里将使用白名单里的 key
var cacheWhitelist = [cacheKey];
self.addEventListener('activate', function(event) {
event.waitUntil(
caches.keys().then(function(cacheNames) {
return Promise.all(
cacheNames.map(function(cacheName) {
// 不在白名单的缓存全部清理掉
if (cacheWhitelist.indexOf(cacheName) === -1) {
// 删除缓存
return caches.delete(cacheName);
}
})
);
})
);
});
最终完整的代码 Service Workers 脚本代码如下:
See the Pen Service Workers by whjin (@whjin) on CodePen.
用 Webpack 构建接入 Service Workers 的离线应用要解决的关键问题在于如何生成上面提到的 sw.js
文件, 并且sw.js
文件中的 cacheFileList
变量,代表需要被缓存文件的 URL 列表,需要根据输出文件列表所对应的 URL 来决定,而不是像上面那样写成静态值。
假如构建输出的文件目录结构为:
├── app_4c3e186f.js
├── app_7cc98ad0.css
└── index.html
那么 sw.js
文件中 cacheFileList
的值应该是:
var cacheFileList = [
'/index.html',
'app_4c3e186f.js',
'app_7cc98ad0.css'
];
Webpack 没有原生功能能完成以上要求,幸好庞大的社区中已经有人为我们做好了一个插件 serviceworker-webpack-plugin 可以方便的解决以上问题。 使用该插件后的 Webpack 配置如下:
See the Pen serviceworker-webpack-plugin by whjin (@whjin) on CodePen.
以上配置有2点需要注意:
serviceworker-webpack-plugin
插件为了保证灵活性,允许使用者自定义 sw.js
,构建输出的 sw.js
文件中会在头部注入一个变量 serviceWorkerOption.assets
到全局,里面存放着所有需要被缓存的文件的 URL 列表。需要修改上面的 sw.js
文件中写成了静态值的 cacheFileList
为如下:
// 需要被缓存的文件的 URL 列表
var cacheFileList = global.serviceWorkerOption.assets;
以上已经完成所有文件的修改,在重新构建前,先安装新引入的依赖:
npm i -D serviceworker-webpack-plugin webpack-dev-server
安装成功后,在项目根目录下执行 webpack-dev-server
命令后,DevServer 将以 HTTPS 模式启动。