5

我正在使用sw-precachewithsw-toolbox以允许离线浏览 Angular 应用程序的缓存页面。

该应用程序通过 node express 服务器提供服务。

我们遇到的一个问题是index.html有时似乎没有在缓存中更新，尽管其他资产在激活新的 service worker 时已经更新。

在这种情况下，这会给用户留下一个index.html试图加载不再存在的版本化资产的过时资产/scripts/a387fbeb.modules.js。

我不完全确定发生了什么，因为似乎在index.html已正确更新的不同浏览器上具有相同的哈希值。

在一个浏览器上过时（有问题）Index.html

2cdd5371d1201f857054a716570c1564（用哈希缓存）包括：

<script src="scripts/a387fbeb.modules.js"></script>

在其内容中。（此文件不再存在于缓存或远程）。

在另一个浏览器上更新（好）index.html

（同缓存2cdd5371d1201f857054a716570c1564）包括：

<script src="scripts/cec2b711.modules.js"></script>

虽然返回给浏览器的内容不同，但这两个缓存是一样的！

我该怎么办？这是否意味着sw-precache当新软件激活时不能保证原子缓存失效？一个人怎么能免受这种伤害？

如果这些有帮助，这是生成的 service-worker.js文件sw-precache。

注意：我意识到我可以使用remoteFirst策略（至少 for index.html）来避免这种情况。但我仍然想了解并找出一种使用cacheFirst策略来充分利用性能的方法。

注意2：我在其他相关问题中看到可以更改缓存的名称以强制破坏所有旧缓存。但这似乎打败了sw-precache只破坏更新内容的想法？这是要走的路吗？

注意3：请注意，即使我硬重新加载网站损坏的浏览器。该站点将工作，因为它会跳过服务工作人员缓存，但缓存仍然是错误的 - 服务工作人员似乎没有激活 - 我的猜测是因为这个特定的 SW 已经被激活但未能正确破坏缓存。随后的非硬刷新访问仍然会看到损坏的index.html.

4

1 回答 1

2

（这里的答案是特定于sw-precache库的。这些细节通常不适用于服务工作者，但有关缓存维护的概念可能仍然适用于更广泛的受众。）

如果 的内容index.html是由服务器动态生成的，并且依赖于内联或通过<script>or<link>标记引用的其他资源，那么您需要通过dynamicUrlToDependencies选项指定这些依赖关系。这是作为库的app-shell-demo一部分提供的示例：

dynamicUrlToDependencies: {
  '/shell': [
    ...glob.sync(`${BUILD_DIR}/rev/js/**/*.js`),
    ...glob.sync(`${BUILD_DIR}/rev/styles/all*.css`),
    `${SRC_DIR}/views/index.handlebars`
  ]
}

(/shell在那里使用而不是/index.html，因为这是用于访问缓存的 App Shell 的 URL。)

此配置告诉sw-precache任何与这些模式匹配的本地文件发生更改时，都应更新动态页面的缓存条目。

如果您index.html不是由服务器动态生成的，而是在构建时使用类似这种方法的方法进行更新，那么确保您的构建过程中运行的步骤sw-precache发生在所有其他修改和替换之后发生是很重要的地方。这意味着使用类似的东西run-sequence来确保服务工作者生成不会与其他任务并行运行。

如果上述信息对您没有帮助，请随时提交包含更多详细信息的错误，包括您网站的 URL。

于 2016-02-24T21:48:10.693 回答