重点关注关键场景
1、目标应用场景
移动端（脆弱的网络连接和不同的人机交互方式）
2、关键技术和优势
| 显著提高应用加载速度、让 web 应用可以在离线环境使用 | Service Worker & Cache Storage |
| 描述 web 应用元数据、让 web 应用能够像原生应用一样添加到主屏、全屏运行 | Web App Manifest |
| 进一步提高 web 应用于操作系统集成能力、让 web 应用能够在未被激活时发起消息通知 | Push API & Notification API |
3、解决了什么问题
- 无需担心网络延迟；
- 有着独立入口与独立的保活机制。
4、技术要点
W3C Web App Manifest
{
"short_name": "Manifest Sample",
"name": "Web Application Manifest Sample",
"icons": [{
"src": "launcher-icon-2x.png",
"sizes": "96x96",
"type": "image/png"
}],
"scope": "/sample/",
"start_url": "/sample/index.html",
"display": "standalone",
"orientation": "landscape",
"theme_color": "#000",
"background_color": "#fff",
}
<!-- document -->
<link rel="manifest" href="/manifest.json">
Service Worker 基本架构
通常遵循以下基本步骤来使用 service workers：
- service worker URL 通过 serviceWorkerContainer.register() 来获取和注册。
- 如果注册成功，service worker 就在 ServiceWorkerGlobalScope 环境中运行； 这是一个特殊类型的 woker 上下文运行环境，与主运行线程（执行脚本）相独立，同时也没有访问 DOM 的能力。
- service worker 现在可以处理事件了。
- 受 service worker 控制的页面打开后会尝试去安装 service worker。最先发送给 service worker 的事件是安装事件(在这个事件里可以开始进行填充 IndexDB和缓存站点资源)。这个流程同原生 APP 或者 Firefox OS APP 是一样的 — 让所有资源可离线访问。
- 当 oninstall 事件的处理程序执行完毕后，可以认为 service worker 安装完成了。
- 下一步是激活。当 service worker 安装完成后，会接收到一个激活事件(activate event)。 onactivate 主要用途是清理先前版本的service worker 脚本中使用的资源。
- Service Worker 现在可以控制页面了，但仅是在 register() 成功后的打开的页面。也就是说，页面起始于有没有 service worker ，且在页面的接下来生命周期内维持这个状态。所以，页面不得不重新加载以让 service worker 获得完全的控制。
