页首Html代码

[转]H5浏览器和webview后退刷新方案

一、背景

用户点击浏览器工具栏中的后退按钮，或者移动设备上的返回键时，或者JS执行history.go(-1);时，浏览器会在当前窗口“打开”历史纪录中的前一个页面。不同的浏览器在“打开”前一个页面的表现上并不统一，这和浏览器的实现以及页面本身的设置都有关系。

在移动端HTML5浏览器和webview中，“后退到前一个页面”意味着：前一个页面的html/js/css等静态资源的请求（甚至是ajax动态接口请求）根本不会重新发送，直接使用缓存的响应，而不管这些静态资源响应的缓存策略是否被设置了禁用状态。除非请求是JS发送的，且每次发送时，都在url中加入了随机数。（证据可以通过抓包来看，发生后退返回时，没截获到主页面、静态资源和动态接口的请求，但抓到JS发送的pv日志请求，因为pv日志请求的url中加了随机数。）

后退返回到上一个页面的表现，一句话总结就是：html/js/css/接口等资源直接使用前一次请求过的，而JS中的代码从头开始重新执行了一遍。这在一些场景下会导致严重的bug，所以才会提出“后退刷新”的需求。

“后退刷新”的目标是浏览器在后退返回到前一个页面时，能从server端请求到一个全新的的页面内容（即status code 200 ok或status code 304 not modified的页面响应，而不是status 200 from cache根本不向server端请求）进行加载展示并重新执行JS代码。

二、思路和方案

2.1 浏览器历史纪录和HTTP 缓存

PC浏览器实现后退刷新的方法是给响应添加Cache-Control的header，如果server返回页面响应的headers中包含如下内容：

Cache-Control: no-cache,no-store,must-revalidate

Expires: Thu, 01 Jan 1970 00:00:00 GMT

Pragma: no-cache

浏览器在前进后退到该页面时，就会重新发送请求。

代码示例如下：

在jsp模板的header部分加入如下的禁用缓存设置：

  1. <head>
  2. <meta http-equiv="Pragma" content="no-cache">
  3. <meta http-equiv="Cache-control" content="no-cache,no-store,must-revalidate">
  4. <meta http-equiv="Expires" content="0">
  5. <%
  6.   response.setHeader("Cache-Control","no-cache,no-store,must-revalidate");
  7.   response.setHeader("Expires", "0");
  8.   response.setHeader("Pragma","no-cache");
  9. %>
  10.  
  11. </head>

说明一下，其实通过meta标签设置缓存策略，会被浏览器忽略，设置在response header中是比较可靠的。

这样看上去，浏览器历史纪录和HTTP缓存是有关系的。事实上不是这样的，参考You Do Not Understand Browser History， 里面的结论是：

The browser does not respect HTTP caching rules when you click the back button.

2.2 bfcache和page cache

bfcache和page cache是webkit和firefox有一项优化技术。可参考：

  1. Using_Firefox_1.5_caching
  2. WebKit Page Cache I – The Basics 和 WebKit Page Cache II – The unload Event

这里简单介绍一下：

对于支持bfcache/page cache的浏览器，“后退”不光意味着html/js/css/接口等动静态资源不会重新请求，连JS也不会重新执行。因为前一个页面没有被unload，最后离开时的状态和数据被完整地保留在内存中，发生后退时浏览器直接把“离开时”的页面状态展示给用户。

就好像，你在页面A，点击链接要在当前窗口打开页面B，这时浏览器在不卸载页面A的情况下去加载页面B。这时你看到的是页面B，那页面A呢？ 页面A只是被隐藏了，JS暂停执行（我们称之为pagehide）。如果用户点击“返回”，浏览器快速把页面B隐藏，并把页面A再显示出来，JS恢复执行（我们称之为页面B pagehide, 页面A pageshow）。

pageshow事件在页面全新加载并展现时也会触发，与从bfcache/page cache中加载并展示的区分依据是pageshow event的persisted属性。

实际观察中发现，一些移动端浏览器的pageshow event的persisted属性值一直是false，尽管页面看上去确实是从bfcache/page cache中加载展示。（另外一个理论上的point，页面绑定了unload事件时，不再会进入bfcache/page cache，一些移动端浏览器上观察来看实际上也不是这样的）。

可行的方案是：JS监听pagehide/pageshow来阻止页面进入bfcache/page cache，或者监测到页面从bfcache/page cache中加载展现时进行刷新。参考 Forcing mobile Safari to re-evaluate the cached page when user presses back button

代码示例如下：

  1.  
  2. if(Q.ua.IOS){
  3. Q.$(window).on("pagehide",function(){
  4. var $body = $(document.body);
  5. $body.children().remove(); // wait for this callback to finish executing and then...
  6. setTimeout(function() {
  7. $body.append("<script type='text/javascript'>window.location.reload(true);<\/script>");
  8. });
  9. });
  10. }
  11. //for android qq browser
  12. Q.$(window).on('pageshow', function(evt){
  13. setTimeout(function(){
  14. if(evt.persisted){
  15. location.reload(true);
  16. }
  17. });
  18. });
  19.  

3. 安卓webview cache的问题

安卓webview，包括安卓微信里面内嵌的QQ X5内核浏览器，都存在后退不会重新请求页面的问题，无论页面是否禁用缓存。上面的pageshow/pagehide方案也都失效。可行的方法，如下：

1. 给每个需要后退刷新的页面上加一个hidden input，存储页面在服务端的生成时间，作为页面的服务端版本号。

2. 并附加一段JS读取读取页面的版本号，同时也记录在浏览器/webview本地（cookie/localStorage/sessionStorage）进行存储，作为本地版本号。

3. JS检查页面的服务端版本号和本地存储中的版本号，如果服务端版本号大于本地存储中版本号，说明页面是从服务端重新生成的；否则页面就是本地缓存的，即发生了后退行为。

4. JS在监测到后退时，强制页面重新从服务端获取。

该方案的前提是浏览器在向server请求页面时，每次都用jsp重新生成html。需要页面本身有禁用缓存的配置。

方案的代码示例如下：

  1.  
  2. <!-- 安卓webview 后退强制刷新解决方案 START -->
  3. <jsp:useBean id="now" class="java.util.Date" />
  4. <input type="hidden" id="SERVER_TIME" value="${now.getTime()}"/>
  5. <script>
  6. //每次webview重新打开H5首页，就把server time记录本地存储
  7. var SERVER_TIME = document.getElementById("SERVER_TIME");
  8. var REMOTE_VER = SERVER_TIME && SERVER_TIME.value;
  9. if(REMOTE_VER){
  10. var LOCAL_VER = sessionStorage && sessionStorage.PAGEVERSION;
  11. if(LOCAL_VER && parseInt(LOCAL_VER) >= parseInt(REMOTE_VER)){
  12. //说明html是从本地缓存中读取的
  13. location.reload(true);
  14. }else{
  15. //说明html是从server端重新生成的，更新LOCAL_VER
  16. sessionStorage.PAGEVERSION = REMOTE_VER;
  17. }
  18. }
  19. </script>
  20. <!-- 安卓webview 后退强制刷新解决方案 END -->

以上代码应该放在body中，最好是作为body的第一个子元素，这样后退发生时可以第一时间进行后退行为检测，避免用户看到页面呈现，然后页面又重新刷新，中间闪现“空白”。

以上是安卓webview的后退刷新方案，对于安卓微信内嵌浏览器，也适用的。

三、总结

1. PC浏览器，设置禁用页面缓存header即可实现后退刷新
2. 支持bfcache/page cache的移动端浏览器，JS监听pageshow/pagehide，在检测到后退时强制刷新
3. 在前2个方案都不work的情况下，可以在HTML中写入服务端页面生成版本号，与本地存储中的版本号对比判断是否发生了后退并使用缓存中的页面

四、花絮

1. 后退时表单控件用户输入内容

后退时，有些浏览器还会把表单控件中用户输入内容给记录并恢复。可以通过给form或者input添加autocomplete="off"属性解决。如果不work，参考chrome和firefox中autocomplete属性失效的解决方法

1，form中没有input[type=password]，autocomplete="off"将起作用

2，去掉form，设置input[type=text]的autocomplete也起作用

2. 从webview的角度看缓存的问题

关于安卓微信webview缓存的问题，X5内核咨询汇总里面有描述：

8、浏览器缓存静态页面，如果这个静态页面重新生成了之后，还是原来的地址，用户看到的是不是就还是老页面了

 

回答：浏览器对页面这种主资源没有做缓存。只对子资源，图片，JS，CSS等做了缓存，而且缓存都是有一个新旧对比的，这个主要是服务器来控制哪些可以缓存哪些不能缓存。会有304 这种判断。

从webview层面来看待缓存问题：

2、缓存模式(5种)

LOAD_CACHE_ONLY: 不使用网络，只读取本地缓存数据

LOAD_DEFAULT: 根据cache-control决定是否从网络上取数据。

LOAD_CACHE_NORMAL: API level 17中已经废弃, 从API level 11开始作用同LOAD_DEFAULT模式

LOAD_NO_CACHE: 不使用缓存，只从网络获取数据.

LOAD_CACHE_ELSE_NETWORK，只要本地有，无论是否过期，或者no-cache，都使用缓存中的数据。

如：www.taobao.com的cache-control为no-cache，在模式LOAD_DEFAULT下，无论如何都会从网络上取数据，如果没有网络，就会出现错误页面；在LOAD_CACHE_ELSE_NETWORK模式下，无论是否有网络，只要本地有缓存，都使用缓存。本地没有缓存时才从网络上获取。

www.360.com.cn的cache-control为max-age=60，在两种模式下都使用本地缓存数据。

总结：根据以上两种模式，建议缓存策略为，判断是否有网络，有的话，使用LOAD_DEFAULT，无网络时，使用LOAD_CACHE_ELSE_NETWORK。

看上去修改webview的配置就能轻松愉快地解决问题的。只是迫于app版本发布缓慢的现实，才从JS和网页的层面来解决这个问题。

 

 

 

原文链接：http://hzxiaosheng.bitbucket.org/work/2015/09/23/refresh-webpage-on-history-back-for-mobile-browser-and-webview.html

posted @   沧海月明FE  阅读(36716)  评论(2)  编辑  收藏  举报
编辑推荐：
· go语言实现终端里的倒计时
· 如何编写易于单元测试的代码
· 10年+ .NET Coder 心语，封装的思维：从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热？
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
阅读排行：
· 周边上新：园子的第一款马克杯温暖上架
· Open-Sora 2.0 重磅开源！
· 分享 3 个 .NET 开源的文件压缩处理库，助力快速实现文件压缩解压功能！
· Ollama——大语言模型本地部署的极速利器
· DeepSeek如何颠覆传统软件测试？测试工程师会被淘汰吗？
点击右上角即可分享
微信分享提示
AI IDE Trae