3

我正在尝试从 AppCache 迁移到大型框架的 Service Worker（构造 2 - 请参阅 www.scirra.com）。很容易找到如何使用 Service Worker 缓存资源列表，然后在 fetch 事件中响应缓存条目的示例。但是，我发现 AppCache 的两个功能很难用 Service Worker 复制：

  1. 自动缓存主页。
  2. 通过在主页加载时请求单独的文件 (offline.json) 检查更新。

这两个都需要识别索引页（#2 将在请求索引页的同时检查更新）。但是，我发现自己陷入了看似不雅的解决方案。请注意，如果请求“foo/”，许多服务器会返回“foo/index.html”，但其他服务器不会，还有一些使用动态路径，因此我无法列出任何硬编码的主页 URL。我必须通过当前页面的 URL。

对于＃1，我在“安装”事件中跳过Waiting（），在“激活”中声明（）客户端，clients.matchAll（）迭代每个客户端，然后将client.url添加到缓存中。这似乎有点啰嗦，有没有办法在“安装”事件中获取主页 URL？

对于 #2，我必须在每个 fetch 事件中调用 clients.matchAll() 并测试当前请求 URL 是否与任何客户端 URL 匹配。如果它是主页，我会检查更新，否则正常处理。这看起来很不优雅，因为在页面加载时发生的数百个 fetch 请求中的每一个都必须不断获取所有客户端的列表并匹配它们的 URL。

有没有更好的方法从服务人员那里获取主页的 URL？

4

1 回答 1

1

我建议将其sw-precache纳入您的构建过程。它会为您生成一个服务工作者脚本，该脚本将负责预缓存您关心的资源，并在构建期间检测到更改时维护缓存（更新/添加/删除）条目。

对依赖于多个底层模板文件的预缓存 URL有一些支持，但您也可以与其他运行时服务工作者逻辑结合使用。是一个很好地补充并实现各种运行时缓存选项的库。sw-precachesw-precachesw-toolboxsw-precache

即使你不sw-precache直接使用，这里有一些从它的代码中提取的模式，你可以在你自己的服务工作者中遵循这些模式：

  • index.html如果请求URL以/. （在服务工作者中使用缓存存储 API时，将您用作键的 URL 标准化总是一个好主意。）

  • 依靠服务工作者生命周期来触发缓存管理，而不是获取带外“清单”。当您的浏览器注意到您的服务工作者脚本发生更改时，它会触发一个install事件，让您有机会缓存​​新条目，并触发一个事件，让您有activate机会进行缓存清理。这意味着只要缓存条目发生更改，您的底层服务工作者脚本就会更改。一个简单但容易出错的方法是在你的服务工作者脚本中包含一个版本字符串内联。一种不太容易出错的方法是在您缓存的底层资源发生更改时自动修改您的服务工作者脚本，这就是sw-precache为你做。在您控制的页面中，您可以侦听特定的 Service Worker 生命周期事件并显示“新内容可用；请刷新！” 留言之类的。

于 2015-10-13T17:15:50.910 回答