准备移除 AppCache

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

我们之前曾宣布,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.htmlmanifest.appcache 文件中。

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

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

  • 使用 AppCache 的所有 HTML 网页
  • 通过 ORIGIN-TRIAL 清单字段提供您的所有 AppCache 清单

如果您过去曾参与过来源测试,则可能只在 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。

Service Worker 和 AppCache 是互斥的

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

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

同样,如果您在移除 AppCache 之前部署一个 Service Worker,然后发现需要回滚到之前的 AppCache 实现,则需要确保取消注册该 Service Worker。只要有注册的 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 代码库中提交问题。

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

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

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