window.applicationCache 有一个名为 update 的方法。我假设此函数获取html元素中指定的 manifest.appcache 文件，并检查差异。
这一切都很好，但根据我的理解，无论何时加载页面，浏览器都会请求 manifest.appcache 文件并运行相同的“检查差异“程序无论如何。
所以我的问题是（请注意统计数据）：
“如果平均更新发布周期是2周，并且在页面上花费的平均时间是30秒，为什么还有更新功能？”
对我来说这没有意义，我认为我错过了一些东西，因此也是如此。
答案 0 :(得分：4)
众所周知，有些公司（例如：IMVU）每天都会多次推送更新。它通常被称为“持续部署”。 在页面上花费的平均时间在很大程度上取决于应用程序的体系结构。
我认为HTML5 Appcache主要用于缓存“单页面应用程序”的代码，即所有用户交互都发生在单个网页浏览中的应用程序 - 就浏览器而言。 Gmail是单页应用的一个很好的例子。它虽然不使用appcache，但它可以。
用户可能不会将其视为单页视图，因为（实际上）整个可见文档可以被从服务器下载的其他内容替换。用户甚至可以在使用HTML5历史记录API在应用程序内“浏览”时看到他的位置栏更改。
用户可能正在使用单页应用程序（想想gmail）几个小时，如果他没有关闭计算机（或关闭浏览器），甚至可能是几天。
按照设计，要求加载具有appcache-cache的页面的浏览器（这与普通的浏览器缓存不同）将始终从磁盘加载缓存版本，这不一定是最新版本。从缓存加载意味着应用程序启动时没有任何网络延迟。只有在加载应用程序后，浏览器才会检查更新的缓存清单。默认情况下，不会通知用户任何此类更新。他只会在浏览器中重新加载应用后看到更新。
如果用户打开了几个小时的应用，那么肯定会有更新。因此，为了最大化在下次启动应用程序时用户将看到最新版本的机会，应用程序应该间歇性地检查更新。如果appcache清单已更改，则将更新缓存。下次用户启动应用程序时，浏览器将加载用户之前使用该应用程序时加载的最新版本。轮询间隔可以调整到新版本之间的预期间隔。
还可以提醒用户可用的更新。可能有一个不显眼的消息“应用程序更新可用，现在加载？（ok）（解除）”由于所有资源都已预先获取，重新加载几乎是瞬时的（全部来自磁盘）。更难的是确保保留所有用户的数据（和“会话状态”）。