移动PWA初探

在去年上海举办的2017谷歌开发者大会上，PWA作为会议的一个重要内容被推介，笔者作为参会嘉宾看了PWA的内容后，觉得这种技术会是未来移动发展的一个趋势。Google开发技术推广工程师Michael Yeung介绍称，新浪微博正在打造一款全新体验的Web Mobile PWA应用，读者可以通过微博提供的PWA版访问网址：m.weibo.cn/beta。

在当前的移动跨平台开发方案中，主要的技术有PWA和Weex、RN（这个笔者在16年专门进行了研究，并出版了相关的书籍）。不过纵观这些移动技术可以发现，PWA是优化web app，RN是用web调用native思路，weex还是使用web栈调用native的思路。

在移动碎片化严重的当前，如何制定一个统一的标准，才是为了移动技术发展的方向，也就是说：“Web不会趋向于Native，而是Native趋向于Web”。

PWA简介

PWA全称Progressive Web Apps（渐进式网络应用），该项目由谷歌在2015年主导推出，主要的特性是让Web App的体验能更接近原生应用，显著提高应用加载速度，甚至可以在离线状态下运行，多种手机/PC浏览器已支持加载PWA网页。

所谓的P（Progressive）这里有两层含义，一方面是渐进增强，让WEB APP的体验和功能能够用渐进增强的方式来更接近原生APP的体验及功能；另一方面是指下一代WEB技术，PWA并不是描述一个技术，而是一些技术的合集。PWA 本质上是 Web App，借助一些新技术也具备了 Native App 的一些特性，兼具 Web App 和 Native App 的优点。

PWA 的主要特点包括下面三点：

可靠 - 即使在不稳定的网络环境下，也能瞬间加载并展现

体验 - 快速响应，并且有平滑的动画响应用户的操作

粘性 - 像设备上的原生应用，具有沉浸式的用户体验，用户可以添加到桌面

PWA 本身强调渐进式，并不要求一次性达到安全、性能和体验上的所有要求，开发者可以通过 PWA Checklist 查看现有的特征。

PWA特性

下面就从安全、性能和体验三个方面来介绍PWA所具有的特性。

可靠

当用户打开我们站点时（从桌面 icon 或者从浏览器），通过 Service Worker 能够让用户在网络条件很差的情况下也能瞬间加载并且展现。

Service Worker 是用 JavaScript 编写的 JS 文件，能够代理请求，并且能够操作浏览器缓存，通过将缓存的内容直接返回，让请求能够瞬间完成。开发者可以预存储关键文件，可以淘汰过期的文件等等，给用户提供可靠的体验。

更详细的内容可以访问： Service Worker

体验

如果站点加载时间超过 3s，53% 的用户会放弃等待。页面展现之后，用户期望有平滑的体验，过渡动画和快速响应。

为了保证首屏的加载，我们需要从设计上考虑，在内容请求完成之前，可以优先保证 App Shell 的渲染，做到和 Native App 一样的体验，App Shell 是 PWA 界面展现所需的最小资源。

更多的资料可以参考： App Shell 设计规范

粘性

PWA具有的粘性表现在如下几个方面：

• PWA 是可以安装的，用户点击安装到桌面后，会在桌面创建一个 PWA 应用，并且不需要从应用商店下载；
• PWA 可以借助 Web App Manifest 提供给用户和 Native App 一样的沉浸式体验；
• PWA 可以通过给用户发送离线通知，让用户回流。

同时，Web App Manifest 允许开发者控制 PWA 添加到桌面，允许定制桌面图标、URL等等。

关于Web App Manifest更多的内容可以参考：Web App Manifest和Push Notification。

其他

除此之外，讲到 PWA 兼具 Web App 和 Native App 的特征的，Web App 无版本问题、可索引也是很重要的特性。

总结一下，PWA 具有下面一些特性：

• 渐进式 - 适用于所有浏览器，因为它是以渐进式增强作为宗旨开发的。
• 连接无关性 - 能够借助 Service Worker 在离线或者网络较差的情况下正常访问。
• 类似应用 - 由于是在 App Shell 模型基础上开发，因为应具有 Native App 的交互和导航，给用户 Native App的体验。
• 持续更新 - 始终是最新的，无版本和更新问题。
• 安全 - 通过 HTTPS 协议提供服务，防止窥探和确保内容不被篡改。
• 可索引 - 应用清单文件和 Service Worker 可以让搜索引擎索引到，从而将其识别为『应用』。
• 粘性 - 通过推送离线通知等，可以让用户回流。
• 可安装 - 用户可以添加常用的 webapp 到桌面，免去去应用商店下载的麻烦。
• 可链接 - 通过链接即可分享内容，无需下载安装。

PWA 是对站点体验的一个飞跃式的提升，可以在移动设备上的 Chrome(version > 52) 访问 天气PWA 体验一下。

渐进式

所谓渐进式，就是逐步的改善，不是一蹴而就的，采取这种方案，主要有两点原因：

• 降低站点改造的代价，逐步支持各项新技术，不要一蹴而就；
• 新技术标准的支持度还不完全，新技术的标准还未完全确定。

所以，从改造的成本考虑，我们也建议采取渐进式的方式，可以考虑按照下面的步骤来改造：

• 第一步，应该是安全，将全站 HTTPS 化，因为这是 PWA 的基础，没有 HTTPS，就没有 Service Worker
• 第二步，应该是 Service Worker 来提升基础性能，离线提供静态文件，把用户首屏体验提升上来
• 第三步，App Manifest，这一步可以和第二步同时进行 后续，再考虑其他的特性，离线消息推送等

同时，PWA作为最新的不太成熟的技术，当前浏览器还没有达到完全支持的程度，W3C 关于这些技术的标准也还在处于草稿状态，没有定稿。根据知名统计网站Can I use的统计，对PWA相关技术的支持程度如下：

• App Manifest 的支持度达到 57.43%；
• Service Worker 的支持度达到 72.82%；
• Notifications API 的支持度达到 43.3%；
• Push API 的支持度达到 72.39%；
• Background Sync 暂未统计到，Chrome 49 以上均支持。

比较遗憾的是上面提到的所有技术，目前只有 Android 的部分浏览器支持，iOS 的Safari暂不支持，不过，Safari 浏览器已经在考虑了。

Service Worker

W3C 组织早在 2014 年 5 月就提出过 Service Worker 这样的一个 HTML5 API ，主要用来做持久的离线缓存。对于API相关的内容，这里仔细整理了一下：浏览器中的 javaScript 都是运行在一个单一主线程上的，在同一时间内只能做一件事情。随着 Web 业务不断复杂，我们逐渐在 js 中加了很多耗资源、耗时间的复杂运算过程，这些过程导致的性能问题在 WebApp 的复杂化过程中更加凸显出来。

W3C 组织早早的洞察到了这些问题可能会造成的影响，这个时候有个叫 Web Worker 的 API 被造出来了，这个 API 的唯一目的就是解放主线程，Web Worker 是脱离在主线程之外的，将一些复杂的耗时的活交给它干，完成后通过 postMessage 方法告诉主线程，而主线程通过 onMessage 方法得到 Web Worker 的结果反馈。

一切问题好像是解决了，但 Web Worker 是临时的，我们能不能有一个东东是一直持久存在的，并且随时准备接受主线程的命令呢？基于这样的需求推出了最初版本的 Service Worker ，Service Worker 在 Web Worker 的基础上加上了持久离线缓存能力。当然在 Service Worker 之前也有在 HTML5 上做离线缓存的 API 叫 AppCache, 但是 AppCache 存在很多 不能忍受的缺点。

W3C 决定 AppCache 仍然保留在 HTML 5.0 Recommendation 中，在 HTML 后续版本中移除。

Issue: https://github.com/w3c/html/issues/40

Mailing list: https://lists.w3.org/Archives/Public/public-html/2016May/0005.html

WHATWG HTML5 作为 Live Standard，也将 AppCache 标注为 Discouraged 并引导至 Service Worker。Ok ，那么 Service Worker 到底用来干啥的呢？

Service Worker 有以下功能和特性：

• 一个独立的 worker 线程，独立于当前网页进程，有自己独立的 worker context。
• 一旦被 install，就永远存在，除非被 uninstall。
• 需要的时候可以直接唤醒，不需要的时候自动睡眠（有效利用资源，此处有坑）。
• 可编程拦截代理请求和返回，缓存文件，缓存的文件可以被网页进程取到（包括网络离线状态）。
• 离线内容开发者可控。
• 能向客户端推送消息。
• 不能直接操作 DOM。
• 出于安全的考虑，必须在 HTTPS 环境下才能工作。
• 异步实现，内部大都是通过 Promise 实现。

所以我们基本上知道了 Service Worker 的伟大使命，就是让缓存做到优雅和极致，让 Web App 相对于 Native App 的缺点更加弱化，也为开发者提供了对性能和体验的无限遐想。

浏览器Service Worker支持情况

根据Can I use发现，目前市场上对Service Worker的支持情况如下：

从这张图可以发现，Chrome 作为开路先锋早早的在 V40 版本就支持了，还提供了完善的 debug 方案（ Service Worker debug ）；Firefox，Opera 不甘示弱在后续版本也进行了支持；安卓手机 4.x 以上版本新系统形势一片大好（具体各手机的实现还得进一步探测）；安卓 Chrome 同样给力；但是目前IE和Safair是不支持的，不过已经被列入未来的支持计划中。

Service Worker使用

Service Worker 出于安全性和其实现原理，在使用的时候有一定的前提条件。

• 由于 Service Worker 要求 HTTPS 的环境，我们通常可以借助于 github page 进行学习调试。当然一般浏览器允许调试 Service Worker 的时候 host 为 localhost 或者 127.0.0.1 也是 ok 的。
• Service Worker 的缓存机制是依赖 Cache API 实现的。
• 依赖 HTML5 fetch API。
• 依赖 Promise 实现。

Service Worker注册

要安装 Service Worker， 我们需要通过在 js 主线程（常规的页面里的 js ）注册 Service Worker 来启动安装，这个过程将会通知浏览器我们的 Service Worker 线程的 javaScript 文件在什么地方呆着。先看一段代码： 、`if ('serviceWorker' in navigator) { window.addEventListener('load', function () { navigator.serviceWorker.register('/sw.js', {scope: '/'}) .then(function (registration) {

            // 注册成功
            console.log('ServiceWorker registration successful with scope: ', registration.scope);
        })
        .catch(function (err) {

            // 注册失败:(
            console.log('ServiceWorker registration failed: ', err);
        });
});

}`