准备移除 AppCache

Chrome 85 默认移除了对 AppCache 的支持。大多数开发者都应立即从 AppCache 中迁出，而不应再等待。

Jeff Posnick

继以前的公告之后，我们将从 Chrome 和其他基于 Chromium 的浏览器中移除对 AppCache 的支持。我们建议开发者立即迁离 AppCache，不要再等待。

Service Worker 受到当前浏览器广泛支持，它提供了一种替代方案来替代 AppCache 所提供的离线体验。请参阅迁移策略。

时间轴

由于 Chrome 发布时间表发生了近期变化，因此其中某些步骤的时间可能会有所不同。我们将努力确保此时间表处于最新状态，但目前，请尽快从 AppCache 迁出，而不是等待特定里程碑。

“已废弃”功能仍然存在，但会记录警告消息，以劝阻用户使用。“已移除”功能已不再存在于浏览器中。

在不安全情境中弃用 Chrome 50（2016 年 4 月）
从不安全情境中移除 Chrome 70（2018 年 10 月）
在不安全的上下文中弃用 Web SQL Chrome 79（2019 年 12 月）
AppCache 范围限制 Chrome 80（2020 年 2 月）
“反向”来源试用计划开始 Chrome 84（2020 年 7 月）
从安全上下文中移除（已选择参与源试用的上下文除外） Chrome 85（2020 年 8 月）
完成源站试用，为所有人从安全情境中彻底移除 2021 年 10 月 5 日（大致相当于 Chrome 95）

来源试用

时间轴列出了两个即将到来的移除里程碑。从 Chrome 85 开始，Chrome 中将默认不再提供 AppCache。如果开发者需要更多时间才能从 AppCache 迁移，可以注册“反向”源代码试用，以延长其 Web 应用的 AppCache 可用性。源试用将从 Chrome 84 开始（在 Chrome 85 中默认移除之前），并将持续到 2021 年 10 月 5 日（大约 Chrome 95 发布之时）。届时，系统会为所有用户（包括已注册原始试用版的用户）彻底移除 AppCache。

如需参与“反向”来源试用，请执行以下操作：

  1. 为您的来源请求令牌。
  2. 将令牌添加到您的 HTML 网页。为此，您可以采用两种方法：
    • 在每个网页的标头部分添加 origin-trial <meta> 标记。例如：<meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
    • 或者，您也可以将服务器配置为返回包含 Origin-Trial HTTP 标头的响应。生成的响应标头应如下所示：Origin-Trial: TOKEN_GOES_HERE
  3. 将相同的令牌添加到您的 AppCache 清单。为此，请在清单中添加一个新字段，格式如下：
ORIGIN-TRIAL:
TOKEN_GOES_HERE

（ORIGIN-TRIAL 和令牌之间需要有新行。）

您可以在下方看到嵌入的示例项目，该项目演示了如何将正确的来源试用令牌添加到 index.html 和 manifest.appcache 文件中。

为什么需要在多个位置使用令牌？

同源试用令牌需要与以下各项相关联：

  • 使用 AppCache 的所有 HTML 网页。
  • 您的所有 AppCache 清单（通过 ORIGIN-TRIAL 清单字段指定）。

如果您过去曾参与过来源测试，则可能只在 HTML 网页中添加了令牌。AppCache“反向”来源试用特别之处在于，您还需要将令牌与每个 AppCache 清单相关联。

将源试用令牌添加到 HTML 页面后，您就可以在 Web 应用中启用 window.applicationCache 界面。未与令牌关联的网页将无法使用 window.applicationCache 方法和事件。没有令牌的网页也无法从 AppCache 加载资源。从 Chrome 85 开始，它们的行为将与 AppCache 不存在时一样。

将来源试用令牌添加到 AppCache 清单中表示每个清单仍有效。从 Chrome 85 开始，任何不含 ORIGIN-TRIAL 字段的清单都将被视为格式有误，并且清单中的规则将被忽略。

起源试用版部署时间安排和物流

虽然“反向”源测试将从 Chrome 84 开始正式启动，但您现在就可以注册源测试，并将令牌添加到 HTML 和 AppCache 清单中。随着 Web 应用的受众群体逐渐升级到 Chrome 84，您之前添加的所有令牌都将生效。

向 AppCache 清单添加令牌后，请访问 about://appcache-internals 以确认您的本地 Chrome 实例（84 版或更高版本）已正确将源试用令牌与您清单的缓存条目相关联。如果系统识别出您的来源试用，您应该会在该页面上看到一个带有 Token Expires: Tue Apr 06 2021... 的字段，该字段与您的清单相关联：

显示已识别令牌的 about://appcache-internals 界面。

移除前进行测试

我们强烈建议您尽快停止使用 AppCache。如果您想测试在 Web 应用中移除 AppCache，请使用 about://flags/#app-cache 标志来模拟移除 AppCache。从 Chrome 84 开始，此标志可用。

迁移策略

Service Worker 在当前浏览器中广受支持，是 AppCache 提供的离线体验的替代方案。

我们提供了一个 polyfill，它使用服务工作器来复制 AppCache 的部分功能，但不会复制整个 AppCache 接口。具体来说，它不提供 window.applicationCache 接口或相关 AppCache 事件的替代。

对于更复杂的情况，Workbox 等库提供了一种简单的方法，可为您的 Web 应用创建现代 Service Worker。

服务工件和 AppCache 是互斥的

在制定迁移策略时，请注意，Chrome 会在由 Service Worker 控制的任何网页上停用 AppCache 功能。换句话说，一旦您部署了用于控制给定网页的 Service Worker，便无法再在该网页上使用 AppCache。

因此，我们建议您不要尝试逐个迁移到服务工件。部署仅包含部分缓存逻辑的服务工件是错误的做法。您无法依赖 AppCache 来“填补空白”。

同样，如果您在移除 AppCache 之前部署了服务工作器，但后来发现需要回滚到之前的 AppCache 实现，则需要确保取消注册该服务工作器。只要有注册的 Service Worker 在给定页面的作用域内，就不会使用 AppCache。

跨平台故事

如果您想详细了解特定浏览器供应商的 AppCache 移除计划，建议您与相应供应商联系。

所有平台上的 Firefox

Firefox 在版本 44（2015 年 9 月）中弃用 AppCache，并且自 2019 年 9 月起在其 Beta 版和每夜 build 中移除对 AppCache 的支持。

iOS 和 macOS 设备上的 Safari

Safari 在 2018 年初弃用了 AppCache。

iOS 设备，Chrome 浏览器

Chrome（适用于 iOS）是一个特殊情况，因为它使用的浏览器引擎与其他平台上的 Chrome 不同：WKWebView。使用 WKWebView 的 iOS 应用目前不支持 Service Worker，并且 Chrome 的 AppCache 移除公告未涵盖 iOS 版 Chrome 上 AppCache 的可用性。如果您知道自己的 Web 应用拥有庞大的 Chrome for iOS 受众群体，请务必注意这一点。

Android WebView

某些 Android 应用开发者使用 Chrome WebView 来显示 Web 内容，可能还会使用 AppCache。不过，无法为 WebView 启用来源试用版。因此，在最终移除 AppCache（预计在 Chrome 90 中）之前，Chrome WebView 将支持无源测试的 AppCache。

了解详情

以下是面向从 AppCache 迁移到 Service Worker 的开发者的部分资源。

文章

工具

获取帮助

如果您在使用特定工具时遇到问题，请在其 GitHub 代码库中提交问题。

您可以使用标记 html5-appcache 在 Stack Overflow 上提出有关从 AppCache 迁移的常规问题。

如果您遇到与 Chrome 移除 AppCache 相关的错误，请使用 Chromium 问题跟踪器报告该错误。

主打图片基于 Smithsonian Institution Archives, Acc. 11-007, Box 020, Image No. MNH-4477.