HTML5 离线应用程序是否需要 swapCache()？
如果我不实现任何 updateready 事件处理程序并且不调用 swapCache()，这是否意味着浏览器将始终使用第一个（最旧的）下载版本应用程序？
如果不是，那么为什么需要 swapCache() 方法？
If I don't implement any updateready event handler and don't call swapCache(), does that mean that the browser will always use the first (oldest) downloaded version of the application?
If no, then why is the swapCache() method needed?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
Swapcache 确保对缓存资源的“后续”调用是从新缓存中获取的。
swapcache之后的后续含义。
要查看实际效果，请尝试在
updateready 事件中的 swapcache 调用（以便浏览器在特定的位置加载它）
时间）。确保该图像尚未加载到页面的其他位置，因为这会
扭曲这个测试。
现在更改图像并更改清单文件（以强制重新加载缓存的文件）。
在浏览器中重新加载页面。
您现在应该在渲染的页面中看到图像的新版本。
现在注释掉对 swapcache 的调用。
更改清单文件并重新加载页面以及所有资源。
再次刷新页面（以确保您拥有新缓存中的版本）。
现在再次更改图像并更改清单。
再次重新加载页面：现在您可以看到旧版本的图像。
在最后一种情况下，浏览器完成了在缓存中加载新版本，但是自从
swapcache 没有被调用，图像仍然从旧的缓存中获取。
如果您不在页面中进行任何资源的动态加载，则交换缓存不起作用。
特别是，如果您在 updateready 事件处理程序中调用 swapcache 重新加载页面
首先没有任何效果，因为重新加载页面无论如何都会从新的缓存中获取它。
Swapcache makes sure that "subsequent" calls to cached resources are taken from the new cache.
Subsequent meaning after swapcache.
To see this in action try setting the src property of an img dynamically after the
swapcache call in the updateready event (so that the browser loads it at that particular
time). Make sure this image is not already loaded elsewhere in the page since that will
distort this test.
Now change the image and change the manifest files (to force reloading the cached files).
Reload the page in your browser.
You should now see the new version of the image in your rendered page.
Now comment out the call to swapcache.
Make a change to the manifest file and reload the page and thus all resources.
Refresh the page again (to make sure you have a version from the new cache).
Now change the image again and change the manifest.
Again reload the page: now you see the old version of the image.
In the last case, the browser finished loading the new versions in cache, but since
swapcache was not called, the image was still taken from the old cache.
If you do not do any dynamic loading of resources in your page, the swapcache has no effect.
In particular, if you reload the page in the updateready event handler calling swapcache
first has no effect since reloading the page will get it from the new cache anyway.
我有一个具有相当大缓存（> 100mb）的应用程序。这需要特别长的时间来交换缓存（并且在发生这种情况时几乎锁定浏览器）。因此，我显示一条消息，指示应用程序正在更新（请稍候...），然后调用
swapCache()，然后在更新完成后显示一条新消息，指示完成。不确定这是否回答了您的问题（至于为什么需要），但我认为它至少为
swapCache()提供了一个有效的用例。I have an app with a pretty large cache (>100mb). This takes a particularly long time to swap the cache in (and pretty much locks the browser while this is happening). So I display a message indicating that the app is updating (please wait...), then call
swapCache(), then display a new message when it's done indicating completion.Not sure if this answers your question (as to why it's necessarily needed), but I think it provides a valid use case for
swapCache()at least.让我们想象两种不同的场景。
当新内容可用时，您调用
location.reload()。该页面将使用其全新内容重新加载。在这种情况下，不需要applicationCache.swapCache()。您的用户继续与您的页面交互，无需重新加载。这种交互会导致资产动态加载。为了便于讨论，我们假设它是一个翻转图像，并且假设您刚刚更新了该翻转图像。如果没有
applicationCache.swapCache()，您的用户将继续看到旧的翻转图像。在applicationCache.swapCache()之后，他/她将看到新的翻转图像。因此
applicationCache.swapCache()无需重新加载 表示：“保持页面加载时的样子，但现在使用任何新资源，只要页面要求他们”。Let's imagine 2 different scenarios.
You call
location.reload()when the new content is available. The page will reload using its all-new content.applicationCache.swapCache()is not needed in this case.Your user continues to interact with your page, without any reload. This interaction causes an asset to load dynamically. For the sake of argument, let's imagine that it's a rollover image, and let's imagine that you have just updated this rollover image. Without
applicationCache.swapCache(), your user will continue to see the old rollover image. AfterapplicationCache.swapCache(), s/he will see the new rollover image.So
applicationCache.swapCache()without a reload says: "Keep the page looking the way it was when it was loaded, but use any new assets now, as soon as the page asks for them".SwapCache 方法为应用程序提供了一种控制如何应用更新的机制。在常规 HTML 应用程序中，很难确定客户端浏览器上是否存在正确的 JS。
此外，浏览器的实现方式也因缓存更新时间而异，我发现 iPhone 特别顽固。 swapCache 让我重新掌控应用程序的更新方式，即我可以选择自动应用补丁或让用户选择何时应用等。
The SwapCache method provides a mechanism for the application to be in control of how an when updates are applied. In regular HTML apps, it can be difficult to determine if the correct JS is present on the clients browser.
Also browser implementations vary on when a cache would be updated, I found the iPhone particularly stubborn. swapCache put me back in control of how my app is updated i.e. I could choose to automatically apply the patch or let the user choose when to apply etc.
我也想知道同样的事情。我似乎只需调用“window.applicationCache.update()”即可触发成功的更新。如果清单文件已被修改，则会触发“下载”事件，然后最终触发“更新就绪”。
当我重新加载它时，它似乎已被应用。我似乎不需要调用swapCache()。我已经准备好从应用程序调用它，但到目前为止还没有注意到对更新过程有任何影响。
调用 update() 基本上消除了一次重新加载，AFAICS。
I was wondering the same thing. I seem to be able to trigger a successful update by just calling "window.applicationCache.update()". If the manifest file has been modified, the 'download' event is triggered, then eventually the "update ready".
When I reload it, it appears to have been applied. I don't seem to need to call swapCache(). I have provision for calling it from the app, but so far have not noticed any effect on the update process.
Calling update() basically eliminates one reload, AFAICS.
swapCache将从缓存清单中列出的上一组资源（加载正在运行的 web 应用程序时）切换到新组。毕竟，您这样做是为了响应updateready，这表明新的清单已加载。不要将这与加载单个资源相混淆，通常的浏览器缓存策略仍然适用。换句话说，您将交换一组资源，但各个资源需要自己的缓存管理，以确保在您需要时重新加载它们。
我还没有尝试过这个，但它似乎建议将代码构造为处理更新过程的“更新控制器”javascript 文件，以及具有已知入口点的版本化文件名（或 URL）的 javascript 源。
swapCachewill switch from the previous set of resources listed in the cache manifest (when the running webapp was loaded) to the new set. You are doing this in response to anupdatereadyafter all, which signals that a new manifest has been loaded.This is not to be confused with loading individual resources, for which the usual browser caching policies still apply. In other words you will swap set of resources, but individual resources need their own cache management to ensure they're reloaded when you need them to.
I haven't tried this yet, but it would seem to suggest structuring the code as an "update controller" javascript file that handles the update process, and javascript sources with a versioned filename (or URL) with known entry points.