渐进式网页应用（PWA）

PWA

Web应用 VS 本地应用

Service Worker

设计思路

浏览器三大进化路线：

应用程序Web化
Web应用移动化
Web操作系统化

主要说一下第二个：Web应用移动化

对于收集设备来说，前有本地App，后有移动小程序，想要浏览器切入到移动端时相当困难的一件事，因为浏览器的运行性能时低于本地App的，并且Google也没有类似微信或者Facebook体量的用户群体

不过要想切入到移动端，让其取得和原生应用同等待遇，Google提出了PWA

PWA

PWA："(Progressive Web App)"渐进式网页应用

站在Web应用开发者来说，PWA提供了一个渐进式的过渡方案，让普通站点逐步过渡到Web应用。采取了渐进式可以降低站点改造的代价，使得站点逐步支持各项新技术，而不是一步到位
站在技术角度来说，PWA技术也是一个渐进式的演化过程，在技术层面会一点点演进，比如逐渐提供更好的设备支持，不断优化更加流畅的动画效果，不断让页面的加载速度变得更快，不断实现本地应用的特性

PWA采取的是非常缓和的渐进式策略，不像以前那样激进，动不动就取代本地App、取代小程序。与之相反，而是要充分发挥Web的优势，渐进式地缩短和本地应用或者小程序的差距。

所以，PWA可以理解是：一套理念，渐进式增强Web的优势，并通过技术手段渐进式缩短和本地应用或者小程序的差距。

那么：可以通过那些手段去缩短差距呢？

Web应用 VS 本地应用

相对于本地应用，Web页面到底缺少什么？

离线使用能力，在离线或者弱网络环境下基本是无法使用的。而用户需要的是沉浸式的体验，在离线或者弱网环境下能够流畅地使用是用户对一个应用地基本要求
缺少消息推送能力
缺少一级入口，也就是将Web应用安装到桌面，在需要地时候直接从桌面打开Web应用，而不是每次都需要通过浏览器打开

针对以上缺陷，PWA提出了两种解决方案：

Service Worker：试解决离线存储和消息推送
manifest.json：解决一级入口地问题

Service Worker

WebApp请求资源时，会先通过Service Worker，让他判断是返回Service Worker缓存地资源还是重新去网络请求资源。一切控制权交给Service Worker来处理。

设计思路

现在知道了Service Worker的主要功能是拦截请求和缓存资源

架构

前面页面循环系统的分析，知道了JavaScript和页面渲染流水线的任务都是页面主线程上执行的，如果一段JavaScript执行时间过久，那么会阻塞主线程，使得渲染一帧的时间边长，从而让用户产生卡顿的感觉，这对用户来说体验是非常不好的。

为了避免JavaScript过多占用页面主线程时长的问题，浏览器实现了Web Worker的功能。

Web Worker：让JavaScript能够运行在页面主线程之外，不过由于Web Worker中没有当前页面的DOM环境，所以在Web Worker中只能执行一些和DOM无关的JavaScrip脚本，并通过postMessage方法将执行的结果返回给主线程。

“让其运行在主线程之外就是Service Worker来自Web Worker的一个核心思想”。不过Web Worker是临时的，每次JavaScript脚本执行完成之后都会退出，执行结果也不能保存下来，如果下次还有同样的操作，还得重新再来一遍。所以Service Worker需要Web Worker的基础上加上存储功能。

另外，由于Service Worker还需要为多个页面提供服务，所以不能把Service Worker和单个页面绑定起来。

目前，Service Worker是运行在浏览器进程中的，因为浏览器进程生命周期的最长的，所以在浏览器的生命周期内，能够为所有页面提供服务。

消息推送

安全

Service Worker考虑吧到安全，采用的是HTTPS协议，因为通信数据都会经过加密，即便拦截了数据，也无法破解数据内容，而且HTTPS还有校验机制，通信双方很容易知道数据是否被篡改。

除此之外安全方面还有：Web页面默认的安全策略、储入同源策略、内容安全策略（CSP）等