Progressive Web Apps

2024-02-27 15:42:51

一.What?


A new way to deliver amazing user experiences on the web.

一种提升Web用户体验的方式。除了Web天生的（便捷）体验外，还有3个特点：Reliable, Fast, Engaging

可靠：在不确定的网络环境下，也能立即加载，而不会（因为断网而）瞬间回到远古时代

可靠指的是离线缓存，断网状态走缓存，保证离线场景仍然可用，service worker配合cache API建立缓存-代理机制

快速：迅速以丝滑的动画作为交互反馈，而不存在掉帧卡顿的滚动

快速，只是强调交互反馈“感觉快”，与推崇的Material Design有关，并没有真正的速度优势（至少首屏没有）

另外，得益于缓存-代理机制，再次访问时走本地缓存会相当快

类native：像设备原生App一样，具有沉浸式的用户体验（即全屏）

除了全屏外，还有主屏图标（让Web App在主屏幕有一席之地）和系统通知（“拉活”的能力），通过Web App Manifest配置来实现，依赖用户环境支持

P.S.Engaging这个抽象形容词真不好翻译，这里暂且取其实际意义，类native

所以，表面上看，PWA的亮点分2部分：

（离线）缓存-代理机制

全屏，主屏图标和系统通知等类native特性

缓存机制在Web App/SPA里一点不新鲜，抽离出数据层之后，缓存顺手就做了。但侧重点不同，PWA的缓存机制偏向于静态资源缓存，而Web App/SPA的缓存层多用来做动态内容缓存（上次的内容没过期的话，不再重新获取动态部分，而是直接做客户端渲染）

至于全屏，主屏图标以及系统通知等类native特性，算是渐进增强中的增强，在支持的用户环境是可用的（一些浏览器提供了支持，但更广泛的WebView环境在不久的将来可能还是不行）。但这表明Web正在以渐进增强的方式走出PC时代，向着移动化发展

二.试玩
依赖环境
HTTPS

要求服务源必须是安全的，所以需要HTTPS环境。除了出于Web信息安全的考虑，想要推进HTTPS普及也是一个重要原因，HTTPS作为Web技术发展的必要基础设施，对于拍照，录音，push API等新特性，都需要获得用户许可，而HTTPS是权限工作流的关键部分，必不可少

P.S.在permission.site能够体验到HTTPS与HTTP环境在获取用户授权方面的差异

类native增强
通过引入Web App Manifest配置文件来实现类native增强，在支持PWA的浏览器生效（在不支持的环境最坏结果也就是多请求一个JSON文件）：

<link rel="manifest" href="./manifest.json">
注意，有个比较相似的东西，叫Application Cache（HTML5特性，已过时），其manifest引入方式不同：


<html manifest="example.appcache">
  ...
</html>

因为二者引入方式不同，所以Web App Manifest与Application Cache是不相干的，没有历史包袱的后顾之忧

P.S.Application Cache对SPA支持较好，对多页应用则不适用，但存在很多问题，这里不多做介绍

主屏图标
Web App Manifest内容示例如下：


{
  "short_name": "主屏显示的应用名称",
  "name": "安装banner显示的应用名称",
  "icons": [
    {
      "src": "launcher-icon-1x.png",
      "type": "image/png",
      "sizes": "48x48",
      "density": "1.0"
    },
    {
      "src": "launcher-icon-2x.png",
      "type": "image/png",
      "sizes": "96x96",
      "density": "1.0"
    },
    {
      "src": "launcher-icon-4x.png",
      "type": "image/png",
      "sizes": "192x192",
      "density": "1.0"
    }
  ],
  "start_url": "index.html?launcher=true"
}

P.S.安装banner是指一个类似于获取权限的弹出面板，用户可以选择添加至主屏幕或取消，满足一定条件的话，Chrome会自动弹出安装banner，具体见Web App Install Banners

这样理想情况下我们就拥有了主屏图标，支持Web App Manifest的环境会选用最合适的（最接近48dp的）图标

注意：index.html里的内容应该是首屏渲染需要的最小化内容，为了达到首屏立即加载的效果，可以把带loading和默认占位图的页面框架作为App Shell展示出来。另外，为了达到秒开可用的首屏性能，Web App首屏性能优化其它常规手段在PWA也是推荐使用的，比如数据直出。如开篇所说，PWA并没有天生的（首屏）性能优势，Web App适用的常规优化手段仍然是必要的

闪屏（Splash）
从主屏图标进入，可定制的启动过程显示内容包括：标题，背景色和图像。新配置项如下：


// 背景色
"background_color": "#2196F3",
// 主题色，包括工具栏
"theme_color": "#2196F3",

图像从icons中选取最接近128dp的图像作为闪屏，不支持动图

另外，还可以指定显示模式和页面方向：


// 全屏（隐藏浏览器的UI）
"display": "standalone",
// 显示浏览器外壳，像打开书签一样
"display": "browser",
// 横屏
"orientation": "landscape"

P.S.关于闪屏的示例及更多信息请查看Adding a Splash Screen for Installed Web Apps in Chrome 47

特别注意：如果manifest.json文件有更新，这些改动不会自动生效，除非用户重新添加应用到主屏

系统通知
与Web App Manifest无关，依赖Push API。简单示例如下：


// service-worker.js
self.addEventListener("push", function (event) {
  event.waitUntil(
    self.self.registration.showNotification("发布新文章啦", {
      body: "有新文章发布啦,点击查看。"
    })
  );
});

这里不多做介绍（目前（2017/12/15）几乎可以认为这个特性不存在），因为规范定义了API，但没规定统一个push协议，所以各家浏览器的push机制不同，比如Chrome的GCM在我们这片天空下就不可用

关于Push API的更多信息，请查看【Service Worker】消息推送功能“全军覆没”

缓存-代理
缓存分为几部分：

首屏静态资源缓存（预缓存）

已访问资源缓存（运行时缓存）

动态内容缓存（运行时缓存）

缓存是纯数据操作（包括持久化），而service worker能够在后台运行，尤其适合处理这种与页面及交互无关的事情，所以service worker与Cache API，Push API成了搭档。但service worker自身也应该看做“增强”项，在不支持service worker的环境应该跳过缓存机制保证基本的页面体验，简单的特征检测方案如下：


if ('serviceWorker' in navigator) {
  navigator.serviceWorker
           .register('./service-worker.js')
           .then(function() { console.log('Service Worker Registered'); });
}

service worker在install事件处理器完成包括App Shell在内的首屏静态资源缓存：


// service-worker.js
var cacheName = 'weatherPWA-step-6-1';
var filesToCache = [
  // 入口URL
  '/',
  '/index.html',
  '/scripts/app.js',
  '/styles/inline.css',
  // App Shell需要的资源
  '/images/ic_add_white_24px.svg',
  '/images/ic_refresh_white_24px.svg',
  // 内容展示可能用到的资源
  '/images/clear.png',
  '/images/cloudy-scattered-showers.png',
  '/images/cloudy.png',
  '/images/fog.png',
  '/images/partly-cloudy.png',
  '/images/rain.png',
  '/images/scattered-showers.png',
  '/images/sleet.png',
  '/images/snow.png',
  '/images/thunderstorm.png',
  '/images/wind.png'
];

self.addEventListener('install', function(e) {
  console.log('[ServiceWorker] Install');
  e.waitUntil(
    caches.open(cacheName).then(function(cache) {
      console.log('[ServiceWorker] Caching app shell');
      //! 只要有一个失败就不接着做下一个了
      return cache.addAll(filesToCache);
    })
  );
});

当然，还需要对缓存做基本的版本控制：


// service-worker.js
self.addEventListener('activate', function(e) {
  console.log('[ServiceWorker] Activate');
  e.waitUntil(
    caches.keys().then(function(keyList) {
      return Promise.all(keyList.map(function(key) {
        // 以为cacheName为cache key，如果存在旧的缓存，删除掉
        if (key !== cacheName) {
          console.log('[ServiceWorker] Removing old cache', key);
          return caches.delete(key);
        }
      }));
    })
  );
  // 要求立即激活service worker，避免边界case
  return self.clients.claim();
});

P.S.边界case指的是某些情况下service worker无法立刻恢复激活态，导致不走缓存。为了屏蔽这些边界case，推荐使用GoogleChromeLabs/sw-precache帮助处理缓存控制问题（包括过期，更新策略等等）

缓存有了，接下来实现代理部分，拦截请求，并把缓存内容作为响应：


// service-worker.js
// 拦截请求
self.addEventListener('fetch', function(event) {
  console.log('[ServiceWorker] Fetch', e.request.url);
  // 自定义响应内容
  e.respondWith(
    // 查找缓存，没有才请求
    caches.match(e.request).then(function(response) {
      return response || fetch(e.request);
    })
  );
});

到这里基本的缓存-代理机制就准备好了，我们做了这些事情：

按资源列表预先缓存静态资源

拦截请求

把缓存内容作为响应给过去

有3个注意事项：

浏览器缓存可能会影响缓存更新，所以install事件处理器中的请求不会走缓存，而是直接进入网络

注销service worker不会清掉缓存，cache key不变的话，之后还会拿到旧的缓存内容

默认新注册的service worker在页面重新载入之后才会生效，除非做特殊处理

另外，我们的简版实现还存在一些问题，例如：

缓存版本控制依赖一个静态的cache key，每次更新service-worker.js都要修改这个key

一旦cache key有变化，会抹掉所有缓存，重新请求一遍，对于静态资源有些浪费

缺少运行时缓存，资源列表不够灵活，期望更强大的边访问边缓存

第1个问题没什么太好的办法，第2个问题可以通过细分资源类型来缓解，例如：


// Shorthand identifier mapped to specific versioned cache.
var CURRENT_CACHES = {
  font: 'font-cache-v' + FONT_CACHE_VERSION,
  css: 'css-cache-v' + CSS_CACHE_VERSION,
  img: 'img-cache-v' + IMG_CACHE_VERSION
};

通过更细粒度的版本控制，能在一定程度上降低强制更新缓存的成本，当然，缓存层下面还有HTTP Cache兜底，缓存更新成本不是非常关键

至于运行时缓存，实际上只需要再做最后一小步就好了：

没命中缓存的话，请求资源并缓存

具体如下：


// 查找缓存，没有才请求
caches.match(e.request).then(function(response) {
  return response || fetch(e.request).then(function(res) {
    return caches.open(dataCacheName).then(function(cache) {
      // 并缓存起来
      cache.put(e.request.url, res.clone());
      return res;
    )
  })
})

另外，还可以根据资源类型及场景要求，针对性的选用合适的缓存策略，例如：


// service-worker.js
self.addEventListener('fetch', function(e) {
  console.log('[Service Worker] Fetch', e.request.url);
  var dataUrl = 'https://cache.domain.com/fresh/';
  // 策略1：有实时性要求的资源，请求优先，fetch then cache
  if (e.request.url.indexOf(dataUrl) > -1) {
    e.respondWith(
      caches.open(dataCacheName).then(function(cache) {
        return fetch(e.request).then(function(response){
          cache.put(e.request.url, response.clone());
          return response;
        });
      })
    );
  } else {
    // 策略2：一般资源，缓存优先，cache falling back to fetch
  }
});

P.S.更多缓存策略，见参考资料部分

三.Demo
官方Demo：Weather PWA，可能无法正常访问

搬运Demo（把官方Demo挪到github pages）：https://ayqy.github.io/pwa/demo/weather-pwa/index.html

P.S.github pages非常适合用作试验田，稳定可靠的HTTPS，发布内容没有任何限制可以随便折腾，以后的博客Demo都会逐步迁移过去（之前一直放在自己的FTP，那可真蠢..）

Progressive Web Apps

weather-pwa

不太乐观的消息：事实上，故意精心准备了用户环境（官方正版Chrome + 官方Demo），在小米4上没有自动弹出安装banner（可能是操作姿势等条件不满足，见上文），手动点击“添加至主屏幕”，toast添加成功，但主屏幕上啥也没有……这就是提不起兴趣手写Demo试玩的原因（当然，主要原因是懒;)）

四.案例
阿里巴巴国际站

AliExpress

饿了么：奇怪，为什么没有感受到Cache的作用呢

注意，隐身模式可能会导致阿里巴巴国际站的service worker抛如下错误：

Uncaught (in promise) DOMException: Quota exceeded.
正常环境可正常体验

P.S.更多案例，请查看Case Studies | Web | Google | Developers

五.应用场景
简言之，PWA算是Web App的升级版，主要亮点是类native支持。以渐进增强的方式，不需要太高成本就能完成Web App到PWA的“升级”，让部分用户（支持PWA的环境）获得更快（缓存）更便捷（主屏图标）的类native体验（全屏）

那么具体应用场景分以下几种：

缓存能带来明显收益的Web App

期望具有离线能力，或类native体验，或者单纯只是想要个主屏图标的Web应用

期望蹭个技术热点/协助推动其发展的Web应用或浏览器供应商

不管应用场景，话说回来，正如zxx某篇关于缓存（还是worker？）的文章所说，这么点儿成本就能让页面获得离线能力，真切看到缓存带来的收益，何乐而不为呢？

另外，Angular，React，Vue等主流框架都提供了PWA脚手架，具体请查看The Ultimate Guide to Progressive Web Applications

参考资料
The offline cookbook：缓存策略图解，好东西，待翻译，就着ServiceWorker Cookbook一起看

如何看待 Progressive Web Apps 的发展前景？

Your First Progressive Web App：官方教程

A Beginner’s Guide To Progressive Web Apps：比较全面的入门指南

改造你的网站，变身PWA：原文Retrofit Your Website as a Progressive Web App

上一篇：PWA全称Progressive Web App，即渐进式WEB应用?


下一篇：多目标优化（三）recsys2020最佳长论文奖Progressive Layered Extraction (PLE)