概念

PWA（Progressive Web App，渐进式 Web 应用）：用 Web 技术（HTML/CSS/JavaScript）构建的、能提供接近原生 App 体验的应用。

核心思想：

用一套 Web 代码，同时获得"网页的可达性"（一个链接即可访问）和"原生应用的体验"（可安装、可离线、有推送）。

三大技术支柱

一、Service Worker（核心）

是什么：运行在浏览器后台的一段脚本，独立于页面——它可以拦截和处理网络请求。

能做什么：

1. 离线能力

通过 Cache API 缓存资源，在无网络时返回缓存内容。

这是 PWA 最标志性的能力——断网后应用仍可使用（至少部分功能）。

2. 网络代理与缓存策略

可以精细地控制：

  • Cache First：优先用缓存（适合不常变的静态资源）；
  • Network First：优先网络，失败时用缓存（适合需要新鲜度的数据）；
  • Stale-While-Revalidate：先返回缓存（快），同时后台更新（下次访问时是新内容）；
  • Network Only / Cache Only。

这让开发者能针对不同类型的资源选择最优策略。

3. 后台同步（Background Sync）

用户离线时的操作（如提交表单、发消息），可以排队，等网络恢复后自动同步。

4. 推送通知（Push API）

接收服务器推送的消息并显示通知——即使用户没有打开页面。

二、Web App Manifest

一个 JSON 文件，描述应用的元数据：

{
  "name": "我的应用",
  "short_name": "应用",
  "start_url": "/",
  "display": "standalone",
  "icons": [...],
  "theme_color": "#ffffff"
}

作用：

  • 让浏览器知道这个网站可以被安装；
  • 安装后的图标、名称、启动画面；

  • display 模式：

    • standalone：看起来像原生 App（无浏览器地址栏）；
    • fullscreen：全屏；
    • minimal-ui：最小化的浏览器 UI；
    • browser：普通浏览器标签页。

三、HTTPS

Service Worker 只在安全上下文（HTTPS 或 localhost）中可用。

原因：Service Worker 能拦截和修改网络请求——这是一项强大的能力，如果被中间人劫持，后果严重。

这也是为什么 HTTPS 已经成为 Web 的标准配置。

"渐进式"的含义

Progressive（渐进式）有两层含义：

一、功能渐进增强

  • 在支持 Service Worker 的浏览器上，获得完整体验；
  • 在不支持的浏览器上，仍然是一个能用的网站——只是没有离线和推送。

这与原生 App 形成对比：原生 App 要么装，要么不装。

二、体验渐进升级

用户第一次访问 → 用得多了 → 浏览器提示"添加到主屏幕" → 变成一个有图标的应用。

这个"渐进"的过程，正是 PWA 相对原生 App 的核心优势（见下）。

相对原生 App 的优势

一、无需应用商店

  • 不需要审核（这既是优势也是风险——见下）；
  • 更新即时生效（用户下次打开就是新版）；
  • 不受商店的分成和规则约束。

二、安装门槛低

这是最大的优势。

原生 App 的转化漏斗：看到广告 → 跳转商店 → 下载（几十 MB）→ 安装 → 打开 → 注册。

每增加一步，都流失大量用户。

PWA：点击链接 → 立即使用 → 用得好了再"安装"（几乎是瞬间的）。

在用户获取成本上，这是数量级的差异。

三、体积小

通常远小于原生 App（因为没有内置运行时和原生二进制）。

四、可分享

一个 URL 就能分享——可以发在聊天里、印在海报上、放在搜索结果中。

五、统一代码库

一套代码，覆盖多个平台。

局限与争议

一、iOS 的支持相对滞后

这是 PWA 长期面临的最大问题。

  • Safari 对 Service Worker 和 Manifest 的支持晚于 Chrome，且能力相对受限；
  • 推送通知在 iOS 上的支持较晚才加入，且要求先"添加到主屏幕"；
  • 后台能力受限；
  • 一些 API（如后台同步、某些硬件访问）在 iOS 上不可用或行为不同。

这使得"用 PWA 完全替代原生 App"在 iOS 上往往不现实。

二、无法访问所有系统能力

Web 平台的 API 在持续扩展（如文件系统访问、蓝牙、USB、NFC、相机、地理定位、剪贴板等），但：

  • 仍有一些原生能力无法访问或受限；
  • 某些 API 的浏览器兼容性不一致。

近年来 Web Capabilities Project（"Project Fugu"）正在系统性地补齐这些能力。

三、性能

  • 经过良好优化的 PWA 可以非常流畅；
  • 但在计算密集型场景（如复杂的 3D 游戏、实时视频处理）上，原生仍有优势；
  • WebAssembly（后文会提到）正在缩小这一差距。

四、发现性

PWA 不在应用商店里——这意味着失去了商店带来的"自然流量"，但也意味着不必付分成。

五、苹果的政策风险

由于 iOS 上的所有浏览器引擎实质上都受 WebKit 限制（在部分地区由于监管要求有所变化），PWA 的能力上限取决于 Apple 的实现。

现实中的应用

成功的案例：

  • 星巴克：PWA 让订单量增加，且体积远小于原生 App；
  • Twitter Lite：在低带宽市场表现良好；
  • Pinterest：显著提升了核心指标。

共同特点：这些多是内容/交易型应用（电商、社交、资讯、工具），而非需要深度系统集成的应用。

什么时候选 PWA

适合的场景：

  • 内容展示、电商、表单、工具类应用；
  • 用户获取成本敏感（希望降低门槛）；
  • 目标市场带宽/存储受限（新兴市场）；
  • 团队希望一套代码覆盖多平台。

不太适合的场景：

  • 需要深度系统集成（如需要常驻后台、复杂蓝牙交互）；
  • 计算密集型应用（重度游戏、视频编辑）；
  • 用户主要在 iOS 且依赖高级系统能力。

说明：本文为 Web 技术的知识整理，具体能力支持情况请参考各浏览器的最新文档。