【译】面试官：请你实现一个PWA 我：😭
前言🎉
这段时间面试官都挺忙的，嘿嘿，要不是我文章老是没什么人看，我要沦落到蹭热度的地步？
渐进式网页应用，后文统一简称PWA，又名Web开发的未来🤣，你不会，我觉得小伙砸你没有未来啊🤡。
PWA应用程序像普通网页一样加载，但提供脱机工作、推送通知和设备硬件访问的功能（懂吗？这就是不用安装的App啊😂，我就不信你没见过）
为了2020年不要被问了一脸懵，所以我写了这篇文章，废话不多说，接下来我们来看22个在2020到2021年间可能会询问到的PWA面试题，不然我写干嘛🤣。
我觉得是正文🤠
问题1：什么是PWA？
难度：⭐
渐进式网络应用（PWA）是谷歌在2015年底提出的概念。基本上算是web应用程序，但在外观和感觉上与原生app类似。支持PWA的网站可以提供脱机工作、推送通知和设备硬件访问等功能。
💡 来源：stackoverflow.com
问题2：PWA有那些优点？
难度：⭐⭐
- 更小更快: 渐进式的web应用程序比原生应用程序小得多。他们甚至不需要安装。这是他们没有浪费磁盘空间和加载速度非常快。
- 响应式界面:
PWA支持的网页能够自动适应各种屏幕大小。它可以是手机、平板、台式机或笔记本。 - 无需更新: 大多数移动应用程序需要每周定期更新。与普通网站一样，每当用户交互发生且不需要应用程序或游戏商店批准时，PWA总是加载最新更新版本。
- 高性价比：原生移动应用需要分别为
Android和iOS设备开发，开发成本非常高。另一方面，PWAs有着相同的功能，但只是先前价格的一小部分，开发成本低。 - SEO优势：搜索引擎可以发现
PWAs，并且加载速度非常快。就像其他网站一样，它们的链接也可以共享。提供良好的用户体验和结果，在SEO排名提高。 - 脱机功能：由于
service worker API的支持，可以在脱机或低internet连接中访问PWAs。 - 安全性：
PWAs通过HTTPS连接传递，并在每次交互中保护用户数据。 - 推送通知：通过推送通知的支持，
PWAs轻松地与用户进行交互，提供非常棒的用户体验。 - 绕过应用商店：
原生app如果需要任何新的更新,需要应用商店几天的审批，且有被拒绝或禁止的可能性,对于这方面来说，PWAs有它独特的优势，不需要App Store支持。更新版本可以直接从web服务器加载，无需App Store批准。 - 零安装：在浏览过程中，
PWA会在手机和平板电脑上有自己的图标，就像移动应用程序一样，但不需要经过冗长的安装过程。
💡 来源：stackoverflow.com
问题3： PWA有什么缺点？
难度：⭐⭐
- 对系统功能的访问权限较低：目前
PWA对本机系统功能的访问权限比原生app有限。而且，所有的浏览器都不支持它的全部功能，但可能在不久的将来，它将成为新的开发标准。 - 多数Android，少数iOS：目前更多的支持来自
Android。iOS系统只提供了部分。 - 没有审查标准：
PWAs不需要任何适用于应用商店中本机应用的审查，这可能会加快进程，但缺乏从应用程序商店中获取推广效益。
💡 来源：stackoverflow.com
问题4：如何让一个web应用成为PWA？
难度：⭐⭐
一个web应用要成为PWA,有需要一些关键原则需要遵守，如下：
- 可发现的，内容可以通过搜索引擎找到。
- 可安装，可以在设备的主屏幕上使用。
- 可链接，可以通过
URL来分享它。 - 与网络无关，可以在离线或网络连接不好的情况下工作。
- 渐进式的，仍可在较老的浏览器上使用，但在最新的浏览器上功能齐全。
- 可重新参与，能够发送通知，每当有新的内容可用。
- 响应式，可以在任何有屏幕和浏览器的设备上使用 —— 手机、平板、笔记本、电视、冰箱等等。
- 安全，用户和应用程序之间的连接是安全的，不受任何第三方试图访问用户敏感数据的影响。
问题5：为什么我们在PWA中需要Web manifest？
难度：⭐⭐
Web manifest以JSON格式列出关于网站的所有信息。这个文件是使网站可安装的要求之一。
它通常驻留在一个web程序的根文件夹。其中包含一些有用的信息,如应用程序的标题，路径不同大小的图标，可以用来表示移动操作系统上的应用程序(例如,主屏幕图标)，和一个背景颜色用于加载或闪屏。浏览器需要这些信息才能在安装和主屏幕上正确显示web程序。
💡 来源：MDN
问题6：PWA有哪些原生app不具备的特性?
难度：⭐⭐⭐
- 可发现性——
PWA中的内容很容易被搜索引擎找到，但诸如掘金之类的以内容为中心的原生app来说不会在其确实提供访问权限的内容的应用商店搜索结果中得到它确切提供访问的内容（也就是无法通过应用商店去搜索到文章嘿嘿😂，我大PWA就不一样了）。 - 可链接性——任何页面/屏幕都可以有一个直接链接，可以很容易地共享
- 可收藏性——保存该链接以直接访问应用程序的视图
- 始终新鲜——不需要通过应用商店来推送更新
- 通用访问权限——不受应用商店政策或地理限制（你懂的🤣）
- 节省大量数据——这对于昂贵且/或互联网访问速度缓慢的新兴市场至关重要。例如，
Konga(电子商务网站)通过迁移到PWA减少了92％的首次负载数据使用量。 - 发行摩擦低——如果你的
PWA在线，则Android（和其他移动）用户已经可以使用它。- 大部分手机用户没有每月下载任何新的应用程序
PWAs不需要去app store，搜索app，点击Install，等待下载，然后打开app。每一步都会损失20%的潜在用户（懒癌福音，简直了🤣）。
💡 来源：stackoverflow.com
问题7：Service Workers是什么？
难度：⭐⭐⭐
Service Worker是浏览器在后台独立于网页运行的脚本，它打开了通向不需要网页或用户交互的功能的大门。 现在，它们已包括如推送通知和后台同步等功能。 将来，Service Worker将会支持如定期同步或地理围栏等其他功能。 本教程讨论的核心功能是拦截和处理网络请求，包括通过程序来管理缓存中的响应。
这个API之所以令人兴奋，是因为它可以支持离线体验，让开发者能够全面控制这一体验。
在Service Worker出现前，存在能够在网络上为用户提供离线体验的另一个API，称为 AppCache。AppCache API 存在的许多相关问题，在设计Service Worker时已予以避免。
问题8：PWA与Hybrid之间有什么不同？
难度：⭐⭐⭐
Hybrid通常是指使用web和原生技术(native technology)的组合构建的应用程序，这些程序通过应用商店发布。要经过苹果、谷歌、微软等公司的应用程序商店审查程序。
PWA是使用在浏览器中运行的Web技术构建的应用程序，可以添加到主屏幕（就是固定到桌面🐷）。它们不需要通过本地应用程序商店发布，但可以包含在其中，Microsoft自2018年起在其Microsoft Store中包含了PWA，并且TWA（Trusted Web Activities，是谷歌最新提供的一种将web页面移植到Android APP的方法）使向Google Play Store提交PWA变得更加容易。
一些Hybrid平台包括PhoneGap（又名Cordova），Appcelerator Titanium和Ionic。您不需要一个平台来创建一个Hybrid，但它们对你很有帮助，因为它们已经在本地API和JavaScript API之间建立了桥梁。(也就是众所周知的JSbridge🐷)
PWAs只需在浏览器中运行，因此可以使用基本的HTML，CSS和JavaScript进行构建。（前端福音，嘿嘿😂）
💡 来源：stackoverflow.com
问题9：什么是fetch事件？
难度：⭐⭐⭐
在安装Service Worker且用户转至其他页面或刷新当前页面后，Service Worker将开始接收fetch事件
示例：
self.addEventListener('fetch', function(event) {
event.respondWith(
caches.match(event.request)
.then(function(response) {
// Cache hit - return response
if (response) {
return response;
}
return fetch(event.request);
}
)
);
});
复制代码这里我们定义了fetch事件，并且在 event.respondWith() 中，我们传入来自caches.match()的一个promise。 此方法检视该请求，并从服务工作线程所创建的任何缓存中查找缓存的结果。
如果发现匹配的响应，则返回缓存的值，否则，将调用fetch以发出网络请求，并将从网络检索到的任何数据作为结果返回。 这是一个简单的例子，它使用了在安装步骤中缓存的所有资产。
问题10：对网站进行PWA安装有哪些要求？
难度：⭐⭐⭐
要使网站可安装，它需要具备以下条件：
Web Manifest，其中填写了正确的字段- 网站的域必须是安全（
HTTPS）的 - 一个本设备上代表应用的图标
- 一个注册好的
Service Worker，可以让应用离线工作（这仅对于安卓设备上的Chrome浏览器是必需）
💡 来源：MDN
问题11：什么是IndexedDB以及如何在PWA中使用它？
难度：⭐⭐⭐
IndexedDB是大型NoSQL存储系统。它允许您在用户浏览器中存储任何内容。除了通常的search、get和put操作之外，IndexedDB还支持事务。
IndexedDB是用于客户端存储大量结构化数据（包括文件/blob）的低级API。该API使用索引来对数据的高性能搜索。虽然DOM存储对于存储较小数量的数据很有用，但对于存储较大数量的结构化数据则不太有用,所以说，IndexedDB提供了一个解决方案。
在PWA中，一般建议离线存储数据：
- 对于脱机时加载应用程序所需的网络资源，使用
Cache API（Service Workers的一部分）。 - 对于所有其他数据，使用
IndexedDB。
问题12：什么是CacheStorage？
难度：⭐⭐⭐
CacheStorage是浏览器中的一种存储机制，用于存储和检索网络请求和响应。它以Request 为key，Response为value去存储请求和响应对象。
CacheStorage不是Service Worker API，但它使SW能够缓存网络响应，以便在用户断开与网络的连接时提供脱机功能。
Caches对象（CacheStorage的一个实例）被用来访问CacheStorage，检索，存储和删除对象。
💡 来源：blog.bitsrc.io
问题13： 说说Service Worker生命周期，并画出其大概流程。
难度：⭐⭐⭐⭐
Service Worker的生命周期完全独立于网页。
要为网站安装服务工作线程，您需要先在页面的JavaScript中注册。 注册服务工作线程将会导致浏览器在后台启动服务工作线程安装步骤。
在安装过程中，您通常需要缓存某些静态资产。 如果所有文件均已成功缓存，那么Service Worker就安装完毕。 如果任何文件下载失败或缓存失败，那么安装步骤将会失败，Service Worker就无法激活（也就是说，不会安装）。 如果发生这种情况，不必担心，它下次会再试一次。 但这意味着，如果安装完成，您可以知道您已在缓存中获得那些静态资产。
安装之后，接下来就是激活步骤，这是管理旧缓存的绝佳机会。
激活之后，Service Worker将会对其作用域内的所有页面实施控制，不过，首次注册该Service Worker 的页面需要再次加载才会受其控制。 服务工作线程实施控制后，它将处于以下两种状态之一：服务工作线程终止以节省内存，或处理获取和消息事件，从页面发出网络请求或消息后将会出现后一种状态。
以下是Service Worker初始安装时的简化生命周期：
问题14：如何更新Service Worker？
难度：⭐⭐⭐⭐
在某个时间点，您的Service Worker需要更新。 此时，您需要遵循以下步骤：
- 更新您的服务工作线程
JavaScript文件。 用户导航至您的站点时，浏览器会尝试在后台重新下载定义Service Worker的脚本文件。 如果Service Worker文件与其当前所用文件存在字节差异，则将其视为新 Service Worker。 - 新
Service Worker将会启动，且将会触发install事件。 - 此时，
旧 Service Worker仍控制着当前页面，因此新 Service Worker将进入waiting状态。 - 当网站上当前打开的页面关闭时，
旧 Service Worker将会被终止，新 Service Worker将会取得控制权。 新 Service Worker取得控制权后，将会触发其activate事件。
问题15：阐述你所知道的Service Worker缓存策略。
难度：⭐⭐⭐⭐
下述三种缓存策略与框架无关：
- 仅缓存（Cache Only）——Service Worker期望在Cache找到请求的assets。
- 仅网络（Network only）——此策略与上一个策略完全相反：始终访问网络，甚至不查询缓存。
- 重新验证时失效(Stale while revalidate)——与
仅缓存(Cache Only)策略类似，目标是通过从缓存中传递数据来确保快速响应。但是，在处理客户端请求时，将向服务器触发一个单独的请求，以获取更新的版本（如果有的话😂）并将其存储到缓存中。
接下来说一下Angular框架提供的两种缓存策略：
- 性能优先（默认）：这里的目标是优化响应时间。如果缓存中
有可用的资源，则会传递此版本。否则，将执行网络请求以获取并缓存它。 - 新鲜度优先：当需要从网络传输最新数据时使用。我们可以指定一个
超时时间，在请求超时之后，将退回到缓存并尝试从那里传递所需的数据。
💡 来源：dev.to
问题16：什么是App Shell？
难度：⭐⭐⭐⭐
App Shell架构是构建PWA的一种方式，这种应用能可靠且即时地加载到您的用户屏幕上，与原生app相似。
App Shell是支持用户界面所需的最小的HTML、CSS和JavaScript，如果离线缓存，可确保在用户重复访问时提供即时、可靠的良好性能。这意味着并不是每次用户访问时都要从网络加载App Shell。 只需要从网络中加载必要的内容。
App Shell架构对具有相对不变的导航以及一直变化的内容的应用和网站意义重大。
问题17：一个App Shell应该具有什么特性？
难度：⭐⭐⭐⭐
App Shell应能完美地执行以下操作：
- 快速加载
- 尽可能使用较少的数据
- 使用本机缓存中的静态资产(
static assets) - 将内容与导航分离开来
- 检索和显示特定页面的内容（
HTML、JSON等） - 可选：缓存动态内容
问题18：苹果设备对于PWA支持怎样？
难度：⭐⭐⭐⭐⭐
Safari 11.1中提供了Service Worker，该产品于2018年3月29日与iOS 11.3和macOS 10.13.4一起发布。
下面是补充注意点：
- iOS和macOS都支持
Service Worker+Cache API（Cache API实际上是Service Worker支持的先决条件） - 没有“添加到主屏幕（就是固定到桌面😝）”提示
- 没有推送API
- 没有后台同步
- 其对
Service Worker实现中还有一些值得注意的问题
💡 来源：stackoverflow.com
问题19：Service Workers是否能够同时存在多个？
难度：⭐⭐⭐⭐⭐
有两点要注意：
- 只要每个
Service Workers都有自己独有的范围，就可以为给定的来源注册任意数量的Service Workers 缓存存储(Cache Storage API)(以及其他存储机制，如IndexedDB)在整个源中都是共享的，默认情况下不存在“分片”或命名空间隔离。
💡 来源：stackoverflow.com
问题20：有哪些Service Worker能做但是web worker不能的？
难度：⭐⭐⭐⭐⭐
Web Workers——为Web内容提供在后台线程中运行脚本的简单方法。工作线程可以在不干扰用户界面的情况下执行任务。此外，它们还可以使用XMLHttpRequest执行I/O（尽管responseXML和channel属性始终为空）。创建后，工作人员可以通过将消息发布到该代码指定的事件处理程序中来向创建该代码的JavaScript代码发送消息（反之亦然）。
Service Worker——本质上是充当位于Web app与浏览器和网络（如果可用）之间的代理服务器。它们旨在（除其他外）创建有效的脱机体验，拦截网络请求并根据网络是否可用以及服务器上是否存在更新的资产(assets)来采取适当的操作。它们还允许访问推送通知和后台同步API。
| Web Workers | Service Workers | |
|---|---|---|
| 实例（Instances） | 每个（Many per tab） | 一对所有（One for all tabs） |
| 存活时间（Lifespan） | 与tab一致（Same as tab） | 独立（Independent） |
| 用途（Intended use） | 并行（Parallelism） | 离线支持（Offline support） |
Web Worker可以方便地运行高耗能的脚本（expensive scripts，我也是看英文的，不知道翻译对不对🤣），而不会造成页面阻塞，而Service Worker有助于修改网络请求的响应（例如，构建离线App时😂）。
💡 来源：stackoverflow.com
问题21：使用Service Worker线程的 App Shell 架构有哪些优势？
难度：⭐⭐⭐⭐⭐
-
始终快速的可靠性能。重复访问速度极快。 第一次访问时即可缓存静态资产和 UI（例如
HTML、JavaScript、图像和 CSS），以便在重复访问时即时加载。内容可能会在第一次访问时缓存到系统中，但一般会在需要时才进行加载。 -
如同本机一样的交互。通过采用
App Shell模型，您可以构建如同本机应用一样的即时导航和交互，包括离线支持。 -
数据的经济使用。其设计旨在实现最少的数据使用量，并且可以正确判断缓存的内容，因为列出不需要的文件（例如，并不是每个页面都显示的大型图像）会导致浏览器下载的数据超出所必需的量。尽管在西方国家和地区中，数据相对较廉价，但新兴市场并非如此，这些市场中连接和数据费用都非常昂贵。
问题22：有可能在PWA中拥有真正的持久存储吗?为什么需要这样的存储?
难度：⭐⭐⭐⭐⭐
答案是否定的。用户可以删除PWA（如果安装在Android上）并清除浏览器缓存中的所有PWA。 Cache API是临时的，当用户清除浏览器缓存时，IndexedDB数据可以被擦除。 所以要在PWA安装中持久化应用程序的数据，您应该通过一些API使用云存储。
💡 来源：stackoverflow.com
