跳到主要内容
渐进式 Web 应用开发实例：核心技术与实战 | 极客日志
JavaScript Node.js 大前端
渐进式 Web 应用开发实例：核心技术与实战 综述由AI生成 渐进式 Web 应用（PWA）的核心技术与实战开发。内容涵盖 PWA 的基本概念、优势及三大技术要求（Web 清单、HTTPS、服务工作者）。重点讲解了 Web 清单文件的配置、添加到主屏幕的体验实现、HTTPS 迁移策略与安全特性。此外，深入剖析了服务工作者的生命周期、Fetch API 的使用、推送通知与后台同步的编程实践。通过 2048 游戏和播客应用实例，展示了如何利用现代 Web API 构建高性能、离线可用的 Web 应用，帮助开发者掌握 PWA 开发全流程。
活在当下 发布于 2026/3/29 更新于 2026/6/11 渐进式 Web 应用（PWA）入门与实战
渐进式网络应用（PWA）标志着用户体验交付的新时代。现在，每个主要浏览器和平台都支持 PWA，消除了许多以前仅限于原生应用的缺失功能。如果您从事前端开发，了解 PWA 是什么、其优势以及如何构建现代 Web 应用至关重要。
本文将涵盖基本 PWA 要求，如 Web 清单文件以及 HTTPS 如何通过高级服务工作者生命周期和缓存策略工作。同时涉及 Web 性能优化实践和工具，帮助您持续创建高质量的渐进式网络应用。
为什么我们需要一种新的方式来构建网站
当苹果公司在 2007 年发布 iPhone 时，最初打算使用 HTML 来构建应用程序。然而，封闭的 App Store 通过引入第三方守门人而违反了网络的开放性。这导致审查过程可能导致您的应用程序被拒绝进入。
网络遇到的下一个感知问题是性能。性能问题在移动设备上被放大。智能手机和平板电脑的 CPU 性能较弱，蜂窝连接仍然不可靠。
在过去十年中，随着单页应用程序和许多大型框架的兴起，丰富的用户体验在网络上变得司空见惯。许多开发者尝试通过黑客手段在移动设备上模仿本地应用程序体验。这导致了一些进步，也带来了一些不良体验和编码实践。
这就是 PWA 如何使企业和组织能够更深入地与消费者互动。网络拥有原生应用无法触及的几个超级能力。现在，随着原生 API 的兴起，网络超越了原生应用。
什么是 PWA？
两年前，一位谷歌 Chrome 工程师 Alex Russell 发布了定义 PWA 的里程碑式博客文章。通过这篇博客文章，Alex 宣布网络现在可以与原生应用并驾齐驱。
Chrome 团队和其他浏览器希望您理解的是，用户体验是您网站或应用最重要的部分。浏览器为您提供构建优秀应用的基础，但让这些体验变得生动还是取决于您。
我倾向于认为，与原生应用程序开发者相比，网络开发者存在信心问题。然而，这并不完全正确。正如我们稍后将会看到的，可访问的网络页面比原生应用程序要多得多，与原生应用程序相比，你的网站品牌有更大的成长空间。
PWA 标志着对网页的重新工具化，使其成为一个以移动设备为先的平台。你的应用程序可以运行得更快，离线工作，并请求用户允许它们出现在主屏幕上。
PWA 特性
不要将 PWA（渐进式网络应用）误认为是特定技术。它更多的是一个营销术语，描述了使用现代平台功能来提供一定质量体验的方式。如果没有良好的用户体验，技术本身并不重要。
Chrome 团队确定了 PWA 应该提供的四个体验因素：
研究表明，如果网站加载时间超过 3 秒，53% 的用户将放弃该网站。服务工作者缓存使得页面加载时间几乎瞬间完成。
出现卡顿或屏幕跳动现象的应用程序被称为"janky"。例如，如果你曾经加载过网页，比如几乎任何新闻网站，当你开始阅读时内容上下跳动，你就知道我在说什么。这是一个非常差的用户体验，但可以通过适当的编码实践轻松避免。
在本书的后面部分，你将学习关于 RAIL（响应、动画、空闲、加载）和 PRPL（推送、渲染、预缓存和懒加载）模式。这些是 Chrome 团队提供的编码最佳实践。
PWA 技术要求
至少，要成为 PWA，有三个核心技术要求。一个网站必须有一个 Web 清单文件，使用 HTTPS 提供服务，并且必须注册一个具有 fetch 事件处理器的服务工作者。
Web 清单驱动着添加到主屏幕的体验。HTTPS 在你的应用程序和浏览器之间提供了一层安全性和信任。服务工作者提供了可扩展的后骨架构，用于在用户界面之外的线程上执行事件驱动功能。
PWA 也应使用应用程序外壳或常见的 HTML 和 CSS。这是 Chrome 最常见的应用，它被用于网站上几乎每个页面。
应用程序外壳
典型的应用程序外壳通常包含一个页眉、一个主要内容区域和一个页脚。当然，这可能会根据应用程序和网站而有所不同。
在单页应用程序中，应用程序外壳很常见，因为它们可以在浏览器中动态渲染标记和数据。对于 PWA 来说，情况并不一定如此。单页应用程序之所以如此受欢迎，是因为它们能够创建更接近原生的过渡体验，因为请求新页面时没有请求延迟。
由于 PWA 可以本地缓存，这并不意味着你需要一个真正的应用程序外壳。如果应用程序采用先缓存策略，页面可以在毫秒级加载，通常小于 100 毫秒。这在人类心智中感觉是瞬间的。
源代码示例结构
让我们回顾一下游戏源代码的结构。我喜欢这个项目，因为代码简单，展示了在浏览器中使用少量代码可以完成多少事情。
有三个资源文件夹：js、meta和 style。它们包含渲染和执行游戏所需的 JavaScript 文件、图像和样式表。
你还会注意到一个 node_modules 文件夹。我使用 grunt connect 添加了一个本地网络服务器，这是一个 node 模块。原始游戏如果直接在浏览器中加载
index.html
index.htmlmanifest.jsonsw.jsfavicon.ico 2048 代码的优点在于它只需要一个 HTML 文件。manifest.json和 sw.js 文件添加了我们追求的 PWA 功能。favicon.ico 文件是浏览器为地址栏加载的图标。
将 node 模块添加到项目中 原始仓库是一个独立游戏，这意味着它不需要网络服务器来执行，只需要一个浏览器。你可以右键点击 index.html 文件，选择在您喜欢的浏览器中打开它。在注册服务工作者之后，你仍然可以这样做，可能不会注意到任何区别。但是，如果你打开浏览器控制台（F12 开发者工具），你很可能会看到一个错误。
这种错误可以归因于服务工作者（service worker）的要求。服务工作者，就像大多数浏览器支持的新的 API 一样，需要 HTTPS 协议。这一要求提高了默认的安全级别，并使浏览器对您的网站所有权有最低程度的信任。
服务工作者规范放宽了对 localhost 地址的要求。localhost 是一种常见的引用本地机器的方式，通常是开发环境。由于你不太可能自己攻击自己，浏览器通常会允许你做你想做的事情——除了当你直接从文件系统中打开文件时。
您可以运行各种本地网络服务器。近年来，我更倾向于使用 node connect，我将它作为一个 Grunt 任务执行。
加载节点模块的第一步是从 npm 或其他新兴的包管理网站安装它们。如果您喜欢，可以通过命令行来管理，或者您可以在 package.json 文件中定义所需的模块。
就我们的目的而言，grunt 和 grunt-contrib-connect 模块是 devDependencies。
{
"name" : "2048" ,
"version" : "1.0.0" ,
"description" : "2048 Progressive Web App" ,
"author" : "Chris Love" ,
"private" : true ,
"devDependencies" : {
"grunt" : "*" ,
"grunt-contrib-connect" : "*"
}
}
Grunt 是一种在几年前获得流行并仍然是我的首选任务运行器。任务运行器，似乎每周都有一个新版本，帮助您将可重复的任务组织成可重复的食谱。
接下来，您需要创建一个 gruntfile.js 文件。这是您告诉 Grunt 您想运行哪些任务以及如何运行它们的地方。
module .exports = function (grunt ) {
grunt.loadNpmTasks ('grunt-contrib-connect' );
grunt.initConfig ({
connect : {
localhost : {
options : {
port : 15000 ,
keepalive : true
}
}
}
});
};
剩下的唯一任务是启动 connect 网络服务器。这是通过命令行完成的。
> grunt connect
Running "connect:localhost" (connect) task
Waiting forever...
Started connect web server on http://localhost:15000
执行 grunt connect，你应该会看到前面的示例输出。请注意，命令会继续执行。这是因为它是一个服务器，正在监听端口 15000 的请求。你无法在这个提示符下执行其他命令。
现在，你可以在浏览器中通过在地址栏输入 http://localhost:15000 来加载游戏。
添加清单文件 添加 Web 清单文件应该是升级现有网站的第一步。你可以在几分钟内创建你网站的清单文件。
注册 PWA 的 Web 清单需要在 HTML 的 head 元素中添加一个特殊的链接元素。以下代码显示了如何注册 2048 清单文件：
<head >
...
<link rel ="manifest" href ="manifest.json" >
</head >
如果你熟悉引用样式表，这个语法应该看起来很熟悉。区别在于 rel 属性值是 manifest。href 值指向清单文件。你可以自由命名它，但 manifest 是最常见的名称。
下一章将详细介绍清单文件。你可以参考项目的 manifest.json 文件来查看 2048 游戏的配置。它包含应用程序的名称、默认 URL、主要颜色以及一个图标图像引用数组。
添加服务工作者 接下来，你需要注册一个服务工作者。这是在所谓的客户端代码中完成的，即你习惯于编写的 JavaScript。服务工作者在 UI 的独立线程中执行。我认为它是一个后台进程。你仍然需要为网站注册服务工作者。
对于像这个例子这样的简单注册，我首选的方法是在我网站标记的底部添加一个脚本块。首先，检测是否支持服务工作者。如果支持，那么尝试注册网站的服务工作者。如果浏览器不支持服务工作者，则跳过注册代码以避免出现异常。
注册是通过调用 navigator.serviceWorker.register 函数来完成的。它接受一个参数，即服务工作者文件的路径。
注册函数返回一个承诺。你可以添加代码来记录成功的注册，如下所示：
<script>
if ('serviceWorker' in navigator) {
navigator.serviceWorker .register ('/sw.js' ).then (function (registration ) {
console .log ('ServiceWorker registration successful with scope: ' , registration.scope );
}).catch (function (err ) {
console .log ('ServiceWorker registration failed: ' , err);
});
}
</script>
我们将在第五章 服务工作者生命周期 中开始深入了解关于服务工作者细节。为了帮助你理解示例代码，让我介绍一些服务工作者基础知识。服务工作者是完全异步的。如果它们不需要，它们会进入空闲或睡眠状态。当操作系统或浏览器触发事件时，它们会唤醒或完全启动。
所有逻辑执行都是事件的结果。你必须注册事件处理程序来执行你的服务工作者逻辑。2048 服务工作者为安装、激活和获取事件注册了事件处理程序。
2048 游戏服务工作者在安装事件中预缓存了整个应用程序。你将在第六章 掌握缓存 API – 在播客应用程序中管理网络资产 中了解更多关于缓存策略的内容。现在，我们将缓存应用程序，使其始终可用，没有任何网络通信：
self.addEventListener ("install" , function (event ) {
console .log ("Installing the service worker!" );
caches.open ("PRECACHE" ).then (function (cache ) {
cache.addAll (cacheList);
});
});
2048 服务工作者在安装事件中缓存资产。应用程序资产在服务器工作者代码中的一个数组中定义。缓存 API 提供了一个接口，用于一个专门为持久化响应对象而设计的特殊存储。
var cacheList = [
"index.html" ,
"style/main.css" ,
"js/keyboard_input_manager.js" ,
"js/html_actuator.js" ,
"js/grid.js" ,
"js/tile.js" ,
"js/local_storage_manager.js" ,
"js/game_manager.js" ,
"js/application.js"
];
服务工作者也有激活和获取事件处理程序。在触发添加到主屏幕功能之前，必须注册获取事件处理程序。
当浏览器从网络请求资产时，获取事件会被触发。这可能是一个图像、样式表、脚本、AJAX 调用等等。event 参数包含请求对象，可以用来检查你的缓存以查看资产是否可用：
self.addEventListener ("fetch" , function (event ) {
event.respondWith (
caches.match (event.request ).then (function (response ) {
if (response) {
return response;
}
return fetch (event.request );
})
);
});
没有获取事件处理程序，你的应用程序无法离线工作。没有要求处理程序捕获任何请求，只需注册即可。这是离线功能的最小检查。
在示例中的获取事件处理程序中，所有缓存都会被查询以查看是否存在与请求匹配的现有条目。如果存在，则返回本地缓存的版本。如果不存在，则请求会被传递到网络。
就这样；恭喜！你的网站现在至少在你的本地机器上是一个 PWA。
在这一点上，在 Chrome 中加载本地站点应该会显示添加到主屏幕的提示。如果没有，请重新加载页面一次或两次，并将焦点应用到浏览器标签页上。如果你仍然没有看到提示，请检查控制台中的任何错误消息并相应地进行调试。
第二章：使用网页清单创建主屏幕体验 进阶式网页应用让网站感觉就像原生应用一样。对于企业利益相关者来说，这给了他们使用免费应用商店来吸引客户的机会。对于真实用户来说，这意味着他们经常访问的网站可以无缝安装。
每个平台（操作系统和浏览器）都以自己的方式实现主屏幕和应用程序的启动，但大多数都涉及某种形式的书签过程和由网页清单文件驱动的打开体验。
Chrome for Android 将安装的 PWA 放置在应用架中，并允许在设备设置中将 PWA 像原生应用一样进行管理。Microsoft 利用 Windows Store，并为未来的版本制定了一个免费商店安装流程。Apple 仍在探索他们将如何实现这些体验，但他们正在基于他们的遗留体验进行构建。
本章将介绍如何创建网页清单文件来描述你的应用程序给平台，以及你如何可以通过编程方式提示用户将 PWA 添加到他们的主屏幕。
为什么将应用添加到主屏幕很重要 重新参与是原生应用程序相对于网站所享有的关键优势。它们图标出现在用户的主屏幕和应用架上，提供了快速、直观的品牌体验访问。这是微妙的，但那个图标是客户与品牌关系的持续视觉提醒。
浏览器已经为我们提供了内置机制，多年来我们可以使用收藏夹来书签网站，但这些列表已经变成了杂乱无章的混乱，我们经常忘记它们。
更现代的浏览器已经开始记录你经常访问的页面，并在你打开新标签页时提供这些常见目的地的书签。这是一个在不要求用户 书签 网址的情况下提高用户生产力的例子。
这些书签并不能提供渐进式网络应用添加到首页体验的相同原生体验。Android 上的 Chrome 通过将所有已安装的 PWA 作为 WebAPK 来提供最先进的 PWA 安装优势，引领了这一领域。
WebAPKs 是一种技术术语，表示 Android 上的 Chrome 会在安装过程中将渐进式网络应用打包成 APK（Android 可执行文件）以实现几乎原生的应用升级。由于它们无法访问像原生 Android 应用那样的 Android 特定 API，因此它们仍然有限。
然而，如果你将你的 PWA 提交到 Windows Store，并且客户从 Windows Store 安装它，那么你的渐进式网络应用就是一个原生应用。它将享受与原生应用在 Windows 上相同的所有好处和能力，包括文件系统访问和与 Cortana 等功能的集成能力。
在客户首页上获得位置的能力很重要。原生和 Web 应用都有机制，但两者都有摩擦，这降低了成功率并增加了成本。你必须使用 6-8 个步骤来诱导潜在客户在移动平台上安装你的应用。2012 年，加博尔·塞勒估计，每个步骤都会消除 20% 对安装你应用感兴趣的移动用户。
这意味着对于 6 步安装过程，只有 26% 的用户保留。如果步骤有 8 步，这个数字将下降到不到 17%。
当然，用户只有在知道如何在/能够找到你应用商店的情况下才会开始应用安装过程。这意味着你的公司必须投资时间和金钱来驱动流量和品牌知名度。
使你的 PWA iOS 网络应用具备功能 当苹果推出 iOS 时，原始的应用推荐是使用 HTML5、CSS3 和 JavaScript 来创建丰富的客户端用户体验。苹果没有移除 Web 应用支持，并且随着时间的推移增强了一些功能。iOS Web 应用体验是由添加到网页 HEAD 中的自定义元数据驱动的。
大部分苹果元数据已成为现代 Web 清单规范的模式。在创建 Web 清单规范之前，Android 上的 Chrome 集成了对苹果元数据的支持，以驱动类似的经验。
当你的网站包含苹果特定的 META 标签、相应的图标，并且用户已将你的网站添加到他们的主屏幕时，iOS 上的 Web 应用体验被触发。
你需要的第一件东西是一个 png 文件作为默认的主屏幕图标。文件应命名为 apple-touch-icon.png，并且应位于你网站的根目录中。
单个页面可以有一个独特的图标，在 HEAD 中的 link 引用：
<link rel ="apple-touch-icon" href ="/custom_icon.png" >
更好地是，为不同的屏幕尺寸和密度指定图标。平台将确定哪个图标最适合设备。如果没有指定图标，则搜索根目录中带有 apple-touch-icon 前缀的图标：
<link rel ="apple-touch-icon" href ="touch-icon-iphone.png" >
<link rel ="apple-touch-icon" sizes ="152x152" href ="touch-icon-ipad.png" >
<link rel ="apple-touch-icon" sizes ="180x180" href ="touch-icon-iphone-retina.png" >
<link rel ="apple-touch-icon" sizes ="167x167" href ="touch-icon-ipad-retina.png" >
当提供了所需的元数据后，你必须诱导用户启动 iOS 添加到主屏幕的过程。这始于他们按下 Safari 的分享图标。
这触发了 Safari 分享菜单，其中不仅包含分享 URL 的选项：它还包含书签图标，并将网站保存到主屏幕。
与主屏幕图标类似，启动屏幕图像也可以指定。将其视为启动画面。这是通过一个 LINK 元素和一个对启动图像的引用来完成的。如果没有指定图像，则使用上次启动应用时的截图：
<link rel ="apple-touch-startup-image" href ="/meta/apple-touch-startup-image-640x920.png" >
应用程序标题通过另一个 META 标签设置 这与我在 网络清单 部分将详细讨论的名称和短名称清单属性相似。如果没有提供 META 值，则使用 title 元素值：
<meta name ="apple-mobile-web-app-title" content ="2048 PWA" >
接下来，您应该控制您的 Web 应用如何呈现给用户。iOS 允许您在浏览器中启动应用或以独立模式启动。独立模式移除了浏览器，但保留了屏幕顶部的 iOS 状态栏。以下代码展示了这一点：
<meta name ="apple-mobile-web-app-capable" content ="yes" >
<meta name ="apple-mobile-web-app-status-bar-style" content ="black" >
在独立模式下，没有地址栏，因此您可能需要调整您的 UI 以允许客户复制 URL 并返回到之前的屏幕。导航问题与本地应用程序设计师协商的问题相同，每个应用程序都有不同的要求。
状态栏也可以使用 apple-mobile-web-app-bar-style 值进行样式化。此值仅在您的应用以独立模式启动时使用。您可以将默认的灰色更改为黑色或半透明黑色。
不幸的是，您无法将颜色主题化以匹配您的应用程序主题或完全隐藏它。
如果您已按照苹果的规范完成所有操作，当用户启动 2048 游戏时，它应该占用整个屏幕。
苹果可能在 iOS 上为与网络品牌建立更亲密的关系铺平了道路，但他们的方法从未成为通用标准。随着 W3C 的标准化，这种变化发生在渐进式 Web 应用时代，这是一个元数据格式，用于向平台描述您的 Web 应用。
网络清单规范 网络清单描述了渐进式 Web 应用，使用元数据和 JSON 格式。浏览器解析清单文件以创建添加到主屏幕的图标并启动体验。
现在，不再需要在每个页面的 HEAD 中添加额外的元数据，浏览器可以加载一个包含使用 JSON 格式化的标准属性和值的外部文件。
引用网络清单文件 网络清单文件必须在文档的 HEAD 中引用，如以下代码所示：
<head >
....
<link rel ="manifest" href ="manifest.json" >
</head >
清单应该使用 application/manifest+json MIME 类型提供服务。这是一个重要的设置，因为它经常被忽视。
您应该研究如何在您选择的 Web 服务器中定义或添加 MIME 类型。
许多服务器默认根据文件类型阻止对文件的请求。这通常导致清单文件返回 404 或 403 类型状态代码。您可能需要与您的网络管理员或 devops 团队协调，以确保您的服务器配置正确。
不要使用您的服务工作者缓存网络清单文件。您可能无法在不更新服务工作者的情况下更新文件。它们应该保持解耦。
网络清单属性 拥有您应用程序的外观对于确保最佳用户体验至关重要。每个应用程序都有独特的用例，消除了渐进式 Web 应用程序'一刀切'的想法。虽然大多数应用程序将想要复制全屏的原生应用程序体验，但有些将想要保持可见的地址栏。标准化的清单文件为品牌所有者提供了一个与浏览器通信的渠道，以提供最佳品牌体验。
清单应包含一系列属性，包括 name、short_name、description、icons、orientation、颜色和默认页面。这些用于主屏幕和启动体验。
nameshort_namedescriptioniconsorientationtheme_colorbackground_colorstart_url 您可以在清单中指定其他官方属性，但它们的使用案例有限。我还想指出，由于文档使用 JSON，这是一种可变的数据结构表示法，因此它是可扩展的，一些浏览器正在尝试专有属性。如果您使用非标准属性，请不要担心——您不会破坏其他浏览器，因为它们只是忽略那些值。
有两个名称属性；name 和 short_name。short_name 用于主屏幕图标和其他空间受限的地方。在允许空间的地方，使用 name 属性。
{
"name" : "2048" ,
"short_name" : "2048" ,
"description" : "[provide your description here]" ,
"start_url" : "/" ,
...
}
start_url 定义了当选择主屏幕图标时加载的初始 URL。这消除了用户从深度链接（如新闻文章）将 PWA 添加到主屏幕的情况。在过去，图标将是该文章的书签，而不是主页。
start_url 可以是应用范围内的任何 URL。它不需要是公共主页；它可以是特殊的 PWA 主页。您还可以使用查询字符串值从服务器驱动额外的跟踪和动态行为。
接下来，icons 属性是一个包含 icon 对象的数组，这些对象定义了图标的 URL、MIME 类型和尺寸：
"icons" : [
{ "src" : "meta/2048-logo-70x70.png" , "sizes" : "70x70" , "type" : "image/png" } ,
...
{ "src" : "meta/2048-logo-600x310.png" , "sizes" : "600x310" , "type" : "image/png" }
]
虽然支持不同的图像类型，但我建议使用 .png，因为 Chrome 至少需要一张 144 x 144 像素的 .png 图像。你应该至少包含四个图标，其中至少一个是 144 x 144 像素，但 192 x 192 像素更好。
我的经验法则是包含一打或更多的图标变体，以应对潜在的平台需求和机会。Windows Live Tiles 宽度可达 600 像素，可以缩小到小于 70 像素宽。
在创建图标时使用一些艺术指导也是一个好主意。有些标志在小尺寸下效果不佳。如果你将图标添加到主屏幕并发现难以定位，那么你的客户可能也会如此。
启动画面图像是从图标数组中绘制的。Chrome 会选择与设备 128dp 最接近的图像。标题直接从名称成员中提取。使用名为 background_color 的属性指定背景颜色。
使用数组引用你的 PWA 图标作为 URL。数组中的每个项目都是一个描述图标的对象。包括 src URL、sizes 属性和 MIME 类型。我建议使用 .png 文件，因为 Chrome 目前要求此格式。
控制启动样式 清单具有平台用于了解如何启动应用程序的属性。display 属性允许你控制 Chrome 浏览器如何渲染。默认值是 browser，它将在浏览器中启动 PWA，带有 Chrome。
minimal-ui 选项将 PWA 作为应用程序启动，但带有最小的一组导航 UI。
standalone 模式将 PWA 作为全屏应用程序启动。应用程序占据大部分屏幕，但一些浏览器元素，如状态栏，可能会被渲染。查看以下代码以了解属性：
"display" : "fullscreen" ,
"orientation" : "landscape" ,
fullscreen 模式在无任何浏览器元素的全屏和应用模式下启动应用程序。对于最终用户来说，感觉就像他们打开了一个原生应用程序。
fullscreen：在全屏中启动应用程序。standalone：类似于全屏，但可能有一个可见的系统 UI。minimal-ui：向独立视图添加一些最小浏览器导航 UI 组件。browser：在浏览器中以常规网页形式打开 PWA。orientation：此属性定义应用程序渲染的角度。主要选择是横屏和竖屏。值应该是自解释的。不，你不能以 45 度倾斜渲染你的应用程序！
any自然横屏竖屏竖屏 - 主要竖屏 - 次要横屏 - 主要横屏 - 次要 theme_color 和 background_color 用于表示应用并提供默认背景颜色。这两种颜色之间的区别在于它们的应用方式：
"background_color" : "#fff" ,
"theme_color" : "#f67c5f" ,
背景颜色指的是 BODY 元素的默认背景颜色。这通常在网站的 CSS 中设置。如果没有设置，则默认回浏览器默认值。今天，事实上的背景颜色是白色，但在早期，它是灰色。
theme_color 定义了操作系统用于可视化的颜色。这包括任务切换体验。每个平台都提供不同的用户体验，与如何展示应用程序相关，因此主题颜色的应用会有所不同。
如果你的应用程序使用的是从右到左的语言，你可以使用 dir 属性来指定。然后这个方向会被应用到 name、short_name 和 description 字段。
lang 属性与 dir 相关，因为它指定了网站使用的语言。它也应用于文本属性。值应该是一个标准的语言标签，由 2 或 3 个字符代码后跟一个可选的子标签组成，例如，en-US 或 en-GB。
如果你恰好有一个提供在 PWA 中不可用功能的原生应用程序，你可以使用 prefer_related_applications 字段来指示其可用性，并将其设置为 true 或 false。与 related_applications 值一起使用，以提示如何安装原生应用程序：
"related_applications" : [
{
"platform" : "play" ,
"url" : "https://play.google.com/store/apps/details?id=com.love2dev.2048" ,
"id" : "com.love2dev.2048"
} ,
{
"platform" : "itunes" ,
"url" : "https://itunes.apple.com/app/2048-pwa/id123456789"
}
]
Chrome 最近增加了对清单范围属性的支持，这增加了对 PWA 及其链接页面的渲染方式的更多控制。我将在 WebAPK 或 改进添加到主屏幕体验 部分中稍后回顾 Chrome 如何具体使用此属性。
scope 属性定义了 Web 应用程序的上下文或被认为是渐进式 Web 应用程序一部分的 URL 范围。平台可以根据需要使用它，但共识是，如果用户在范围内导航，浏览器将根据清单的 display 属性渲染 PWA。任何超出此范围的导航都会导致页面使用完整的 Chrome 浏览器渲染。
支持 Apple Safari 网络清单 自从苹果发布了 iOS 11.3 和 Safari 13 更新以来，对网络清单规范的基本支持被包括在内。当前的使用和支持存在一些限制：
主屏幕图标仍然引用自 apple-touch-icon
透明图标不受支持
不支持 3D 触控菜单
没有启动画面
无法锁定方向
不正确地支持 fullscreen 和 minimal-ui
苹果还有工作要做，以便完全支持使用 web 清单，但这是一个开始。我相信在接下来的几个月里，我们应该会看到支持得到改善。浏览器供应商面临的一个挑战是转向支持提供功能的新方法。
从提供用户体验的 10 年旧方式（如触摸图标和移动 Web 应用功能）迁移到不同的机制是困难的。如果他们做得太快，他们可能会破坏许多网站，这是所有浏览器供应商都害怕的事情。因此，预计过渡将是渐进的。
我还想指出，PWA 支持，特别是与服务工作者相关，在许多原生应用使用的 webview 中尚未得到支持。这也意味着任何混合应用程序作为 PWA 将无法访问这些功能，包括服务工作者。
在 iOS 上的伪浏览器，如 Chrome、Edge 和 Firefox，也不支持任何渐进式 Web 应用功能。这些浏览器使用 webview 来渲染页面，而不是它们自己的引擎。因此，目前它们也受到限制。
好消息是，Safari 支持所有主要平台上的所有主要浏览器，并且现在支持基本的 web 清单消费。
验证 web 清单文件 web 清单是一个简单的 JSON 文档，但很容易出错或忘记某些内容。如果您的网站没有正确注册清单文件，您将需要调试问题。幸运的是，有一些资源可以帮助您验证文件。
这些工具并非只有这些。还有一些其他 node 模块，以及 Lighthouse 和 Sonar。我将在第十章，服务工作者工具 ，以及 PWA Builder 中介绍这些工具，PWA Builder 可以生成您的清单。
Chrome 改进的添加到主屏幕体验 在 2017 年某个时候，Chrome 团队宣布了对 PWA 安装体验的更改，称为改进的添加到主屏幕体验。当时，这不仅仅关于自动提示，但这已经成为了变化的一部分。它更多地与 PWAs 在 Android 上的行为有关，它更像是原生应用程序。
这些变化是多方面的，始于 Web 清单的作用域属性。这个属性相对较新，但允许浏览器知道如何限制源（域名）上的 PWA 功能。
当你设置作用域值为 / 时，你是在告诉平台，渐进式 Web 应用的能力适用于源内的所有路径。这并不总是如此，尤其是在较大的网站和企业应用中。通常，这些网站被分割成不同的应用。
如果你将作用域更改为 /hr/，那么只有 /hr/ 文件夹下的 URL 将包含在 PWA 的作用域内。这意味着这些 URL 将根据 Web 清单文件配置打开。不在 /hr/ 文件夹内的 URL 将在浏览器中正常打开。
当使用 Chrome 在 Android 上安装 PWA 时，它会自动创建一个未签名的 WebAPK，这使得 PWA 成为一个原生应用。在 WebAPK 中，会创建一个 Android 清单文件，其中包含 intent 过滤器。
Intent 过滤器告诉 Android 如何打开源内的 URL。对于 PWA，这意味着应用将根据清单配置启动，或者如果在其作用域之外，则直接在浏览器中打开。
这里是这些 intent 过滤器在 WebAPK 中的样子：
<intent-filter >
<action android:name ="android.intent.action.VIEW" />
<category android:name ="android.intent.category.DEFAULT" />
<category android:name ="android.intent.category.BROWSABLE" />
<data android:scheme ="https" android:host ="2048.love2dev.com" android:pathPrefix ="/" />
</intent-filter >
pathPrefix 的值会改变以匹配 Web 清单的作用域值：
<intent-filter >
<action android:name ="android.intent.action.VIEW" />
<category android:name ="android.intent.category.DEFAULT" />
<category android:name ="android.intent.category.BROWSABLE" />
<data android:scheme ="https" android:host ="love2dev.com" android:pathPrefix ="/hr/" />
</intent-filter >
这些变化并没有停止在 Android 上，因为最近的更新也已经应用于 Chrome OS，并且不久的将来也将应用于桌面 Chrome。谷歌正在用渐进式 Web 应用替换 Chrome OS 应用，为平台上的先前 Web 应用提供类似的功能。
Chrome 还将更多添加到主屏幕体验的功能引入桌面。然而，这会因操作系统而异，因为每个平台都有不同的用户期望。
好消息是，如果你制作了好的渐进式 Web 应用，你将直接受益于这些变化。
添加到主屏幕体验 出现自动提示访客将你的渐进式 Web 应用添加到他们的主屏幕上是非常令人兴奋的。在过去，Chrome 最终会显示一个提示安装渐进式 Web 应用，但最近这已经改变了。触发提示的规则仍然有效，但现在只触发 beforeinstallprompt 事件。
用户提示触发的机制是每个浏览器可以选择不同路径的地方。一些要求在 Web 清单规范中定义，但体验被留给浏览器根据需要实现。
目前，Chrome 拥有最成熟的过程。他们建立了以下标准来自动触发添加到主屏幕体验：
有一个 Web 应用清单文件：
一个 short_name（用于主屏幕）
一个名称（用于横幅）
一个 144 x 144 .png 图标（图标声明必须包含 image/png 的 MIME 类型）
Astart_url 加载
在你的网站上注册了 service worker：
有 fetch 事件处理器
Fetch 事件处理器不能是一个空操作函数，它必须做些什么
通过 HTTPS（使用 service worker 的要求）提供服务
至少访问两次，两次访问之间至少有五分钟
FireFox、三星和 Opera 有类似的要求。FireFox 将在 Android 上触发体验，但不在桌面版上。你可以允许桌面版上的体验，但它被隐藏在标志后面。
这些浏览器通常在浏览器的地址栏中提供简单的视觉提示。以下是 Android 上的 Firefox 如何显示指示器。
注意它如何使用带有 + 的房屋图标来表示该网站可以安装。在其右侧，你也会看到一个 Android 轮廓标志。小 Android 头像表示有应用可用。
Chrome 添加到主屏幕体验 在渐进式 Web 应用体验方面，Chrome 无疑是当之无愧的领导者。他们应该如此，因为他们创造了这一概念。他们也有时间对这个概念进行实验，看看什么有效，什么无效，以及消费者和开发者有什么期望。
这导致他们不断改进流程，使得在 Android 上安装应用时 Chrome 会创建一个 WebAPK，将应用提升到与原生应用相似的水平。最近，他们扩展了这一功能到 Windows 和 ChromeOS，并计划很快在 macOS 上实现。
这里，你可以看到我 Windows 开始菜单中最近安装的一些渐进式 Web 应用。
那么，WebAPK 和 增强型添加到主屏幕体验 究竟是什么？
我已经解释过了：Chrome 将渐进式 Web 应用打包到 apk 包中，这种打包方式被称为 WebAPK 。如果你不熟悉 Android 原生应用开发，所有的资源都打包在一个名为 apk 的单个文件中。
简单来说，这只是一个包含应用资源的 zip 文件。Windows 使用 appx 格式做类似的事情。Chrome 创建 WebAPK 时所做的类似于使用 Cordova 从网站生成原生应用。
Chrome 团队决定创建一个重复的通道来维护并给予 PWAs 类似的控制，因为采用这种混合方法的原生应用效率最高。他们首先在 Chrome 57 中推出了这一功能。原生 Android 应用与已安装的渐进式 Web 应用之间的主要区别是无法访问平台 API。
应用看起来就像设备上安装的任何 Play Store 应用一样。图标可以放置在主屏幕上，在应用托盘上可见，并且可以通过 Android 平台设置进行管理。
这里是如何在 Android 应用管理界面中呈现 2048 PWA 的。
当 Chrome 在其他平台上实现此功能时，您可能会或可能不会发现相同级别的控制。例如，您仍然无法从 Windows 的控制面板中管理已安装的 PWA。
应用程序使用与网页相同的存储设置。清除域的存储也将清除已安装 PWA 的存储。这意味着将删除 cookie 和缓存内容。
另一个好处是当 Web 清单文件更新以引用新的图标或更改名称值时。这将更新主屏幕图标。
您添加到主屏幕的责任 在 2018 年的 Google I/O 上，宣布 Chrome 在 Android 上将不再包含自动添加到主屏幕的提示。相反，您有责任创建用户体验。最终，Chrome 团队决定更符合其他浏览器供应商构建体验的方式。
清单规范需要时间来定义添加到主屏幕体验的骨架规则和最小要求。而不是将所有浏览器限制在相同的规则下，该规范定义了可以作为添加到主屏幕提示算法一部分使用的 安装信号 。
提示序列应尊重一定的隐私考虑，并在发出提示之前等待文档完全加载。该过程还应允许用户检查应用程序名称、图标、起始 URL、来源和其他属性。还建议允许最终用户修改一些值。例如，更改他们主屏幕上的应用程序名称。
这就是 beforeinstallprompt 事件发挥作用的地方。这是您将用户引导至安装您的渐进式 Web 应用的正确信号的钩子。
当满足触发添加到主屏幕体验的启发式条件时，将触发此事件。但不是来自 Chrome 的原生或内置提示，您需要在事件触发后适当时机提示用户。
他们为什么改变这个？我并不是 100% 确定，尽管我个人认为这是一个好主意，有助于推广 Web 应用程序的安装。但这有点侵扰性，并且不符合其他最佳实践。例如，当我们在这本书的后面部分查看启用推送通知时，您不应该自动打扰访客启用通知。
在请求下一阶段的交往之前，应该有一些小小的求爱过程。我并不喜欢用这个比喻，但到了这个阶段，它已经变得很经典了；你不能只是走到每一个漂亮的女孩面前，就请求她们嫁给你。这是一个更长的过程，其中必须赢得双方的信任。
请求访客将你的图标添加到他们的主屏幕上，并不完全等同于婚姻，但更像是请求他们开始稳定交往或独家约会。
要使用 beforeinstallprompt 事件，在你的网站 JavaScript 中添加一个事件监听器回调：
var deferredPrompt;
window .addEventListener ('beforeinstallprompt' , function (e ) {
e.preventDefault ();
deferredPrompt = e;
showAddToHomeScreen ();
});
我需要审查几个移动部件。首先是事件对象 (e) 有两个独特的属性，platforms 和 userChoice。platforms 是一个数组，表示用户是否可以安装原生应用或渐进式 Web 应用。userChoice 属性解决了一个承诺，表示用户是否选择了安装应用。
在这个代码中使用的另一个元素是 deferredPrompt 变量。这个变量是在事件处理程序外部声明的，因此可以在稍后使用，在这种情况下是在 showAddToHomeScreen 逻辑中。
在这个例子中，showAddToHomeScreen 方法会在事件触发时立即被调用，但更好的做法是将操作推迟到适当的时间。想想一个正在执行重要应用任务的用户。突然的安装应用提示将会是一个令人困惑的干扰。如果你将提示推迟到操作完成，这将对你和用户都有好处。
showAddToHomeScreen 方法显示一个特殊的覆盖层，请求用户安装应用：
function showAddToHomeScreen (var a2hsBtn = document .querySelector (".ad2hs-prompt" );
a2hsBtn.style .display = "flex" ;
a2hsBtn.addEventListener ("click" , addToHomeScreen);
}
我在 2048 应用中添加了一个简单的覆盖层，当可见时它会向上滑动。
最后，addToHomeScreen 方法利用了我们保存在 beforeinstallprompt 事件处理程序中的 deferredPrompt 变量。它调用提示方法，显示前面截图所示的内置对话框：
function addToHomeScreen (if (deferredPrompt) {
deferredPrompt.prompt ();
deferredPrompt.userChoice .then (function (choiceResult ) {
if (choiceResult.outcome === 'accepted' ) {
console .log ('User accepted the A2HS prompt' );
} else {
console .log ('User dismissed the A2HS prompt' );
}
deferredPrompt = null ;
});
}
}
然后该方法使用 userChoice 方法根据选择执行任务。在这里，我只是将选择记录到控制台。你可以持久化一个表示状态的令牌，或者级联额外的逻辑来执行其他任务。
2048 应用是一个非常简单的添加到主屏幕体验。你可以扩展这个功能来教育用户或告诉他们添加你的应用到他们主屏幕上的好处。Flipkart 有一个很棒的教育序列，解释了如何安装应用以及为什么应该这样做。这是一个很好的体验模式，也是他们成功使用渐进式 Web 应用的原因之一。
禁用主屏幕提示 beforeinstallprompt 事件也可以用来抑制 Chrome 的自动提示。这次，就像打破默认表单提交一样，调用 preventDefault 函数并返回 false：
window .addEventListener ('beforeinstallprompt' , function (e ) {
e.preventDefault ();
return false ;
});
这将在 Chrome 中阻止该行为。目前，我不知道如何在其他平台上抑制提示，因为它们还没有支持 beforeinstallprompt 事件。
跟踪主屏幕安装 一旦显示主屏幕安装提示，用户可以选择将 PWA 添加到他们的主屏幕，或者忽略提示。企业应该跟踪和衡量所有可能的事情，以做出更好的决策。了解有多少主屏幕安装以及客户安装他们的 PWA 的速率，可以提供对他们的营销和技术投资的洞察。
Chrome 支持 beforeinstallprompt 事件，可以用来跟踪这项活动。你可以添加一个处理程序到这个事件，并记录每个用户的选项：
window .addEventListener ('beforeinstallprompt' , function (event ) {
event.userChoice .then (function (result ) {
if (result.outcome == 'dismissed' ) {
} else {
}
});
});
你可以将用户的选项 POST 到你的分析系统中。这可能是一个自定义 API 到你的内部分析，甚至可以绑定到你的第三方服务，如 Google Analytics。
beforeinstallprompt 是 Web 清单规范的一部分，但在撰写本书时，它只由 Chrome 支持。希望其他浏览器很快会添加支持。
不支持 beforeinstallprompt 的浏览器也可以提供反馈。Web 清单的 start_url 可以设置为特殊起始 URL，或者追加到默认 URL 的自定义查询字符串值。你需要添加逻辑到你的日志分析器中，以跟踪这种行为。除了知道你有多少主屏幕安装之外，你还可以跟踪用户启动你的 PWA 的次数，以及那些没有安装你的 PWA 的用户。
在 iOS 和其他旧浏览器上多文件化主屏幕体验 开发者和企业主经常问的一个问题是，如何在 iOS 和像 Internet Explorer 这样的旧浏览器上启用渐进式 Web 应用功能。虽然这些浏览器中所有功能都不能被破解，但大部分是可以的。
当 iPhone 发布时，最初的应用模型是网页。他们为 Web 应用创建了一个高级体验，包括添加到主屏幕的体验。不幸的是，他们没有制作自动提示体验。谁知道如果开发者没有呼吁原生应用模型，今天这个体验可能会多么先进。
避免重复加载主屏幕提示非常重要，除非需要，不要加载'添加到主屏幕'库。我发现确定是否需要 polyfil 的最简单方法是通过使用功能检测服务工作者支持。我选择这样做是因为支持服务工作者的浏览器有一些添加到主屏幕的体验。这在未来可能或可能不会保持不变，所以如果情况发生变化，请准备好更改标准。
不深入细节，我喜欢在页面加载时动态加载 JavaScript 引用。这个过程涉及一系列功能检测，以 polyfil 各种要求，如 Promises 和 Fetch API：
if (!'serviceWorker' in navigator) {
scripts.unshift ("js/libs/addtohomescreen.min.js" );
}
您还需要动态添加添加到主屏幕样式表。这次，在文档的 HEAD 中添加一个功能检测脚本：
<script>
if ('serviceWorker' in navigator) {
cssLink = document .createElement ("link" );
cssLink.id = "addToHomeScreen" ;
cssLink.rel = "stylesheet" ;
cssLink.type = "text/css" ;
cssLink.href = "css/libs/addtohomescreen.css" ;
document .head .appendChild (cssLink);
}
</script>
自从 iPhone 发布以来，用户就可以安装这样的 Web 应用，但这个过程是手动的，并且对最终用户和开发者来说都 largely unknown。缺乏自动提示一直是该功能的关键缺失组件。它创造出的体验似乎是 Chrome 团队和其他平台模仿以显示渐进式 Web 应用主屏幕提示的模型。
Matteo 的库只提示用户并开始手动过程，但用户仍需完成一些不太直观的额外步骤。新的原生添加到主屏幕过程有一个伪自动管道可以集成。我认为添加到主屏幕库可以作为设计您体验的良好参考，所以花时间看看它是值得的。
你应该 polyfil 响应缓存吗？ 请求缓存也可以使用 IndexedDB 进行 polyfile。然而，现在大多数浏览器都支持服务工作者和缓存，我认为这种方法并没有明智地利用资源。在移动使用之外，Internet Explorer 是主要没有服务工作者支持的浏览器。在撰写本书时，IE 应该主要用于企业，当他们的业务线应用程序尚未升级到现代标准时。
这意味着可能只有极少数潜在用户会在没有服务工作者支持的浏览器中打开您的 PWA。当这种情况发生时，可以说他们很可能是某种桌面电脑，并且拥有可靠的网络连接。
尽管我使用早期实现的客户端资产缓存开发了数百个应用程序，但我已经正式从我的推荐中弃用了这种方法。
微软 Edge 和 Internet Explorer 当 Windows 8 发布时，微软悄悄地发布了他们所谓的 托管 Web 应用 （HWA ）的支持。这些是引用有效 web 清单文件的网站，并通过 HTTPS 提供服务。
HWA 是渐进式网络应用的早期前身。明显的区别是无需服务工作者要求，这是预料之中的，因为服务工作者这个概念当时还没有被创造出来。
要成为 HWA，你需要为你的应用程序创建一个包含清单文件和公共 URL 引用的 .appx 文件。然后，你将 HWA appx 提交到 Windows Store，消费者可以从商店安装 HWA。
成为 HWA 的优势在于这些网络应用可以完全访问所有 Windows 平台 API，就像任何原生应用一样。它们拥有这种特权的原因是，一旦安装，它们就构成了商店，并且是完整的应用程序。
主要区别在于 UI 组件和业务逻辑都是网页。这让你能够立即更新应用程序，而无需经历所有移动应用商店都面临的审核延迟。
在许多方面，这就像是传统原生应用和 Chrome 在 Android 上支持的 WebAPK 功能之间的结合。
微软甚至创建了一个名为 Manifoldjs 的在线工具，以帮助进行 HWA 创建和提交过程。近年来，Manifold 已经重新设计，并有了新的名字，PWA Builder (pwabuilder.com )。
今天，PWA Builder 可以将任何公共网站转换为渐进式网络应用，并提供资源将其提交到 Windows Store，同时还能编译适用于 Apple 和 Google Play 商店的 Cordova 应用。
如果你有所疑问，Windows Store 中已经有很多 HWA 和 PWA 了。Twitter 和 Pandora 是一对知名 Windows 渐进式网络应用。事实上，Twitter 正在逐步淘汰所有原生应用，未来将全部转向 PWA。
我将在第十章第十章，服务工作者工具 中详细介绍 PWA Builder。相信我，你不会想跳过这一章，因为 PWA Builder 和我们所提到的其他工具都已经成为了我的 PWA 工作流程的基石。
今天，Microsoft Edge 支持服务工作者，这意味着 HWA 的概念已经演变为渐进式网络应用的消费。同样的过程适用于商店提交，你仍然拥有完整、原生的应用功能。
Windows 8 和 Internet Explorer 也支持将网络应用固定到开始屏幕的本地 Live Tiles。当 Edge 和 Windows 10 发布时，Live Tile 支持并未被包含在内。但这并不意味着你不能将网站添加到开始菜单。
在 Microsoft Edge 中，用户可以通过右上角的 ... 图标打开菜单。这会显示一个包含许多选项的菜单，其中一个是将此页面固定到开始菜单。另一个选项是将页面添加到任务栏：
如你所知，在 Windows 7 时代，Internet Explorer 支持丰富的锁定网站功能。最近，对锁定网站的支持已经恢复。就像 iOS 一样，你可以通过 meta 标签自定义此体验：
<meta name ="application-name" content ="2048" />
<meta name ="msapplication-square70x70logo" content ="meta/2048-logo-70x70.png" />
<meta name ="msapplication-square150x150logo" content ="meta/2048-logo-152x152.png" />
<meta name ="msapplication-wide310x150logo" content ="meta/2048-logo-310x150.png" />
<meta name ="msapplication-square310x310logo" content ="meta/2048-logo-310x310.png" />
<meta name ="msapplication-TileColor" content ="#ECC400" />
锁定网站仍然可以通过 Internet Explorer 使用，但随着企业升级到 Windows 10，作为主要浏览器的 Internet Explorer 使用率正在迅速下降。这并不意味着你应该跳过锁定网站的元数据。目前我仍然包括它。
我不想将这些解决方案放在负面空间，因为它们都是将网络平台推进以提供更好用户体验的良好首次尝试。也许你可以看到这些尝试如何作为现代网络清单规范参考的依据。
现在，随着 Microsoft Edge 发布了服务工作者，团队正忙于研究他们的添加到开始菜单（我的术语，不是他们的）将是什么样子。他们在 2018 年 Build 大会上提供了一些早期原型，但在撰写本书时，还没有确定的东西。
我最好的猜测是在夏末或初秋，我们可能会在 Redmond 的年度 Edge 开发者峰会上看到一些更具体的内容。
无需 Polyfils 即可享受好处 即使你没有 polyfil 添加到主屏幕的行为，你的网络应用在 iOS 和其他非 PWA 平台上也会看到用户参与度的提升。许多公司正在公开分享他们在各种渐进式网络应用案例研究中的改进。
在线航空预订服务 Wego 报告称，在 iOS 上的转化率提高了 50%，会话时间延长了 35%。Mynet 页面浏览量增加了 15%，iOS 上的跳出率降低了 23%。兰蔻的 iOS 会话增加了 53%。这些都是积极的渐进式网络应用案例研究的小样本。
这些公司正在享受 iOS 上 PWAs 的好处，因为从本质上讲，正确架构的网站性能更佳。此外，创建渐进式网络应用迫使你将客户放在首位，而不是开发者。当你这样做时，你会创造更好的用户体验，这直接关联到关键性能指标的改善。
遵循渐进式网络应用指南迫使你提供跨所有平台工作的以用户为中心的体验。
在 Chrome 中测试添加到主屏幕的体验 没有测试添加到主屏幕的体验，开发者的体验将不完整。Chrome 添加了工具，允许你查看你的网页清单文件是如何被解释的，并手动触发提示。
通过使用 F12 启动 Chrome 的开发者工具并选择应用程序标签页。有许多选择可以帮助你调试渐进式网络应用的各个方面。在应用程序下，有一个'清单'选项。这将显示你的网页清单文件属性，包括每个图标。这是一个快速确定你的清单是否被正确解释的方法。
测试您的最佳方式是将您的渐进式 Web 应用部署到云端，并启用 HTTPS。在支持 PWA 的浏览器中打开您的网站，并尽可能遵守规则以触发添加到主屏幕提示。
在多个设备上测试您的网站始终是一个最佳实践。我建议至少有一部 iPhone、一部 Android 手机和一台配备多个浏览器的桌面电脑。拥有这些真实用户体验可以让您有信心，您部署的 PWA 按预期工作。
摘要 由于 Web 清单和添加到主屏幕体验，原生和渐进式 Web 应用之间的界限变得非常模糊。主屏幕不再仅限于原生应用；Web 被所有平台所欢迎。
今天，大多数浏览器都为渐进式 Web 应用提供了高级应用体验，尽管苹果公司尚未采用渐进式 Web 应用标准，但他们却是第一个将 Web 体验转变为应用体验的公司。开发者和企业需要采用并实施丰富的添加到主屏幕功能。
触发添加到主屏幕体验是提升您的网络存在感的第一步。
即使用户尚未将您的 PWA 添加到他们的主屏幕，您仍然可以利用渐进式 Web 应用的功能。然而，在我们深入探讨服务工作者之前，让我们看看如何将 SSL 添加到您的网站上。
下一章将介绍安全性或 HTTPS 的使用，这是使应用成为渐进式 Web 应用的三项主要技术要求之一。
第三章：使您的网站安全 现在没有任何网站使用 HTTPS，这令人惊讶。过去保护网站很困难，但近年来大多数安全障碍都已被消除。这些障碍包括价格、技术要求和性能担忧。
要成为渐进式网络应用，网站必须通过 HTTPS 提供服务。服务工作者位于 HTTPS 之后，因为它们在后台运行，旨在执行可能在不受保护的情况下损害隐私的任务。
减少和消除障碍后，由于搜索引擎排名的提高、浏览器中的视觉提示以及 HTTPS 背后的门控 API，搜索引擎和浏览器增加了 HTTPS 对消费者的可见性。
这意味着每个网站现在都有从 HTTP 迁移到 HTTPS 的激励措施。但仍然有一些问题您需要解决，以确保 HTTPS 策略的成功。
什么是 SSL/TLS 和 HTTPS
常见反对意见，迁移到 HTTPS 的理由
HTTPS 迁移策略
SSL 历史 安全套接字层 （SSL ）证书代表了大多数网络和互联网交易中信任的基础。当谈到 SSL 和 HTTPS 时，信任是关键词。当网站使用 SSL 时，浏览器和服务器之间的通信是加密的，但为了获得 SSL 证书，您必须与颁发机构建立一定程度的信任。
要启用 SSL，您必须在服务器上安装证书。证书由 证书颁发机构 （CA ）颁发。如今，有许多证书颁发机构，很难一一列举。您应该寻找最适合您需求的最佳提供商。在本章中，我将讨论其中的一些。您还将了解不同类型的证书以及 CA 打包 的附加功能。在不久的过去，Network Solutions 是唯一一个可以购买证书的权威机构。
他们不仅是镇上唯一的游戏，您还得处理大量的繁琐手续。如果他们不喜欢您的文件，他们会拒绝您。个人购买证书几乎是不可能的，因为域名所有权需要与注册企业绑定。
这种有限的可用性导致了年度证书的高价。平均博客、企业或组织从未考虑过使用 SSL，因为成本问题。这限制了 SSL 的使用，仅限于传输敏感信息（如信用卡和银行账户号码）的网站，因为这些原始障碍。
证书成本不仅限于年度证书成本——托管安全网站是昂贵的。因为网络技术尚未发展，SSL 限制为每个 IP 地址一个域名。这意味着网站需要支付专用 IP 地址的费用，通常还需要支付专用 Web 服务器的费用。如果您想要加密，每月 4.99 美元的共享托管计划不是选项。
自那时起，HTTPS 的故事已经改变。有许多免费和低成本的证书授权机构，消除了年度成本障碍。HTTP 协议和 Web 服务器技术也得到了发展。今天，您可以使用不同的证书和主机头（域名）在同一 IP 地址上托管多个网站。
2003 年的 TLS 规范变更使得客户端将域名作为 TLS 协商的一部分包含在内。现在，Web 服务器可以使用它们的内部主机头表来确定所需的网站。
TLS 是如何工作的？ TLS 是一种加密协议，它建立在 TCP 之上，有时也建立在 UDP 之上。因为它位于传输层之上，它允许链中更高层的协议保持不变，例如 HTTP。
该协议隐藏了通过线路发送的实际数据。攻击者只能看到与之连接的端口、域名和 IP 地址。他们还可以跟踪传输的数据量。
一旦建立了 TCP 连接，客户端（通过浏览器或其他用户代理客户端应用程序）将启动 TLS 握手。客户端通过提出一系列问题开始 TLS 对话：
它运行的是 SSL/TLS 的哪个版本？
它想使用哪些加密套件？
它想使用哪些压缩方法？
客户端选择客户端和服务器都支持的 TLS 协议的最高级别。同时也会选择压缩方法。
一旦建立了初始的 TLS 连接，客户端会请求服务器的证书。证书必须得到客户端或客户端信任的权威机构的信任。证书授权机构的例子包括 Network Solutions、GeoTrust、Let's Encrypt 和 Amazon。
证书验证完成后，将交换加密密钥。密钥取决于所选择的加密方式。一旦密钥交换完成，客户端和服务器就可以执行对称加密。
客户端和服务器执行最终验证，其中客户端的 MAC 地址由服务器验证。服务器从客户端接收一个初始认证消息，该消息被解密并发送回客户端以进行验证。
加密密钥为每个连接生成，并基于认证消息。假设握手成功完成，客户端和服务器现在可以安全地通信。
客户端和服务器之间的安全 TLS 连接至少具有以下属性之一：
由于对称密码学用于加密传输的数据，这是连接安全的原因。共享密钥的协商既安全又可靠（协商的密钥对窃听者不可用，攻击者无法在协商过程中修改通信内容而不被检测到）。
公钥密码学用于验证通信方的身份。认证过程可以是可选的，但通常对于服务器来说是必需的。
为了防止在传输过程中数据未被检测到的丢失或更改，每个传输的消息都包含使用消息认证码进行的信息完整性检查。
什么是 HTTPS？ HTTPS 是 SSL/TLS 中的 HTTP。TLS 为两个主机（Web 服务器和浏览器）之间的双向二进制数据通信建立了一个安全隧道。HTTP （超文本传输文本协议 ）是客户端和服务器之间用来互相通信的通信协议：
因此，可以将 HTTP 想象成管道内的水。管道是 TLS 加密，而水是数据。HTTPS 与水类比的主要区别在于 HTTPS 是双向的，而管道不是。
还有其他通信协议支持 TLS，例如 WebSockets（WSS）、电子邮件（SMTPS）和 FTP（FTPS）。
HTTPS 优势 当有人询问 SSL 或 HTTPS 时，你首先想到的，通常是加密。这是使用 HTTPS 的一个很好的理由，但不是唯一的原因，甚至不是最重要的原因。
身份 ：证书证明服务器是真正的服务器机密性 ：只有浏览器和服务器可以读取它们之间传递的数据完整性 ：发送的数据是对方接收到的数据
身份 当你安装 SSL 证书并启用 HTTPS 时，你是在告诉全世界他们可以信任你的网站身份。一旦客户端和服务器之间建立了这个安全的通信通道，双方都可以确信对话是期望的对象。
客户端和服务器通过验证彼此的身份来建立通信通道。证书用于验证这个身份。每次对话都需要一个只有客户端和服务器知道的令牌。
机密性 没有 HTTPS，你的连接可能会被中间人攻击所劫持。浏览器中的地址可能会告诉你它是你期望加载的域名，但实际上，它可能是中间的坏人。
通常，当你使用 HTTP 连接到一个网站时，对话是明文的。一般来说，对话不包含任何敏感信息。但坏人可能会窃听你的流量，并利用他们找到的信息做坏事。
当你使用公共 Wi-Fi 时，这种情况会加剧。这些网络对于免费连接到互联网来说很棒，但对于个人安全来说却很糟糕。
一旦窃听者确定了你的会话，他们可能会拦截对话并将你重定向到他们的服务器。现在，你与目标网站共享的任何信息都会发送到坏家伙的服务器。
让我们改变场景，让所有相关人员都在使用 HTTPS。现在所有通信都是加密的。坏家伙唯一能看到的是你访问的域名（s），甚至不是那些域名上的 URL。
客户端和服务器之间的连接无法被劫持。如果恶意行为者试图劫持会话，客户端和服务器都知道有问题，对话就会结束。
完整性 因为连接是加密的，第三方演员无法篡改数据，所以每一端都知道数据是有效的。这是因为中间人攻击被阻止了。
你不仅需要担心坏人。第三方内容，如广告，可能会在 HTTP 的任何地方注入响应中。例如，ISP 或你当地的咖啡馆可能会修改请求和响应，将你重定向到不同的服务器或更改你查看的内容。
HTTPS 保证了客户和服务器对会话包含真实数据的信心。当使用 HTTP 时，无法保证客户端或服务器接收到的数据是正确的。
浏览器正不遗余力地向客户表明 HTTPS 你有没有注意到浏览器地址栏中的那些挂锁？你可能注意到了，但你直到觉得有点不对劲时才真正考虑它。近年来，浏览器逐渐提高了普通消费者的用户体验。
很快，Chrome 将开始明确显示页面包含密码或信用卡字段的情况。如果这些字段存在且不是通过 HTTPS 提供的，它们将显示一个大红色的视觉警告，提示客户该页面不安全。
最近，Chrome 在隐身模式下加载使用 HTTP 的网站时开始显示警告。
Chrome 并非唯一在网站未使用 HTTPS 提供服务时增加视觉提示的浏览器：Microsoft Edge、FireFox 和 Opera 都已宣布计划增加视觉提示。这当然会导致越来越少诈骗成功，但也会减少合法的商业转化，因为它们忽视了 HTTPS 的应用。
搜索引擎优化 谷歌和其他搜索引擎已经公开表示，他们认为 HTTPS 网站比信息相同但不安全的网站更具权威性。原因有两个。首先，普通网络冲浪者会更信任 HTTPS 网站而非非 HTTPS 网站。这可能只是一个简单的博客，也可能是一个巨大的银行——无论网站是什么，对安全的感知都至关重要。
因此，即使你的网站不处理 敏感 信息，你也应该实施 HTTPS，以增强访客对你品牌和搜索引擎排名的信心。
第二个原因是，搜索引擎推动企业和组织实施 HTTPS 是为了验证所有权。没有某种所有权验证，你无法安装合法的 TLS 证书。证书颁发者会发送一封电子邮件，根据域名的 WHOIS 记录触发验证过程。当你注册域名时，你必须提供真实的联系信息，包括一个有效的电子邮件地址。
恶意分子倾向于使用虚假或错误的联系信息注册域名，这样他们就无法被追踪。通过要求 HTTPS，搜索引擎表明对网站所有权有一定的信任。
随着网络向 HTTPS 作为默认方式发展，垃圾网站将越来越少。恶意分子不会轻易获得 SSL 证书。
已不再具有成本障碍 自从 SSL 开始以来，证书就伴随着成本。通常，这是一个年度成本。在过去（大约 15 年前），证书通常每年花费 100 到 500 美元。你可以把它想象成年度营业执照。事实上，为了完成证书请求，你通常需要提供业务或组织的证明。颁发过程也是耗时耗力的。通常需要 3-14 天才能获得证书。颁发机构有一支评估每个证书请求及其相关文件的员工。对于一个数字平台来说，这是一个非常古老的过程。
虽然企业对每年 100 美元的网站费用并不在意，但普通小型企业却会感到压力。对于每一家企业，都有成千上万家小型企业。除了传统的小型企业，还有数百万的企业、博客、论坛和其他实体，它们的网站几乎没有或没有收入。它们几乎无法证明其托管费用的合理性。以那样的价格，HTTPS 根本不可行。
另一个你可能没有考虑到的成本是 IP 地址。最初，SSL 需要一个专用的 IP 地址。尽管有数百万个可能的 IP 地址，但仍然不够，甚至远远不够。IP 地址的有限供应也提高了 HTTPS 的价格。这可能会给托管一个网站的成本每年增加 100 美元或更多。今天，这种情况已经改变。现在，证书映射到域名。这消除了这种税收。
今天，HTTPS 的要求和成本都已经放宽。有许多低成本证书提供商。实际上，您可以从亚马逊或 Let's Encrypt (letsencrypt.org ) 免费获得证书。Let's Encrypt 分享的最新统计数据表明，已颁发超过 5000 万张证书。
到目前为止，我提到了 SSL，但这个名字已经不再完全准确了。传输层安全性 （TLS ）是今天使用的正确术语。安全协议随着时间的推移不断进化。SSL 最初是由 Netscape 创建的，现在由 AOL 拥有。
在一般对话中，SSL 和 TLS 是可以互换的，因为大多数人都会明白你的意思。
你实施的协议版本受限于你的服务器平台。因为 TLS 1.2 现在已经非常成熟，所以很难找到一个不支持版本 1.2 的服务器平台或浏览器。但 Qualys 有一些建议：
'SSL/TLS 家族中有五种协议，但并非所有都是安全的。最佳实践是使用 TLS v1.0 作为你的主要协议（确保在配置中缓解了 BEAST 攻击），如果服务器平台支持，则使用 TLS v1.1 和 v1.2。这样，支持较新协议的客户端将选择它们，而不支持的客户端将回退到 TLS v1.0。你绝对不能使用 SSL v2.0，因为它是不安全的。'
幸运的是，当你创建 TLS 证书时，协议版本由你处理。在本章的后面部分，我将介绍在 AWS 和 Let's Encrypt 创建证书的步骤，这两个都是免费服务。
现代 API 需要 HTTPS 虽然这些 API 可以在没有 HTTPS 的情况下工作，但安全性将这些特性包裹在信任之中。想想看——平台让你集成得越深，它们对你的应用程序的要求就越高。
要求使用 HTTPS 确保最小程度的安全和信任，因此足以让潜在的平台相信你不会做坏事。
HTTPS 可以比 HTTP 快得多 一些旨在使网站更快的技术的确只与 HTTPS 一起工作。一个例子是称为 HTTP/2 的协议增强。通过 HTTP 与 HTTPS 测试来查看这一功能如何发挥作用（详情见 www.httpvshttps.com/ ）。
当我第一次看到研究显示 HTTPS 更快时，我承认我持怀疑态度。我看到加密在网络瀑布中增加了多少时间。幸运的是，管理浏览器和网络堆栈的人们为我们做了好事，并平滑了许多导致 SSL 比非 SSL 慢的问题，如下面来自谷歌的 Adam Langley 的引言所示：
'在我们的生产前端机器上，SSL/TLS 占 CPU 负载不到 1%，每个连接不到 10 KB 的内存，以及网络开销不到 2%。许多人认为 SSL/TLS 会占用大量的 CPU 时间，我们希望前面的数字有助于消除这种看法。'
由于 HTTP/2 通过单个连接多路复用请求，因此只需完成一次 TLS 握手。这减少了检索资产和服务器负载的时间。现在客户端和服务器只需要执行一次握手和加密周期。
HTTP/2 的目标是通过消除 HTTP/1.1 规范中的不足来提高性能。HTTP/2 通过多路复用响应、压缩头部、优先处理响应以及允许服务器端推送来实现这一点。
所有浏览器都支持 HTTP/2，大多数服务器也是如此。Windows 2016 是最后一个支持 HTTP/2 的主要操作系统。由于它是相对较新的，因此在网络上没有很多生产部署。
HTTP/2 不会改变任何 HTTP 语义。状态码、动词和其他此类短语是我们多年来一直在使用的，因此不会破坏现有应用程序。
标准浏览器强制执行的默认实现是 HTTP/2 over TLS。虽然技术上可以使用 HTTP/2 而不使用 TLS，但浏览器不允许这种做法。
单个连接和 TLS 握手与 HTTP/2 提供的其他性能优势相结合，意味着 TLS 始终比 HTTP 快。
HTTPS 的采用 根据 2017 年 8 月的 Qualys 调查（见 www.ssllabs.com/ssl-pulse/ ），他们分析的网站中有 60.2% 配置了正确的 SSL。值得注意的是，他们的调查仅限于 138,672 个最受欢迎的网站，这只是目前数亿个网站中的一小部分样本。
与过去不同，现在每个网站都应该使用 HTTPS 而不是纯文本 HTTP。通过 HTTPS 保护你的网站不仅仅是关于安全，它还关乎建立信任。当你实施 HTTPS 时，你不仅增加了一层安全：你的客户可以看到你对安全的承诺，并更愿意与你品牌做生意。大多数消费者和非技术人员都理解 HTTPS 的目的。他们不关心技术实现，他们关心的是信任。当你实施 HTTPS 时，你正在消除客户可能有的压力，如果你不使用 HTTPS。SSL 增加了你的整体用户体验价值，这就是为什么搜索引擎和浏览器都在推动每个人使用 HTTPS。有几个原因说明为什么你应该在每个网站上使用 HTTPS。
不同类型的 SSL 证书 SSL 证书可以分为两种类型：验证级别 和 受保护域名 。
证书可以颁发给多个域名，甚至通配符域名。但由于扩展验证规范，这些证书只能颁发给单个域名，而不是多个或通配符域名。这是因为验证过程的敏感性。
根据你选择的确认身份的方法，存在几种不同类型的 SSL 证书。这三个级别在复杂性上递增，并且在验证证书所需的信息类型上有所不同。
域验证证书 域验证 SSL 证书 （DV 证书 ）是最基本的，验证与 SSL 证书注册关联的域名。为了验证 DV SSL 证书，所有者（或具有管理员权限的人）通过电子邮件或 DNS 批准证书请求。
电子邮件接收者通过确认收件并发送确认给提供商来证明他们对域的行政权限。此外，他们可能需要为相关域配置某些 DNS 记录。订购和验证 DV 证书的过程可能需要几分钟到几小时。
这应该是最常用的证书类型，因为任何网站都可以快速安装它们，成本极低或没有成本。如果你的网站可能成为钓鱼或其他欺诈形式的攻击目标，你可能需要投资于需要更多身份验证的证书：
浏览器将通过绿色锁形图标在视觉上指示使用适当 HTTPS 的服务网站。域验证证书是实现这一状态所需的最基本证书。
以下截图显示了 Firefox 如何显示证书信息。这是我的当前 Love2Dev.com 证书，一个域名验证证书：
你可以看到它只列出了通用名称（域名），而将组织和组织单位留空。
组织验证证书 组织验证 SSL 证书 （OV 证书 ）验证域名所有权，以及证书中包含的组织信息，如名称、城市、州和国家。验证过程与域名验证证书类似，但需要额外的文件来证明公司的身份。由于公司验证过程，订单可能需要几天的时间。
提供更多公司信息，从而向最终用户传达更多信任。大多数消费者永远不会检查证书的详细信息，但它可以帮助传达更多信任。
扩展验证 SSL 证书 扩展验证 SSL 证书 （EV 证书 ）比 DV 和 OV 证书需要更多的公司数据验证。需要验证域名所有权、组织信息以及法律证明和文件。由于扩展验证过程，订单可能需要几天到几周的时间。
浏览器中的 绿色地址栏 包含公司名称是扩展验证证书的显著特征，并且是扩展验证证书的直接回报。它实际上不是一个绿色栏，但你的组织名称以漂亮的绿色字体列在地址栏中，表明这是一个受信任的网站。
将扩展验证证书与前面的示例进行比较，组织和组织单位字段具有属性。
OV 和 EV 证书类型并不反映加密级别的提高；相反，这些反映了网站域名所有者/公司的更严格验证。一个好的规则是，你网站管理的敏感数据越多，你应该使用的验证级别就越高。
如果你使用的是组织或扩展验证证书，请确保你在证书到期前开始续订流程。这些证书由于需要仔细审查，因此发放需要花费数天甚至数周时间。如果你的证书到期，你可能会在没有适当安全保护的情况下度过数天。
如何获取和安装 SSL 证书 每个服务器平台都有自己的步骤来生成证书请求和安装已发行的证书。但常见的步骤包括以下内容：
生成 证书签名请求 （CSR ）
从 CA 订购 SSL 证书
从 CA 下载中间证书
在服务器上安装中间证书
今天可以选择多个证书颁发机构，例如 GeoTrust、DigiCert、Symantec 和网络解决方案。你可以比较他们的价格以及他们提供的证书类型，以找到最适合你的解决方案。我们将在本章后面回顾不同类型的证书。
传统上，你从你的 web 服务器软件或管理面板生成一个未签名的密钥。这通常是一个包含加密字符串的文件。你将此文件作为订单过程的一部分提交给 CA。
一旦验证过程完成，CA 将颁发证书，另一个文件。然后你的 web 服务器允许你为该网站安装证书。
今天，这个过程已经变得更加自动化。许多人将其作为一个包含在 web 服务器控制面板中的自动功能。许多人包括自动的 LetEncrypt.org 证书。
WordPress (wordpress.com/ ) 是采用 HTTPS-only 政策的最大玩家。他们在 2017 年使用内置的 Let's Encrypt 工具将他们托管的所有网站升级到 HTTPS。
亚马逊 AWS 为 Cloud Front 和他们的网络负载均衡器服务提供免费的证书。这些是域名验证证书，处理大约需要 30 秒；这是自 90 年代中期以来 SSL 世界发展到一个新高度的又一光辉例子。
将网站迁移到 HTTPS 无论你有一个新网站还是现有网站，你应该有一个系统来确保你的网站正确地实现了 HTTPS。安装证书只是这个过程的开端。你必须确保网站的不同方面都正确地引用 HTTPS。
这包括你页面中的链接，处理指向你网站的链接，以及你的分析和搜索引擎配置文件。
即使你的网站使用 HTTPS，任何包含 HTTP 内容的页面的 HTTP 部分都可能被攻击者读取或修改。当一个 HTTPS 页面包含 HTTP 内容时，它被称为 混合内容 。你可能认为页面是安全的，但它并不是因为混合内容。
当一个页面包含混合内容时，浏览器会有视觉提示来提醒用户该状态不安全。你不能仅仅依靠在地址栏看到 https 来信赖——寻找绿色的锁。以下截图显示了浏览器栏中的不安全 URL：
这张图片显示，尽管网站是通过 HTTPS 加载的，但微软的主页并不安全。它包含了对不安全资产的引用。以下截图是可能引起问题的示例：
迁移你的网站不仅仅是清理资产引用。本节应该是一个指南或清单，帮助你为你的网站定义一个 HTTPS 迁移策略。
作为额外的好处，这个列表可以作为你完整网站就绪检查单的一部分，因为它包括了一些经常被忽视的最佳实践。
无论你有一个单页网站还是包含数百万个 URL 的网站，你都需要审计每一页的外部 http:// 链接引用。这包括锚点标签以及你文档头部可能有的任何链接标签。
所有第三方托管资产，如 CSS、JavaScript 库、图像和字体在公共 CDN 上，以及第三方服务，如 Google Analytics （GA ），都是 HTTP 引用的主要目标。这些通常被忽视，因为它们不是由企业'拥有'的。
到现在为止，任何值得信赖的第三方服务都提供 HTTPS 支持。如果它不支持，你可能需要要求它们提供 HTTPS，或者如果它们拒绝，你可以寻找新的提供商。
与前面的 Microsoft 示例一样，你也应该确保你网站上所有对资产的引用要么是 HTTPS，要么根本不带协议。这将更新网站并准备好任何潜在的未来协议：
//:c.microsoft.com/trans_pixel.aspx
最佳实践是使所有引用无协议。与其将所有引用更改为 https://，不如将它们更改为 //。这种方法更具前瞻性，因为它使任何可能演变的未来通信协议更容易适应。
当使用无协议引用时，用户代理将其应用于资产或外部链接的主要协议。这样，用户应该有一个更无缝的浏览体验。
审计内容和数据 Google 建议你应该始终使用 HTTPS 协议引用外部 URL，以向排名引擎发送一个明确的信号，表明你的网站有 HTTPS。
内容，如博客或一般文本，通常通过内容管理界面由非开发者输入。这意味着原始内容或网站数据以某种形式保存在数据库中，并且不会成为源代码审计的一部分。
你可以爬取你的整个网站并生成报告。这可以通过简单的 node 模块或其他工具完成。同样，你也应该在网站持久化数据上运行脚本以查找外部 HTTP 引用。
关键是要审计你的整个网站以识别这些潜在问题。每个网站都将需要某种形式的定制审计和更新流程。我建议你尽可能自动化；这样，你可以快速更新并重复这个过程作为你构建的一部分。
更新内容后，部署（最好是到测试服务器）并审计结果。很可能会错过一些引用，需要解决这些问题。纠正这些问题并再次尝试，直到通过测试。
更新社交媒体链接 我想强调社交媒体链接作为前一步的常见例子。所有社交媒体网络都使用 HTTPS。由于大多数网站将社交媒体配置文件作为网站主要布局的一部分进行链接，因此这些应该是你首先更新的链接。
由于这些链接通常包含在网站页眉、页脚或两者中，它们会传播到每个页面。从源代码的角度来看，这个 app-shell 文件是一个单独的文件，在这些审计中，它通常会被忽略。
当全局更新某些内容，例如用于引用链接的协议时，你需要审计你的源代码以及你的内容。这包括每个原型文件，例如主布局文件和子布局文件。
配置服务器自动将 HTTP 重定向到 HTTPS 旧链接和自然消费者倾向是通过 HTTP 引用 URL。你的 Web 服务器应该配置为向用户代理发送一个 301 重定向，告诉他们永久加载 HTTPS 地址。
301 重定向是一个永久地址更改。你正在告诉用户代理他们正在寻找的地址不再有效，而应转到新的地址。通过将 HTTP 重定向到 HTTPS，你实际上在告诉全世界不再请求不安全的内容。
这个过程因 Web 服务器而异，因此请查阅你平台的文档以获取更多指导。大多数服务器可以通过简单的设置来完成此操作。
如果你正在使用内容分发网络，并且你应该为任何消费者网站这样做，你应该能够在你的 CDN 配置中配置此重定向。
301 重定向通过接收用户代理的请求并在服务器的响应中包含一个 301 头来实现。例如，对 www.example.org 的 HTTP 请求看起来如下：
GET / HTTP/2
Host: www.example.org
服务器返回一个包含永久位置的 301 响应，如下面的代码所示：
HTTP/2 301 Moved Permanently
Location: https://www.example.org/
你还应该在更改网站路由时配置适当的 301 重定向。当从 HTTP 迁移到 HTTPS 时，你正在更改网站中的每个路由。
在网站管理工具中添加并验证所有域名协议组合 在网站管理工具中添加和验证所有域名协议组合是另一个常被忽视的迁移任务。如果你对搜索引擎排名认真，你将使用 Google 和必应的网站管理工具正确注册你的网站。
关于这两个网站管理平台的详细信息超出了本书的范围。
最佳实践是注册你的网站可能被引用的所有四种方式。你应该为你的主域名和 www.别名注册 HTTP 和 HTTPS 版本。如果你没有全部注册，你的网站将不是完全注册的，可能会遇到一些搜索引擎排名问题。
定义一个规范 HTTPS 链接 你可能还会忽视的另一个 SEO 实践是定义规范链接。Google 和其他搜索引擎使用这个信号来了解内容的原始来源。在这种情况下，任何使用 HTTP URL 的引用都将被视为 HTTPS 版本的重复。以下代码为例：
<link rel ="canonical" href ="http://example.com/foo" >
<link rel ="canonical" href ="https://example.com/foo" >
这样可以避免重复内容的惩罚，在这种情况下，这会稀释链接流量。通过定义 canonical 链接，您告诉搜索引擎将排名权威导向何处。
将 Google 分析更新为默认使用 HTTPS 您应该进行的另一个更新涉及您的分析服务。由于 GA 是最常见的消费者服务，我将演示如何更新 GA。
在当前的 GA 仪表板中，菜单底部有一个 ADMIN 选项。
这将打开您网站的行政界面。中心列的属性有一个属性设置选项。选择它：
在属性设置面板中，将默认 URL 更改为使用 HTTPS 协议并保存：
就像您更新网站源代码和内容一样，您也应该确保您的 sitemap.xml 和 RSS 源已更新以使用 HTTPS。这些文件被搜索引擎和当然，任何订阅您 RSS 源的人使用。它们充当您网站的一个已知目录。
您网站地图中的链接被认为是搜索引擎的权威来源。您 RSS 源中的链接传播到订阅者，因此是许多活跃访客进入您网站的方式。确保以最佳方式引导他们进入非常重要。
更新您的 robots.txt 文件 如果您的 robots.txt 文件包含完整的 URL，您也应该更新这些。一般来说，如果您允许和拒绝蜘蛛访问，您包括相对路径。您最有可能有完整引用的文件是您的 sitemap 文件：
User-Agent: *
Disallow:
Sitemap: https://example.com/sitemap.xml
虽然不太常见，但一些网站为搜索引擎蜘蛛维护一个 disavow 文件。他们这样做是为了避免负面链接的惩罚。此文件也应更新为使用 https://，这加强了网站协议配置文件与搜索引擎的联系。
摘要 正如您所看到的，HTTPS 的实施很重要，但确实需要您的一些勤奋来正确配置您的网站。随着 TLS、证书和 HTTP 的进步，之前阻碍网站实施 HTTPS 的障碍已被消除。
进步式网络应用需要 HTTPS，因为它提供了更高的用户体验。它们还需要一个注册的服务工作者，这也需要 HTTPS。HTTPS 解锁了现代网络的功能；没有它，您的网站将被限制在更小的功能集。
由于 TLS 确保客户端和服务器之间的对话不会被中间人篡改，并且因为窃听被减轻，所有网站都应该采用 HTTPS。您正在为您的客户提供一层信任，并为网络提供的最新功能打开大门。
第四章：服务工作者 – 通知、同步以及我们的播客应用 在第一章，'渐进式 Web 应用简介'中，您了解到网络在移动时代的表现不足，以及为什么渐进式 Web 应用可以使您的网站达到与原生选项相当甚至更好的能力。服务工作者是渐进式 Web 应用最重要的部分，因为它们是应用的骨架。
网络清单和主屏幕图标增强了与客户建立关系和控制启动体验的能力。服务工作者在页面加载时以及页面未加载时都允许程序化地增强用户体验。
服务工作者位于浏览器和网络之间，充当代理服务器。它们提供的不仅仅是缓存层；它们是一个可扩展的骨干：
对于程序员来说，服务工作者 是 JavaScript 文件，这使得它们对大多数 Web 开发者来说都很熟悉。这些脚本更像是 Node.js 模块，而不是网页脚本。它们在 UI 服务工作者之外的一个单独线程上执行，因此它们无法访问 DOM。
服务工作者编程模型比您可能用于用户界面的模型更功能化。将服务工作者编程与无头节点比较是有意义的，因为服务工作者编程用于执行计算，许多任务传统上是为 Web 服务器保留的。
服务工作者与 UI 脚本也有所不同，因为它们是完全异步的。这意味着一些 API，如 XHR 和 localStorage，不支持。相反，您应该使用 Fetch API 和 索引数据库 （IDB ）来与 API 和持久化数据连接。当浏览器支持服务工作者时，它们也必须支持 promises，提供自然的异步接口。
关于 XMLHttpRequest 的注意事项，当从客户端发起时，请求会通过服务工作者。您不能从服务工作者中发起 XHR 请求。
服务工作者被设计成一个可扩展的平台，允许随着时间的推移添加额外的 API。缓存是规范中详细说明的唯一扩展 API。原生推送通知和后台同步是服务工作者启用的一些额外 API 示例。未来，您可以期待添加更多 API。
缓存使得离线和即时资产加载成为可能。我认为描述这个功能的最佳术语是浏览器中的代理服务器。高级服务工作者几乎像是一个完整的 Web 服务器堆栈。一个精心制作的服务工作者可以承担目前分配给 ASP.NET、Node Express、Ruby 等任务的渲染责任。
上一章介绍了如何为您的网站添加 HTTPS。如果您之前还没有被这个概念说服，现在应该会了。服务工作者也需要 SSL。服务工作者需要 SSL 的主要原因是为了启用需要更高信任级别的 API 和其他功能。
已启用的强大服务工作者可能被用于邪恶目的。除了需要 SSL 之外，它们的作用域也限制在单个域。它们没有能力操纵域之外的内容。
这是一件好事，因为第三方脚本无法注册服务工作者并对您的网站造成破坏。
表面上看，这可能看起来很简单，但掌握服务工作者需要一定的技巧。以下章节旨在为您提供创建能够增强任何网站的服务工作者所需的基础知识。
服务工作者线程模型
服务工作者浏览器支持
示例播客应用程序的工作原理
fetch API 简介
如何创建基本服务工作者
服务工作者生命周期
服务工作者缓存基础
如何使用推送通知
背景同步编程简介
服务工作者线程 服务工作者在 UI 之外自己的上下文或线程中运行。因为服务工作者线程与 UI 分离，所以它无法访问 DOM。
服务工作者的作用域是事件驱动的，这意味着平台（根据您的观点，是浏览器或操作系统）启动服务工作者。当服务工作者启动时，它是以响应某个事件为目的，例如网页打开、推送通知或其他事件。
进程保持活跃足够长的时间以服务需求。这个时间由浏览器决定，并且因平台而异。服务工作者规范中没有定义固定的时间。
在与正常 JavaScript 不同的上下文中运行为服务工作者提供了许多优势。首先，服务工作者脚本不会阻止 UI 渲染。您可以使用此功能将非 UI 工作卸载到服务工作者。我们将在后面的章节中看到一个示例，展示如何使用客户端模板在服务工作者而不是 UI 线程中渲染标记。
这为您提供了将任务分离到更合适的线程中的方法。现在，您可以在响应 API 调用时执行计算，如数学或渲染标记，然后将结果返回到 UI 线程以更新 DOM。
服务工作者可以通过消息 API 与 UI 线程通信。您可以在线程之间传递文本消息。您还可以在它们到达 UI 线程之前修改来自服务器的响应。
像推送通知这样的功能之所以可行，是因为服务工作者在自己的上下文中执行。服务工作者可以响应操作系统触发的事件而启动，而不是因为页面加载。
在过去，基于 Web 的推送通知可以通过使用 Web 工作者来实现。这些工具很棒，但只有在浏览器打开时才会执行。服务工作者与之不同，因为操作系统可以因为外部刺激而启动它们。唯一真正的要求是客户端设备应该处于开启状态。
服务工作者浏览器支持 服务工作者是一项相对较新的技术，因此人们常常会问：使用服务工作者是否安全？我们真正想问的是，有多少浏览器支持服务工作者？
好消息是所有主要的浏览器都已经发布了基本的服务工作者支持。Chrome 一直是领导者，因为他们在很大程度上负责启动这一概念并管理规范。这项技术得到了包括微软、Firefox、三星和 Opera 在内的其他浏览器厂商的热烈支持。
截至 2018 年春季，所有现代浏览器都已向普通消费者发布了更新，至少支持服务工作者缓存功能。当然，旧浏览器不会支持服务工作者。但随着消费者升级手机和笔记本电脑，它们的用量正在减少。
微软 Edge 服务工作者支持 在 2017 年 9 月的 Edge Web Summit 上，微软宣布他们将在标志后发布服务工作者支持。目标是解决实现中的任何错误，在向普通消费者发布支持之前。
2018 年春季，随着 Windows RS4 的发布，服务工作者的支持被推向了普通消费者。
Safari 服务工作者支持 如果您不熟悉苹果如何宣布 Web API 支持，他们不会这样做。新功能会悄悄发布，至少在大多数情况下，留给开发者去发现。
在一个令人惊讶的发布中，苹果在 2018 年 3 月更新了 Safari，以支持服务工作者：
Safari 服务工作者支持存在一些限制。目前，它们不支持原生推送通知或后台同步。我不认为这些缺失的功能是避免在您的应用程序中集成它们的原因。记住，渐进式 Web 应用是关于利用可用功能的。您仍然可以创建可行的解决方案来绕过这些功能。
服务工作者是否准备好了？ 该网站有行，专注于每个主要服务工作者功能和它们的要求，以及每个浏览器的图标。灰度浏览器图标表示支持尚未发布。背景为黄色的图标表示已发布部分支持。绿色背景表示对功能的完全支持：
如您所见，主要的浏览器厂商都支持服务工作者（service workers）。
现在所有现代浏览器都支持服务工作者，你可能认为没有必要担心不支持服务工作者的浏览器。但仍有相当一部分浏览器会话使用 Internet Explorer 和遗留的 Android 浏览器。这意味着你可能需要考虑回退选项。
Polyfilling 更旧的浏览器 Polyfills 是你可以按需引用的库或回退，用于向不支持现代功能的浏览器添加对现代特性的支持。并非所有现代特性都可以通过 Polyfills 实现，但许多可以。有些不是直接的 Polyfills，而是利用其他 API 来创建所需体验。
好消息是你可以将服务工作者缓存 Polyfill 到一定程度。这可以通过 IndexedDB 实现。你需要额外的 JavaScript 层来管理网站的资产和 API 调用。我们将在高级缓存章节中涉及此技术。
除了使用 IndexedDB 缓存资源外，你还可以使用 appCache 作为离线和资源缓存的回退。
推送通知无法通过 Polyfills 实现，但你可以利用替代的通知媒介。短信文本和 Web Worker 通知可以为业务与客户互动提供方式。
播客应用程序 本章向您介绍不同的服务工作者概念和功能，如服务工作者生命周期、缓存和推送通知。为此，我们将构建一个简单的播客应用程序。此应用程序将展示如何处理服务工作者生命周期和响应缓存：
最基本的播客应用程序需求包括：
快速加载
搜索播客
收藏播客
播放音频文件
持久化剧集以供离线收听
你将学习如何注册服务工作者、服务工作者生命周期的基本知识、服务工作者缓存的工作原理以及如何使用 IndexedDB 持久化数据。你还将看到如何利用服务工作者缓存和 IndexedDB 持久化 MP3 媒体文件。
播客应用程序源代码按文件夹组织，这些文件夹与每个章节的进度相关联。根文件夹包含定义运行本地 Web 服务器的 Grunt 任务等常见文件，就像 2048 应用程序一样。
在每个章节的文件夹中，有用于资产（如 CSS、JavaScript 和图像）的文件夹。每个路由都有一个包含单个 index.html 文件的文件夹。这允许应用程序使用无扩展名的 URL。数据文件存储在 API 文件夹下。
/(home)/podcasts//podcast/{slug}/episode/{slug}/search?q={term}/later/
每个页面都是一个静态页面，作为网站构建过程的一部分预先渲染。背后的逻辑超出了本书的范围。
应用程序的数据来自 iTunes API。它确实需要一些数据处理才能在应用程序中使用。如果您想使用或研究这些数据，我已经将这些原始数据文件包含在 GitHub 仓库中。
苹果的数据模型需要转换为应用程序。而不是建立一个 Web 服务器来托管正式的 API，数据存储在一系列 JSON 文件中。应用程序将根据需要引用这些文件。
服务工作者位于应用程序的根目录中。这个文件是本章的核心，我们将花费大部分时间在每个章节中修改它。它将演示服务工作者生命周期和基本缓存概念。
首页包含用户订阅的播客列表。这是通过 API 调用检索列表来填充的。然后使用 Mustache 在浏览器中渲染。所有 API 数据都是一组 JSON 文件，因此不需要编写杂乱的代码来连接和建立数据库：
播客页面显示了播客的详细信息以及最近集锦的列表。播客数据也是通过 API 调用检索的：
集锦页面列出了集锦的标题和描述。它包括一个播放 mp3 文件的 AUDIO 元素。同样，页面在从服务器检索数据后进行渲染：
Fetch API 回到 1996 年，Internet Explorer 引入了 iframe 元素，作为在网页中异步加载网页内容的一种方式。在接下来的两年里，这个概念发展成了我们现在所知道的 XMLHttpRequest 对象的第一种实现。
当时，它被称为 XMLHTTP，并首次在 Internet Explorer 5.0 中发布。不久之后，Mozilla、Safari 和 Opera 都发布了我们现在称之为 XMLHttpRequest 的实现。
到目前为止，网页是静态的，当用户在同一个站点内从一个页面导航到另一个页面时，需要整个页面重新加载。
在 2004 年，谷歌开始在 Gmail 和 Google Maps 中广泛使用我们现在称之为 AJAX 的技术。他们向我们展示了如何利用浏览器对服务器的请求以及如何根据服务器的有效载荷来操作 DOM。这通常是通过调用返回 JSON 数据的 API 来完成的。
就像任何技术一样，随着它的使用，实施者 在处理使用过程中暴露的问题时会感到沮丧。为了应对新的用例和问题，技术会更新，通常是通过发布新版本。
有时，这些更新如此重大，以至于新的技术、产品或实现取代的第一个版本。
XMLHttpRequest 提供了一种机制来对服务器进行异步调用，但它基于十年前网络和浏览器的工作方式。
今天，网络在许多方面都得到了扩展。我们现在普遍支持的一个特性是 JavaScript Promises。我们也对可以使用异步调用服务器的内容类型有了更深入的了解，这些内容类型是我们当初在 AJAX 最初被指定时没有考虑到的。
介绍 Fetch 在确定了 XMLHttpRequest 对象的常见限制之后，Fetch API 被标准化，以提供一种新的、经过深思熟虑的方式来实现异步 HTTP 请求。
Fetch API 是制作 AJAX 调用的一种全新的方式。它被创建出来是为了解决我们开发者为了处理 XMLHttpRequest 限制而进行的许多黑客式和绕道工作。主要区别在于，当使用 Promises 时，Fetch 是异步的。
它最初在 2016 年春季开始看到浏览器实现，现在所有现代浏览器都广泛支持。如果你还没有开始使用 Fetch 来制作异步 HTTP 请求，你应该尽快开始迁移。
Fetch 与 XMLHttpRequest 对象区别的三个关键特性是更简单的语法、原生的 promise 支持和能够操作请求和响应：
使用 Fetch API 由于 AJAX 已经成为驱动 DOM 操作的一种流行方式，让我们看看如何使用 Fetch 来实现这一点。这将会是一个稍微人为构造的例子，其中 Podcast 的标志被获取并设置到相应的 IMG 元素中：
var logo = document .querySelector ('.podcast-logo' );
fetch ("…/600x600bb.jpg" ).then (function (response ) {
return response.blob ();
}).then (function (logoBlob ) {
var objectURL = URL .createObjectURL (logoBlob);
logo.src = objectURL;
});
如果你熟悉如何组合 XMLHttpRequest，这个例子看起来应该非常干净和简单。你首先会注意到，唯一需要的参数是一个 URL。这是 fetch 的最简单形式。
这段代码做的是同样的事情，但使用了 XMLHttpRequest 对象：
var xhr = new XMLHttpRequest ();
xhr.open ("GET" ,"…/600x600bb.jpg" ,true );
xhr.overrideMimeType ('text/plain; charset=x-user-defined' );
xhr.send (null );
xhr.onreadystatechange =function (if (xhr.readyState ==4 ){
if ((xhr.status ==200 )||(xhr.status ==0 )){
var logo = document .querySelector ('.podcast-logo' );
logo.src ="data:image/gif;base64," +encode64 (xhr.responseText );
}else {
alert ("Something misconfiguration : " +
"\nError Code : " + xhr.status +
"\nError Message : " + xhr.responseText );
}
}
};
这并不完全干净，也不是异步的。这个例子相当简单。在大多数情况下，AJAX 请求需要更多的复杂性。
fetch 方法返回一个 promise，它解析一个响应对象。这代表的是响应，而不是我们想要的图片。通过调用 blob mixin 来访问图片，它也返回一个 promise。
Blob 是图片，然后可以使用 URL.createObjectUrl 函数将其字节转换为可用的图片格式，并将其应用于图片的 src 属性。
虽然这个例子是人为构造的，但它展示了 Fetch API 的多个方面，你应该熟悉这些方面。API 提供了一个简单的表面来发起请求，但它允许你实现非常复杂的请求处理逻辑。
除了 fetch 方法外，API 还指定了请求、响应和头对象。还有一个 body mixins 集合，用于操作不同的响应类型。
你不仅可以向 fetch 方法传递 URL，还可以传递一个组合的请求对象。请求对象包含进行网络请求的值。
请求构造函数有两个参数，即 URL 和一个可选的选项对象。你也可以提供一个现有的请求对象，这听起来可能有些奇怪，但随着你对服务工作者学习的深入，你会意识到这将成为一个常见的起点。
method：HTTP 请求方法：GET、POST、PUT、DELETE 等。headers：自定义请求头，可以是头对象或对象字面量。body：你想要添加到请求中的任何主体：一个 Blob、BufferSource、FormData、URLSearchParams、USVString 或 ReadableStream 对象。mode：请求模式，例如，cors、no-cors、same-origin 或 navigate。默认是 cors。credentials：你想要用于请求的请求凭据：omit、same-origin 或 include。cache：类似于 Cache-Control 头中使用的属性。这告诉浏览器如何与本地缓存交互。 其他不太常见的属性是 cache、redirect、referrer 和 integrity。
我们可以使用前面的示例并扩展它以使用自定义请求对象：
var logoHeaders = new Headers ();
logoHeaders.append ('Content-Type' ,'image/jpeg' );
var logoInit = {
method :'GET' ,
headers : logoHeaders,
mode :'cors' ,
cache :'default'
};
var logoRequest = new Request ("…/600x600bb.jpg" , logoInit);
fetch (logoRequest).then (function (response ) {
return response.blob ();
}).then (function (logoBlob ) {
logo.src = URL .createObjectURL (logoBlob);
});
你应该注意，fetch 方法只有在出现网络错误时才会拒绝。当抛出异常时，网络无法访问，例如，当设备离线时。它不会因为非 2XX 状态码而失败。
这意味着你必须验证响应是良好的、未找到、重定向还是服务器错误。你可以构建一个健壮的逻辑树来处理不同的状态码。如果你只需要响应良好的请求，你可以使用 response.ok 属性。
如果响应的状态是 200-299，即良好，那么 ok 属性为真。否则，为假。
你应该以不同的方式处理异常和具有状态码的响应。例如，如果一个响应的状态码是 403，那么你可以重定向到一个登录表单。404 状态应该重定向到一个未找到页面。
如果出现网络错误，你可以触发适当的视觉响应，如错误消息或触发应用程序的离线模式体验。
响应对象 fetch 方法解析响应对象。这与请求对象类似，但有几个区别。它代表对请求的服务器响应。
headers：头对象ok：指示状态是否在 200-299 范围内redirected：指示响应是否来自重定向status：HTTP 状态码，例如，200 表示良好statusText：对应代码的状态消息type：响应类型，例如，cors 或 basicurl：响应 URLbodyUsed：一个布尔值，指示主体是否已被使用
clone：创建响应对象的副本arrayBuffer：返回一个解析为 arrayBuffer 的承诺blob：返回一个解析为 blob 的承诺formData: 返回一个解析为 formData 对象的承诺json: 返回一个解析正文为 JSON 对象的承诺text: 返回一个解析正文为承诺 之前的示例展示了如何使用 blob 方法创建图像。网络应用程序更常见的任务是从 API 获取数据。通常，响应是文本，包含 JSON。
在播客应用程序中，一个常见的用户任务是在播客和剧集之间进行搜索。我们的播客应用程序在布局标题中集成了搜索表单。它绑定了一些逻辑来调用 API 并返回一组结果。
Podstr 应用程序使用单个 JSON 文件作为示例搜索结果。这样做是为了我们不需要构建服务器端搜索基础设施。生产应用程序将有一个更正式的设置。
搜索结果格式化为包含两个数组，一个是匹配的播客列表，另一个是匹配的剧集列表：
[ podcasts: [ { …} ] , episodes: [ { …} ] ]
搜索结果通过在模板上渲染结果来在搜索页面上显示。检索结果是通过使用 JSON 方法的 fetch 请求完成的：
var searchResults = document .querySelector ('.search-results' );
fetch ("api/search?term={term}" ).then (function (response ) {
return response.json ();
}).then (function (results ) {
renderResults (results);
});
renderResults 函数将结果对象通过 Mustache 模板运行，并将渲染的标记分配给 search-results 元素：
function renderResults (results ) {
var template = document .getElementById ("search-results-template" ),
searchResults = document .querySelector ('.search-results' );
searchResults.innerHTML = Mustache .render (template.innerHTML , results);
}
搜索页面展示了如何动态组合页面进行 API 调用。这在今天的网络应用程序中很常见。我们不再来回走动，让服务器根据操作（如提交表单）渲染新的标记。
相反，我们迁移到了一个演变成我们通常称为的单页应用程序的模式。页面不再是静态体验，我们可以动态地更改它们。
能够在不进行完整往返的情况下向服务器发起 API 调用。Fetch 使得这成为可能，并且比之前更简单。模板库如 Mustache 使得在客户端渲染标记变得简单。
如果你熟悉 jQuery 的 ajax 方法，你会注意到与 fetch 的一些相似之处。但也有一些关键的区别。
从 fetch() 返回的承诺不会在 HTTP 错误状态上拒绝，即使响应是 HTTP 404 或 500 错误。相反，它将正常解析（ok 状态设置为 false），并且只有在网络失败或任何阻止请求完成的情况下才会拒绝。
默认情况下，fetch 不会从服务器发送或接收任何 cookies，如果网站依赖于维护用户会话（要发送 cookies，必须设置 credentials 初始化选项），则会导致未认证的请求。
服务工作者 fetch 服务工作者依赖于 promises 和异步 API。这消除了在服务工作者中使用 XMLHttpRequest 等平台功能。服务工作者依赖于浏览器支持 promises 和 fetch API。
对 fetch 的基本理解是服务工作者编程所需的基本技能。服务工作者允许你在网络请求发送到网络之前拦截所有网络请求。这是通过添加一个 fetch 事件处理器来完成的：
self.addEventListener ('fetch' , function (event ) {
event.respondWith (
caches.match (event.request ).then ((response ) => {
if (response) {
return response;
}
return fetch (event.request );
})
);
});
事件处理器接收一个单一的 FetchEvent 对象。你需要了解 FetchEvent 对象的两个成员，它们是 request 和 respondWith。
请求属性是正在发送到网络的请求对象。respondWith 方法限制了 fetch 事件处理器。它保持事件处理器 打开 ，直到响应准备好。该方法还需要返回一个响应对象。
服务工作者 fetch 事件允许你拦截对网络的请求。这种力量允许你调查请求并返回一个缓存的响应，组合一个自定义响应，或者返回一个网络响应。我们将在服务工作者缓存章节中介绍如何使用这种力量的方法。
在旧版浏览器中 polyfill fetch Fetch 和其他现代 API 得到了主流浏览器的广泛支持。然而，仍然有足够的用户在使用较旧的浏览器。许多企业仍然要求员工使用过时的 Internet Explorer 版本。许多消费者对旧手机感到满意，不升级他们的设备或更新软件。
这意味着我们需要使我们的网站适应这些潜在的情景。幸运的是，许多 API 可以用 JavaScript 库进行 polyfill。Fetch 和 promises 是现代功能，可以轻松地进行 polyfill。
就像我们检测服务工作者支持一样，我们也可以检测 fetch 和 promise 支持。如果这些功能不受支持，那么我们可以加载一个 polyfill。重要的是这些 polyfills 需要按照依赖顺序加载，其中 promise 之后是 fetch，然后是任何特定于网站的代码：
var scripts = ["js/libs/jquery.small.js" , "js/libs/index.js" , "js/libs/collapse.js" , "js/libs/util.js" , "js/app/app.js" ];
if (typeof fetch === "undefined" || fetch.toString ().indexOf ("[native code]" ) === -1 ) {
scripts.unshift ("js/polyfill/fetch.js" );
}
if (typeof Promise === "undefined" || Promise .toString ().indexOf ("[native code]" ) === -1 ) {
scripts.unshift ("js/polyfill/es6-promise.min.js" );
}
这种技术使用一系列脚本 URL，并遍历它们，将每个添加到 DOM 中，同时保持依赖顺序。
由于 polyfills 不是总是需要的，它们只有在必要时才添加。这是通过检查原生支持来确定的。在示例代码中，promise 和 fetch 都被检测到。如果不支持，则将它们添加到脚本 URL 数组中，并在其他脚本之前添加。
承诺也被检查，因为 fetch 依赖于 promise 支持。Podstr 应用程序只需要可能使用 fetch 和 promise polyfill。
创建服务工作者外壳 在第一章，'渐进式 Web 应用简介'中，我们创建了一个基本的 service worker，它预先缓存了 2048 游戏资源。在本章和接下来的章节中，我们将更深入地探讨 service worker 的细节。
服务工作者在其整体生命周期中经过几个阶段。服务工作者被注册。一旦脚本被加载，它就会触发'安装'事件。此时，服务工作者不控制客户端（浏览器标签页）。
当服务工作者被清除以控制客户端上下文时，激活事件被触发。在此之后，服务工作者完全活跃并控制任何活跃的客户端，无论是标签页还是后台进程。
合适的服务工作者利用事件生命周期来管理数据，如缓存的响应，以设置服务工作者上下文。
播客应用程序从包含安装、激活和 fetch 事件处理器的简单服务工作者脚本开始：
self.addEventListener ('install' , (event ) => {
});
self.addEventListener ('activate' , (event ) => {
});
self.addEventListener ('fetch' , (event ) => {
});
随着这些章节的进展，我们将填充代码以使用每个这些处理器。这些更新将展示服务工作者生命周期、常见的缓存技术以及其他重要的服务工作者概念。
服务工作者生命周期 服务工作者遵循一个已知的生命周期，允许新的服务工作者在不干扰当前服务工作者的情况下准备自己。生命周期是为最佳用户体验而设计的。
当服务工作者被注册时，它不会立即控制客户端。有一些规则旨在最小化由于代码版本差异而导致的错误。
如果新的服务工作者在期望前一个版本逻辑时控制了客户端上下文，可能会出现问题。尽管服务工作者在单独的线程上操作，但 UI 代码可能依赖于服务工作者逻辑或缓存资源。如果新版本破坏，用户的用户体验可能会受到影响。
生命周期旨在确保在会话期间，作用域内的页面或任务始终由同一服务工作者（或没有服务工作者）控制：
生命周期包括注册、安装和激活步骤。安装和激活事件可以绑定处理器以执行特定任务。
生命周期还包括服务工作者更新和注销。这两个任务可能不会经常使用，但开发者仍然应该熟悉它们的工作方式。
每个阶段都可以用于不同的处理阶段来管理服务工作者、缓存资源和可能的状态数据。下一章将详细介绍生命周期以及如何利用每个阶段来提高应用程序的性能并使其更容易管理。
你将学习如何注册、更新和删除服务工作者。你还将了解服务工作者的作用域和服务工作者客户端的定义。本章还将涵盖安装和激活事件，以便你可以添加代码来管理服务工作者的缓存和活动状态。
缓存 最重要的渐进式网络应用程序功能之一是能够在离线状态下工作并即时加载。服务工作者缓存实现了这种超级功能。在过去，网站可以在离线状态下运行，甚至可以通过 appCache 获得一些性能优势。
服务工作者缓存取代了 appCache 并提供了更好的程序化接口。AppCache 因其难以管理和维护而臭名昭著。
当你的页面引用了 appCache 清单文件并且有注册的服务工作者时，服务工作者管理缓存，而 appCache 被绕过。这使得服务工作者缓存成为从 appCache 的渐进式增强，并且使用它们是安全的。
通过启用缓存，服务工作者使网络成为渐进式增强。因为服务工作者缓存 API 非常底层，它要求开发者应用自定义逻辑来管理网络资源如何被缓存和检索。
这为在你的应用程序中应用不同的缓存策略留下了很大的空间。第六章，'掌握缓存 API - 在播客应用程序中管理 Web 资源'，深入探讨了你需要掌握的核心服务工作者缓存概念。
使用推送通知 商业已经使用推送来吸引客户，即使他们的应用程序没有打开，也已经大约十年了。为什么不呢？研究表明，与品牌参与度和收入直接相关的数据相当令人印象深刻，这些数据与微小的中断有关。
通过推送通知访问的用户时间增加了 72%
通过推送通知到达的会员平均消费增加了 26%
+50% 在 3 个月内重复访问量增加
这些值都指向品牌和产品经理为什么喜欢推送通知的原因。不幸的是，直到最近，网络一直被排除在这个派对之外。许多企业选择通过原生应用程序的麻烦来发送推送通知。
Push API 为网络应用程序提供了从服务器接收消息推送的能力，无论网络应用程序是否在前台，或者当前是否在用户代理上加载。
在您的应用程序中实现推送通知需要基于服务器的服务，通常是云基础服务，如 Google Cloud Messenger 或 AWS Pinpoint。有众多提供商可供选择。
在撰写本书时，Chrome、Firefox、Samsung Internet 和 Opera 目前都提供了推送通知支持。Microsoft Edge 正在推出支持。苹果尚未发布 Safari 支持的时间表。
重要的一点是，每个浏览器或用户代理都独立于其他浏览器。如果客户从多个浏览器加载您的网页，每个浏览器都会注册一个服务工作者。如果每个浏览器还创建了推送通知订阅，用户可能会接收到多个通知。
这使得在您的应用程序服务逻辑中管理订阅逻辑变得很重要。这超出了本书的范围。作为生产逻辑的一部分，在尝试为推送通知注册用户之前查询您的服务器是一个好主意。有几种选项可以处理这种潜在情况，您需要确定最适合您应用程序的方案。
如果您的品牌也有提供推送通知的原生应用，那么它们也将是单独的订阅。这意味着您应该尽可能跟踪客户是否已经在设备上接收到了通知，以避免重复发送消息。
实现推送通知
如何订阅和取消订阅用户的推送消息
如何处理传入的推送消息
如何显示通知
如何响应用户点击通知
代码是 Podstr 应用程序的一部分。我不会介绍如何设置推送提供商，因为它们差异很大，且易于更改其管理界面。这会创造一个流动的环境，只会给读者和潜在提供商带来困惑。此外，单独强调一个提供商可能会产生不希望的偏见。大多数提供商都有当前的文档和 JavaScript SDK，可以帮助您创建服务器端环境。
对于我们的目的，Chrome 开发者工具提供了足够的功能来触发客户端逻辑和体验。您可以在注册的服务工作者详情右侧找到一个链接来模拟推送事件：
此链接触发一个带有简单负载的模拟推送消息：来自 DevTools 的测试推送消息。Podstr 应用程序将使用此事件来触发一个我们可以显示给用户的关于新播客剧集的消息。
设置推送通知 要启用推送通知，您需要遵循几个步骤。第一步是检测浏览器是否支持推送。如果是的话，然后您可以继续：
navigator.serviceWorker .register ('/sw.js' ).then (function (registration ) {
if ("PushManager" in window ) {
}
});
由于推送是在注册服务工作者之后配置的，因此您可以在服务工作者注册后检查其支持情况。就像检查服务工作者支持一样，您可以检查窗口对象是否包含对 PushManager 的引用。
PushManager 有三个方法来管理用户的订阅状态。getSubscription 方法返回一个解析为 PushSubscription 对象的承诺。如果用户已订阅，则订阅是一个对象，否则为 null。
如何在您的应用程序中呈现推送通知的状态取决于您。我个人的建议是，如果浏览器不支持推送通知，则隐藏任何可见的队列，因为这会混淆消费者。
大多数网站会简单地提示用户允许发送推送通知。发送通知的能力受用户批准的限制。当您尝试启动推送通知订阅过程时，浏览器会显示是或否的对话框。
允许用户选择退出推送通知也是一个好的实践。这可以在应用程序设置或配置页面上完成。Podstr 应用程序有一个设置页面，其中包括管理推送通知的选项：
管理推送通知订阅的代码将在本节后面介绍。您可以为用户提供一个界面，无论是作为被动选项，如配置页面，还是通过通知主动提供。
随着 Android 的发展，Chrome 和其他可能的 Android 浏览器将自动将添加到 homescreen 的渐进式 Web 应用程序转换为 WebAPKs。这些是享受与商店应用几乎同等地位的本地应用程序。它们应该具备的一个功能是通过平台设置应用程序在应用程序中管理推送通知的能力，但您永远不应该依赖这是关闭通知的唯一方式。
例如，Twitter 已经采用了渐进式 Web 应用程序并可以发送通知。我打开了它，但发现它只将通知推送到我的手机上的单个账户（Scott Hanselman）。虽然我喜欢 Scott，但我期待有更多的多样性。
我花了很长时间才发现如何管理 Twitter 通知。我找到了如何在 Chrome 中更快地阻止该网站通知的方法：
Twitter 有许多需要强大后端来管理的通知选项。Podstr 应用程序使用开或关的选择。如果这是一个生产应用程序，我会随着时间的推移构建出更多的逻辑，就像 Twitter 所做的那样。
管理用户的订阅 在示例代码中，如果订阅对象不存在，将调用 subscribeUser 函数。将服务工作者注册对象作为唯一参数传递：
registration.pushManager .getSubscription ().then (function (subscription ) {
if (subscription === null ) {
subscribeUser (registration);
}
});
pushManager 的订阅方法有一个单一参数，即一个具有两个属性的对象，userVisibleOnly 和 applicationServerKey。
订阅函数在用户已授予发送通知的权限并且浏览器向推送服务发送请求后返回一个解析的承诺。
作为订阅函数工作流程的一部分，用户代理需要提示用户许可。如果被拒绝，承诺将因 NotAllowedError 而拒绝。您应该始终为订阅调用包括一个 catch 处理程序。
用户代理不得在未经用户明确许可的情况下向网络应用提供推送 API 访问权限。用户代理必须通过用户界面为 subscribe() 方法的每次调用获取同意，除非之前的权限授予已被持久化，或者存在预安排的信任关系。超出当前浏览会话的权限必须是可撤销的。
userVisibleOnly 属性是一个布尔值，表示推送通知是否始终对用户可见。目前，您必须将此属性设置为 true，浏览器才会允许您订阅用户：
因此，目前您需要向最终用户显示一条消息，即使不需要用户反馈。例如，可以通过推送通知触发缓存策略来更新网站的缓存资源。在这些场景中，您将显示一个通知来提醒用户更新。
该值应该是 base 64 URL 安全编码。urlB64ToUnit8Array 函数将其转换为 UInt8Array，这是订阅函数所期望的。urlB64ToUnit8Array 是您可以在 Podstr 源代码中找到的实用函数。
用户代理应仅接受包含已订阅的 applicationServerKey 的通知。根据规范，这是一个建议，浏览器会遵守这一建议：
function subscribeUser (registration ) {
const applicationServerKey = urlB64ToUint8Array (applicationServerPublicKey);
registration.pushManager .subscribe ({
userVisibleOnly : true ,
applicationServerKey : applicationServerKey
}).then (function (subscription ) {
updateSubscriptionOnServer (subscription);
console .log ('User is subscribed.' );
}).catch (function (err ) {
console .log ('Failed to subscribe the user: ' , err);
});
}
一旦创建订阅，就不能更改。您必须从初始订阅中退订，并使用新选项创建新的订阅。例如，如果您应该更改您的推送服务，客户端将需要一个新的 applicationServerKey：
就像服务工作者中的所有事物一样，订阅函数返回一个承诺（promise）。如果没有异常，它将解析为一个 PushSubscription 对象。此对象包含有关订阅的各种值，这些值可能有助于构建更稳健的用户体验或管理逻辑。
endpoint：订阅端点expirationTime：除非订阅有过期时间，否则为 nulloptions：创建订阅时使用的选项的回声subscriptionId：订阅 ID
getKey：表示客户端公钥的 ArrayBuffertoJSON：订阅属性的 JSON 表示unsubscribe：启动订阅者退订过程 在成功订阅后调用的 updateSubscriptionOnServer 函数通常用于更新服务器。然而，对于我们的目的，它用于回显订阅对象属性：
{ "endpoint" : "https://fcm.googleapis.com/fcm/send/cRWeyfFxsE0:APA91bE8jAnZtPTHSG5pV9hNWtTdS_ZFZT7FTDEpDEYwf8f_FvwuiLc6YDtxNigxKzyHhj9yzbhlJ4zm3M3wt0w1JPYQ41yhF38yeXKhYVp_TFauMr_RnINOKiobCTCYIgj_X0PWlGQF" , "expirationTime" : null , "keys" : { "p256dh" : "BO0FEUNPej_U984Q-dVAvtv1lyIdSvOn01AVl5ALu8F-GPA7lTtZ8QfyiQ7Z12BFjPQLvpvypMrL4I6QqHy2wNg=" , "auth" : "lDiFiN9EFPcXm7LVzOYUlg==" } }
处理推送通知 在消费者确认推送通知订阅后，您可以向用户代理发送消息。当消息发送到设备时，它将确定应用消息的服务工作者并触发推送事件。
服务工作者需要一个推送事件处理程序，该处理程序接收一个事件参数。事件对象包含消息数据。
服务器可以在消息中发送任何文本。这取决于服务工作者解析消息并触发适当的工作流程。
PodStr 仅管理新播客的剧集通知。但零售商可能想要推广销售或提醒客户完成订单。您可能发送给客户的提示实际上没有限制。
后者消息可能不是一个简单的字符串——它可能是一个字符串化的 JSON 对象。如果您需要处理 JSON 对象，您需要测试它以查看它是否是有效的对象，然后再回退到字符串。您可能有的消息类型越多，您需要的事件处理程序逻辑就越复杂。
为了演示目的，Podstr 推送事件处理程序将创建一个包含有关新剧集详细信息的 options 对象。这包括剧集标题和播客标志：
{ "title" : "CodeWinds - Leading edge web developer news and training | javascript / React.js / Node.js / HTML5 / web development - Jeff Barczewski" , "description" : "episode description here" , "image" : "http://codewinds.com/assets/codewinds/codewinds-podcast-1400.png" }
推送消息由核心 serviceWorkerRegistration 对象的扩展处理，这些扩展在注册过程中或 getRegistration 方法中获取。我们感兴趣的方法是 showNotification 方法。
此方法有两个参数，一个标题和一个选项对象。标题应是一个描述通知的字符串。Podstr 应用程序将使用剧集的标题。
actions：一个对象数组，将显示用户可以选择的动作按钮。badge：当没有足够空间显示通知本身时，表示通知的图像的 URL。body：要显示在消息中的字符串。dir：通知的方向；可以是 auto、ltr 或 rtl。icon：通知图标的 URL。image：包含要显示在通知中的图像 URL 的字符串。lang：必须是有效的 BCP 47 语言标签，用于通知语言。renotify：如果通知使用标签进行重复显示，则可以将此设置为 true 以抑制振动和可听通知。requireInteraction：在较大屏幕上，如果此值为 true，则通知将保持可见，直到用户将其关闭。否则，Chrome 以及我假设的其他浏览器将在 20 秒后将通知最小化。tag：一个 ID，允许您在需要时查找和替换通知。这可以通过调用 getNotifications 方法来完成。vibrate：一个包含振动序列的数字数组。例如，[300, 100, 400] 将振动 300 毫秒，暂停 100 毫秒，然后振动 400 毫秒。data：这是一个开放字段，您可以按需填充。它可以任何数据类型，如字符串、数字、日期或对象。 action 属性允许您向通知添加一个或多个动作按钮。您可以在 notificationClick 事件处理器中处理此选择。
action：一个 DOMString，用于标识要在通知上显示的用户动作。title：一个包含要显示给用户的动作文本的 DOMString。icon：[可选] 包含要显示与动作一起的图标的 URL 的字符串： Podstr 服务工作者在通知事件的 data 字段中查找一个简单的 JSON 对象。它解析对象并构建一个通知对象。
在尝试解析文本时要小心，因为它可能不是一个 JSON 对象。处理这种情况的最佳方式是将解析方法和相关逻辑包裹在 try catch 语句中。这不是最好的场景，但现在是处理有效和无效 JSON 对象解析的唯一方法：
try {
var episode = JSON .parse (event.data .text ());
const title = episode.title ;
const options = {
body : episode.description ,
icon : 'img/pwa-podstr-logo-70x70.png' ,
badge : 'img/pwa-podstr-logo-70x70.png' ,
image : episode.image ,
vibrate : [200 , 100 , 200 , 100 , 200 , 100 , 200 ],
actions : [
{ action : "listen" , title : "Listen Now" , icon : 'img/listen-now.png' },
{ action : "later" , title : "Listen Later" , icon : 'img/listen-later.png' }
]
};
event.waitUntil (self.registration .showNotification (title, options));
} catch (e) {
console .log ('invalid json' );
event.waitUntil (self.registration .showNotification ("spartan obstacles" , {
body : 'Generic Notification Handler' ,
icon : 'img/pwa-podstr-logo-70x70.png' ,
badge : 'img/pwa-podstr-logo-70x70.png' ,
vibrate : [200 , 100 , 200 , 100 , 200 , 100 , 200 ]
}));
}
showNotification 方法在用户的设备上显示消息。该函数返回一个解析为 NotificationEvent 的承诺。
将 showNotification 方法包裹在 waitUntil 函数中可以保持事件处理器打开，直到承诺解析，这样服务工作者就不会终止。
NotificationEvent 对象有两个属性：通知和动作。通知是创建通知时使用的通知对象的副本。如果通知中有一个或多个动作按钮，动作值是通知对象中定义的动作对象的动作属性。
在我们的例子中，这个值将是 listen 或 later。你可以使用这个值来触发不同的响应流程。如果用户选择 listen，你可以直接进入剧集页面并开始播放剧集。如果他们选择 later，你知道要下载剧集的 mp3 文件并将其持久化到缓存中：
self.addEventListener ('notificationclick' , function (event ) {
if (event.action === "listen" ) {
listenToEpisode (event.notification );
} else if (event.action === "later" ) {
saveEpisodeForLater (event.notification );
}
event.notification .close ();
});
notification.close 方法可以编程关闭一个通知。
显示推送通知只需这些步骤。记住，处理推送通知的所有代码都在服务工作者中处理。目前，浏览器要求你在处理通知时显示一个可见的消息。这并不意味着通知需要用户交互。
推送通知可以触发在服务工作者中执行的操作逻辑，如更新缓存。如果你需要响应，你可以配置操作按钮并处理最终用户的选项。
取消推送通知订阅 我们需要实现的唯一推送通知任务是取消订阅的方式。这可以通过 pushManager 完成。
在我深入探讨取消用户推送通知订阅的细节之前，我想看看我们如何为用户提供一个界面来管理他们的订阅状态。
我更喜欢在网站的设置、配置页面或部分中包含一个管理界面。例如，Twitter PWA 有一个详细的推送通知配置体验。它有一个高级页面，包含链接到四个子页面，每个页面都提供了对不同通知方面的更精细控制。
它们被分组为过滤器或偏好设置。在过滤器组中，还有一个复选框来启用质量过滤器，这是一个非常高级的设置。
推送通知在自己的页面组中管理。它们有代码来检测网站是否启用了推送通知，如果是，则给用户一个选项来启用推送。一旦他们启用了推送，他们就可以根据活动类型定制他们的通知。
默认选项可能会导致发送大量通知。所以，如果你像我一样，花时间减少通知的数量。
Twitter Lite 应用可以作为详细推送管理界面的参考。幸运的是，Podstr 应用保持其通知简单。为了我们的目的，我们将提供一个界面来开启或关闭通知：
可以开启或关闭通知，这会触发客户端逻辑来管理订阅。应用程序必须根据用户切换选择来管理 subscribeUser 和 unsubscribeUser。
这就是为什么有单独的订阅和取消订阅方法。在我深入处理切换 UI 的代码之前，让我们回顾一下 unsubscribeUser 方法。
就像 subscribeUser 方法一样，unsubscribeUser 方法使用服务工作者的 pushManager.getSubscription 方法来获取当前订阅的引用（如果有的话）。
如果存在当前订阅，则调用订阅对象的取消订阅方法。取消订阅返回一个解析为布尔值的承诺，指示是否已取消订阅：
function unsubscribeUser (registration ) {
return registration.pushManager .getSubscription ().then (function (subscription ) {
if (subscription) {
return subscription.unsubscribe ().then (function (success ) {
console .log ("user is unsubscribed " , success);
});
}
}).catch (function (error ) {
console .log ('Error unsubscribing' , error);
});
}
如果服务工作者未注册，则任何相关的推送通知订阅都将被停用。
当通知订阅在应用程序的控制之外发生变化时，pushsubscriptionchange 事件在服务工作者中触发。您可以为该事件添加事件处理器来按需处理更改。
订阅状态可以通过消费者或服务自动更改。如果订阅已经过时，服务可能会删除订阅。在这种情况下，您可以创建一个自动重新订阅过程来续订订阅。
如果您正在重新订阅通知订阅，则必须使用与初始前端 JavaScript 中使用的页面相同的选项进行。您可以通过访问事件对象中的 oldSubscription 对象来访问之前的选项。
处理推送订阅变更 如果由于订阅过时而自动删除订阅，pushsubscriptionchange 事件特别有用。这可能会发生，因为许多推送服务出于安全和因不活跃而限制订阅的生存期。
就像身份验证令牌一样，推送订阅可以无缝续订，无需涉及用户。这就是您可以在服务工作者中为推送订阅做的事情。
pushsubscriptionchange 事件包含一个 oldSubscription 对象，其中包含原始订阅的详细信息。它们可以用来创建一个新的订阅：
self.addEventListener ('pushsubscriptionchange' , e =>waitUntil (registration.pushManager .subscribe (e.oldSubscription .options ).then (subscription =>这为您节省了在会话之间持久化值的麻烦。现在，您可以在不干扰最终用户的情况下，轻松地在服务工作者中重新订阅用户。
背景同步 服务工作者缓存允许网站离线渲染。但只有在您有页面和资源在缓存中可用时才有所帮助。如果您需要在离线状态下发送数据或获取未缓存的页面，您能做什么呢？
这就是背景同步可以帮助的地方。它使您能够注册一个请求，当设备重新上线时将得到满足。
背景同步在设备在线时在后台执行异步任务。它通过建立一个队列，当设备能够连接到互联网时立即满足请求。
背景同步的工作方式是您使用与 SyncManager 注册的标签放置一个网络请求。平台负责检查设备是否在线或离线。
如果无法发出请求，同步将请求放入该标签的队列中。背景同步定期检查发出请求的能力，但不会过多到耗尽您的电池或消耗过多的 CPU 周期。
后台同步模型可能需要一种新的方式来组织您的应用程序代码。为了正确使用同步编程，您应该将所有请求从任何事件触发器中分离成独立的方法。
例如，您不会在按钮点击事件处理器中直接进行获取调用，而是会调用一个从事件处理器获取资产的方法。这允许您更好地在后台同步注册中隔离调用。
Podstr 应用程序允许客户选择要离线收听的播客剧集。这需要用户选择剧集，应用程序将下载音频文件并存储以供离线播放。
当然，应用程序必须在线才能下载剧集。您可能还希望限制在设备连接到 WiFi 而不是蜂窝网络时下载大文件，如音频文件。
if ("sync" in reg) {
reg.sync .register ('get-episode' );
}
由于后台同步非常新，目前许多浏览器还不支持它。这应该会在不久的将来改变。例如，Edge 在服务工人标志后面提供了支持。
为了安全起见，在使用之前应该进行功能检测。这可以通过检查服务工人注册对象是否支持 "sync" 来完成。如果是这样，那么您可以注册请求；否则，您可以像普通请求一样发出请求。
同步请求是在您的 UI 代码中注册的，而不是在服务工人中。服务工人有一个同步事件处理器，负责处理网络请求。
后台同步就像一个基于云的消息平台。您不是直接放置请求，而是向一个队列或缓冲区发送消息，该队列或缓冲区可以被放置请求和响应双方访问。
在我们的示例中，Podstr 将离线剧集的请求存储在 IDB 中。这是因为它是一个异步数据存储，可供客户端代码和服务工人使用。我不会在本章中详细介绍它是如何工作的，因为我在第六章 掌握缓存 API - 在播客应用程序中管理网络资产 中会详细介绍，当我们深入探讨缓存时。
要使后台同步工作，您首先需要在 IDB 队列中放置一个消息。当服务工人收到处理稍后收听的剧集的同步事件（get-episode）时，它会检查 IDB 队列中的剧集并获取每个文件。
您可以通过调用同步的 register 方法来注册请求。此方法接受一个简单的标签名称。这个名称会被传递给服务工人的同步事件处理器。
服务工人注册一个单独的同步事件处理器。每次后台同步事件触发时，处理器都会接收到一个 SyncEvent 对象。它包含一个 tag 属性，通过提供的 tag 值来识别事件：
self.addEventListener ('sync' , function (event ) {
if (event.tag == 'get-episode' ) {
event.waitUntil (getEpisode ());
}
});
在这个例子中，你可以看到它在调用 getEpisode 函数之前正在检查标签的值。getEpisode 函数触发了检索收听稍后队列中剧集并为其离线持久化下载所需的任务。
你应该注意这个方法被包裹在 waitUntil 中。这是为了在执行后台任务时保持事件处理器处于活跃状态。下载一集播客可能需要几分钟，你不想服务工作者进程终止。
在这个例子中，播客剧集将在后台同步事件触发时下载。这意味着请求可能不会立即启动，但它们将会被下载。
奖励是，即使浏览器中没有加载 Podstr 页面，这些下载也会发生。此外，下载在后台线程中发生，释放了 UI 从这项繁琐的任务中。现在，消费者可以自由地在应用程序中导航，无需等待音频文件下载。
摘要 服务工作者令人兴奋，为开发者提供了一个构建丰富、引人入胜的用户体验的新环境，同时使用后台活动。本章介绍了不同的服务工作者概念和 Podstr 应用程序。
你现在已经看到了如何利用推送通知和后台同步来建立互动，即使客户没有查看你的应用程序。
在接下来的章节中，你将看到服务工作者生命周期和缓存的工作方式。到本节结束时，你将拥有一个简单的播客应用程序，展示如何使用服务工作者缓存、推送通知和后台同步来创建与使用网络技术构建的流行原生应用程序相媲美的用户体验。
相关免费在线工具 Keycode 信息 查找任何按下的键的javascript键代码、代码、位置和修饰符。 在线工具，Keycode 信息在线工具，online
Escape 与 Native 编解码 JavaScript 字符串转义/反转义；Java 风格 \uXXXX（Native2Ascii）编码与解码。 在线工具，Escape 与 Native 编解码在线工具，online
JavaScript / HTML 格式化 使用 Prettier 在浏览器内格式化 JavaScript 或 HTML 片段。 在线工具，JavaScript / HTML 格式化在线工具，online
JavaScript 压缩与混淆 Terser 压缩、变量名混淆，或 javascript-obfuscator 高强度混淆（体积会增大）。 在线工具，JavaScript 压缩与混淆在线工具，online
Base64 字符串编码/解码 将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
Base64 文件转换器 将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
