caching - Safari 及其贪婪的缓存

Question

现在这里已经出现了一些问题，所以我想我正在寻找一个解释而不是一个修复(尽管那是王牌)，但是 Safari 的后退/前进缓存非常贪婪。

我有一个问题，表单提交，但在进入表单操作页面之前加载了一个插页式模式窗口。在 Safari 上，缓存是如此强大，以至于后退按钮仍然打开模态，这让我感到非常难过。

我通过关闭模式然后提交表单来绕过它。在后面，浏览器有一个半关闭的模式(它是 Bootstrap，所以它会消失)，然后继续关闭。

现在我知道 onunload=""但刷新页面似乎很疯狂。缓存是一件好事，也是您想要的东西，特别是在手机上。

我想我的问题是:

为什么它比 Chrome 更强烈，并且无论如何强制浏览器缓存一个状态而不是最后一个状态？

谢谢

Answer 1

哈，贪婪是轻描淡写!老实说，99% 的情况下，caching Safari 背后的设计是在移动设备上处理页面转换的理想方式。

当你从页面A到页面B ，然后返回页面 A ，您不希望通过获取资源和 Assets 给设备(带宽、电池生命周期)带来负担，因为您可以在交互之间“暂停”状态，然后在返回时“继续”它。

这正是 Safari Mobile 所做的。他们使用 Page Cache 的概念，当您从一个页面导航到另一个页面时，它会将整个页面保留在内存中。这减少了获取这些资源的需要，并允许在单击返回时进行快速交互。

这很好……但它确实会导致问题(例如您提出的问题)- 具体来说，您如何区分已暂停的页面和应该销毁的页面？

幸运的是，WebKit 提供了一个 pageshow和 pagehide进入 Page Cache 的事件.除了在页面显示或隐藏时触发(类似于 onunload )，它还具有指示页面是否为 persisted 的漂亮功能。 - 或放入页面缓存。

虽然这不是一个完美的解决方案，但您可以查看 pageshow事件持久化，然后更直接地处理模式(因为你知道它被缓存了)就像立即隐藏它一样。

如果您还没有，请在此处查看这两个链接:

https://www.webkit.org/blog/427/webkit-page-cache-i-the-basics/
https://www.webkit.org/blog/516/webkit-page-cache-ii-the-unload-event/

他们很好地解释了页面缓存并包含了 pageshow 的代码示例。和 pagehide我之前提到的事件。

希望这可以帮助!