详解小程序中h5页面onShow实现及跨页面通信方案-创新互联

小程序webview的现状

h6页面在小程序中的交互（跳转）场景

• h6跳转小程序native页面（如：调用小程序地址选择能力，然后返回对应的地址信息给h6页面）
• h6跳转己方业务线的h6页面（内部页面交互，方式比较多样）
• h6跳转其它业务线的h6页面（如：交易流程，相关页面可能有其他业务线提供）

主要痛点

在完成相关操作后， 页面状态需要更新 ，目前常见的更新方式有如下两种：

• 第一种：通过url传参（如：url中加入__isonshowrefresh=1，告诉webview再次onshow时候刷新），把需要传递的参数拼接到url中，重新打开url。
• 第二种：需要跳转到新的页面进行数据更新（如：下单页 - 地址选择页 - 新的下单页）

第一种方案，功能上没有问题，但会导致页面刷新，如果页面操作复杂，需要多次刷新

第二种方案，正向操作时体验比方案一好，但导致了另外一个问题：操作 跳转层级过深 ，尤其返回的时候简直让人崩溃。

 小程序中，h6页面打开新页面方式

我们先来看下小程序中常见的h6跳h6的方式：

• 方式1：直接用location.href跳转，返回时候各机型表现不一致，有的会刷页面，重新执行js，有的会直接展示之前的缓存
• 方式2：通过路由hash跳转，返回触发hashchange，页面不刷新，js层面重现渲染
• 方式3：跳转页面打开一个新的webview，相当于每个页面都是一个独立的webview

我们采用的是方式3，理由如下：

1. 打开新页面时的效果更趋近于native间的跳转（当然新打开的页面也会重新加载静态资源，同时这也有另一个问题，一旦你打开10个层级后，再打开新的webview就没反应了，这个是小程序10层限制）
2. 返回的体验也更趋近于native，同时保证页面状态统一（不会出现有的直接展示，有的会重新执行js）
3. webview通过this.src拿到的链接即为当前页面链接，因为如果页面自行通过路由和location.href跳转，页面链接变更后，webview并不会知晓，这种方案，webview通过this.src拿到的链接始终是当前页面的链接。

由于这种方案可能会达到小程序的10层限制。所以在一些重要页面建议加入“ 回到首页 ”的操作，通过这个操作来缩短小程序历史栈

回到首页方案简述

（如果不感兴趣这部分可以直接略过）

wx.miniProgram.reLaunch({
 url: '/pages/webview/bridge?url=项目首页地址'
})