PWA：解决了web应用哪些问题|浏览器篇
# PWA：解决了web应用哪些问题
30 秒速记
PWA即渐进式网页应用，基础仍是普通Web页面，不要求站点一次性完成全面重构。- 对开发者而言，渐进式意味着可以分阶段引入能力，控制既有站点的改造范围与成本。
- 对技术演进而言，
PWA持续增强设备能力、动画流畅度、加载性能和类似本地应用的体验。 PWA的目标不是简单取代本地应用或小程序，而是在保留Web开放与跨平台优势的同时缩小体验差距。- 它更适合作为一套持续增强理念理解；材料未列出具体实现技术，因此不能仅凭本段把某个单一接口等同于完整的
PWA。
PWA 是一套渐进式增强 Web 应用的理念，目标是在保留开放、跨平台优势的同时，逐步缩小与本地应用或小程序的体验差距。 对开发者来说，它允许普通站点分阶段引入新能力，避免一次性全面改造。对技术演进来说，它会持续改善设备能力支持、动画流畅度、加载速度和本地应用特性。它不是简单宣称取代其他应用形态，也不能只凭某个单一接口就认定实现了完整的 PWA。
PWA，全称是 Progressive Web App，翻译过来就是渐进式网页应用。根据字面意思，它就是“渐进式 +Web 应用”。对于 Web 应用很好理解了，就是目前我们普通的 Web 页面，所以 PWA 所支持的首先是一个 Web 页面。至于“渐进式”，就需要从下面两个方面来理解。
- 站在 Web 应用开发者来说，PWA 提供了一个渐进式的过渡方案，让普通站点逐步过渡到 Web 应用。采取渐进式可以降低站点改造的代价，使得站点逐步支持各项新技术，而不是一步到位。
- 站在技术角度来说，PWA 技术也是一个渐进式的演化过程，在技术层面会一点点演进，比如逐渐提供更好的设备特性支持，不断优化更加流畅的动画效果，不断让页面的加载速度变得更快，不断实现本地应用的特性。
从这两点可以看出来，PWA 采取的是非常一个缓和的渐进式策略，不再像以前那样激进，动不动就是取代本地 App、取代小程序。与之相反，而是要充分发挥 Web 的优势，渐进式地缩短和本地应用或者小程序的距离。
那么 Web 最大的优势是什么呢？我认为是自由开放，也正是因为自由和开放，所以大家就很容易对同一件事情达成共识，达成共识之后，一套代码就可以运行在各种设备之上了，这就是跨平台，这也恰恰是本地应用所不具备的。而对于小程序，倒是可以实现跨平台，但要让各家达成共识，目前来看，似乎还是非常不切实际的。
所以我给 PWA 的定义就是：它是一套理念，渐进式增强 Web 的优势，并通过技术手段渐进式缩短和本地应用或者小程序的距离。基于这套理念之下的技术都可以归类到 PWA。
那今天我们就主要来聊聊 PWA 主要采用了哪些技术手段来缩短它和本地应用或者小程序的距离。
面试官追问
追问 1业务负责人要求老站下个迭代一次性“切成 PWA”，否则项目不算交付，你会如何质疑这个验收口径？
这个口径违背了 PWA 的渐进式定位。它强调普通站点按成本逐步增强能力，而不是一次性切换成另一种应用形态；验收应拆成明确的阶段目标，否则既无法判断增强范围，也可能把改造代价集中到单次发布。
追问 2一个内容站准备启动 PWA 改造，产品只写了“体验接近原生应用”，研发该怎样把它落成可执行计划？
应先把目标拆成站点当前缺失且确有价值的能力，再按成本和依赖分阶段交付，例如逐步改善加载、设备特性或应用化体验。原文没有提供统一技术清单，因此不能用模糊口号代替验收标准，也不宜承诺一次覆盖所有原生能力。
追问 3桌面端和移动端用户诉求差异很大，架构师仍要求两端在同一天启用完全相同的增强能力，这符合“渐进式”吗？
不必要求所有设备同步获得相同能力。PWA 的核心是发挥 Web 开放、跨平台和一套代码多端运行的优势，同时逐步缩小体验差距；具体增强仍应受终端支持和业务价值约束，不能把跨平台误解为各端能力绝对一致。
追问 4改造上线后，运营说页面仍不像本地 App，便认定 PWA 项目失败；作为评审人你会核对哪些事实？
应先核对本阶段承诺了哪些增强，以及这些能力是否真实生效，而不是用“是否等同原生”作单一判据。PWA 追求的是渐进式缩小与本地应用或小程序的距离；若目标、范围和验证条件未事先明确，就无法据此判定失败。
追问 5产品经理主张 PWA 的终局是彻底取代本地 App 和小程序，技术负责人则强调保留 Web 路线，你支持哪一方？
更应支持以 Web 优势为基础的渐进增强路线。材料明确反对动辄以取代本地应用或小程序为目标，强调自由开放、共识标准和跨平台价值；代价是能力差距只能逐步缩小，不能把所有本地特性都视为短期必达项。
# Web 应用 VS 本地应用
30 秒速记
- 普通 Web 应用与本地应用的主要差距集中在离线可用、消息触达和桌面级入口三个方面。
PWA通过Service Worker承担请求拦截、资源缓存和消息推送相关能力，改善弱网或页面未打开时的使用体验。manifest.json描述图标、名称和启动方式等安装信息，使 Web 应用可以从桌面直接启动。PWA是一组渐进增强技术，不要求一次性改造整个站点，也不意味着 Web 已完全具备本地应用的底层能力。
相比本地应用，普通 Web 应用的短板主要是离线能力、消息触达和桌面入口。 PWA 用 Service Worker 拦截请求、缓存资源并支持消息推送，所以在弱网、离线或页面未打开时也能改善使用体验。manifest.json 则描述图标、名称和启动方式，让用户可以从桌面直接打开应用。不过它本质上是一组渐进增强技术，既不要求一次改完整个站点，也不能让 Web 完全拥有本地应用的底层能力。
那相对于本地应用，Web 页面到底缺少了什么？
- 首先，Web 应用缺少离线使用能力，在离线或者在弱网环境下基本上是无法使用的。而用户需要的是沉浸式的体验，在离线或者弱网环境下能够流畅地使用是用户对一个应用的基本要求。
- 其次，Web 应用还缺少了消息推送的能力，因为作为一个 App 厂商，需要有将消息送达到应用的能力。
- 最后，Web 应用缺少一级入口，也就是将 Web 应用安装到桌面，在需要的时候直接从桌面打开 Web 应用，而不是每次都需要通过浏览器来打开。
针对以上 Web 缺陷，PWA 提出了两种解决方案：通过引入 Service Worker 来试着解决离线存储和消息推送的问题，通过引入 manifest.json 来解决一级入口的问题。下面我们就来详细分析下 Service Worker 是如何工作的。
面试官追问
追问 1新闻站已经支持“添加到桌面”，产品因此宣布离线阅读和后台通知也已具备，你会当场指出什么？
桌面入口只对应 manifest.json 解决的安装与启动入口，不能证明离线或消息推送已经可用。后两类能力需要由 Service Worker 承担相应工作；如果只验证了图标和启动方式，就不能把它验收为完整的应用化能力。
追问 2用户坐地铁进入弱网后，昨天访问过的文章仍然白屏，团队应该优先检查 manifest.json 还是 Service Worker？
应优先检查 Service Worker 的安装、生效和资源处理逻辑，因为离线与弱网使用依赖它拦截请求并决定返回缓存还是访问网络。manifest.json 只解决一级入口；即使文章访问过，若没有正确缓存或匹配请求，仍可能白屏。
追问 3运营要求用户关闭所有业务页面后仍能收到活动消息，开发者提议把轮询代码留在普通页面中，这个方案为什么站不住？
普通页面关闭后，其脚本可能不再运行，因此无法满足页面未启动时的消息送达需求。材料给出的方向是由 Service Worker 接收服务器推送并展示消息；具体推送链路还需另行设计，不能把后台能力等同于页面轮询。
追问 4线上出现“桌面图标能打开，但断网后首页不可用，也收不到通知”，测试报告只写了 PWA 失效，你会怎样拆解故障？
应把三类能力分别验证：manifest.json 是否提供一级入口，Service Worker 是否正确处理离线资源，以及消息推送链路是否工作。桌面可打开说明入口能力可能正常，却不能覆盖另外两项；笼统归因会掩盖各模块独立的配置或运行问题。
追问 5预算只够先做一项增强，产品选择桌面入口，客服则要求优先解决弱网白屏，你会如何说明两种方案的取舍？
两项能力解决的是不同缺陷：manifest.json 降低用户进入应用的路径成本，Service Worker 面向离线、弱网和消息推送。应按主要用户痛点决定优先级；若当前核心故障是弱网不可用，只增加桌面入口不会改善内容加载体验。
# 什么是 Service Worker
30 秒速记
Service Worker的核心定位是位于 Web 应用与网络之间的可编程请求拦截层。- 注册并生效后，应用请求会先经过
Service Worker，再由其选择缓存响应或发起网络请求。 - 缓存策略由开发者控制，因此可以围绕离线访问和弱网体验设计不同的响应路径。
- 它取代了问题较多且后来被废弃的
App Cache思路，但更高的控制力也意味着开发者需要自行管理请求与缓存决策。
Service Worker 本质上是放在 Web 应用和网络之间的一层可编程请求拦截器。 注册并生效后，资源请求会先经过它，再由它决定返回缓存内容，还是重新访问网络。这样开发者就能按业务需要设计离线和弱网策略，而不是完全依赖浏览器的默认行为。它接替了问题较多、后来被废弃的 App Cache 思路，但控制权更大，也意味着请求和缓存规则要由开发者自己维护。
我们先来看看 Service Worker 是怎么解决离线存储和消息推送的问题。
其实在 Service Worker 之前，WHATWG 小组就推出过用 App Cache 标准来缓存页面，不过在使用过程中 App Cache 所暴露的问题比较多，遭到多方吐槽，所以这个标准最终也只能被废弃了，可见一个成功的标准是需要经历实践考量的。
所以在 2014 年的时候，标准委员会就提出了 Service Worker 的概念，它的主要思想是在页面和网络之间增加一个拦截器，用来缓存和拦截请求。整体结构如下图所示：
在没有安装 Service Worker 之前，WebApp 都是直接通过网络模块来请求资源的。安装了 Service Worker 模块之后，WebApp 请求资源时，会先通过 Service Worker，让它判断是返回 Service Worker 缓存的资源还是重新去网络请求资源。一切的控制权都交由 Service Worker 来处理。
