网络视图的现状

小程序中h5页面的交互(跳转)场景

h5跳转到小程序的本地页面(例如，调用小程序的地址选择能力，然后将相应的地址信息返回到h5页面)h5跳转到自己业务线的h5页面(内部页面以各种方式交互)h5跳转到其他业务线的H5页面(例如，交易流程，相关页面可能由其他业务线提供)。

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

第一个：通过url传递参数(例如，向url添加_ _ isonshowrefresh=1，并告诉webview在它再次显示时进行刷新)，将要传递的参数拼接到url中，然后重新打开url。第二：需要跳转到新的页面进行数据更新(如排序页面-地址选择页面-新排序页面)。第一种方案在功能上没有问题，但是会导致页面刷新。如果页面操作复杂，需要刷新几次

第二种方案，前向操作体验比第一种方案好，但却引出了另一个问题：操作跳转层次太深，尤其是返回时，让人崩溃。

在小程序中，h5页面会打开一个新页面

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

模式1:直接用location.href跳转，返回时各模型性能不一致，有的会刷页面重新执行js，有的会直接显示之前的缓存模式2:通过routing hash跳转，返回触发hashchange，页面不刷新，js级别重新出现渲染模式3:跳转到page打开新的webview，相当于每个页面都是一个独立的webview。我们采用模式3的原因如下：

打开新页面的效果更接近原生之间的跳转(当然新打开的页面也会重新加载静态资源，还有一个问题。一旦你打开了10级，当你打开一个新的webview时就没有反应了，这就是applet的10级限制)。返回的体验也更接近原生，同时页面状态统一(不会有直接显示。有些会重新执行js)。webview通过this.src获得的链接是当前页面链接，因为如果页面通过路由和位置跳转，那么在页面链接更改后，webview将不会知道。在这个方案中，WebView通过this.src获得的链接始终是当前页面的链接。因为这个方案可能会达到小程序的10层限制。所以建议在一些重要页面上增加“回首页”的操作，通过这个操作来缩短小程序的历史栈

返回主页程序简介

(如果不感兴趣，可以直接跳过这部分。)

wx . miniprogram . Relaunch({ URL : '/page/web view/bridge？Url=项目主页地址' })首先声明我们的webview的路径是/pages/webview/webview

/pages/webview/bridge是一个转移页面，它有以下特点：这个页面不是最终打开h5页面的webview页面，而是一个转移页面。

主要用于退货处理

页面逻辑：如果是第一次展示，跳转到/pages/webview/webview，传递url，正常打开h5。如果不是第一次展示，说明是从webview返回，直接重定向到小程序主页的转移页面：主要保证在放松到一个h5页面后，用户仍然可以点击返回小程序主页。

该方案通常用于具有多个业务线的h5页面嵌入到小程序中的场景。

内容发布场景

我们从主页进入发布页面，并在发布完成后跳转到产品详细信息页面

所以对于一个新用户来说，整个操作过程是这样的：

在首页(点击发布)，进入发布页面(选择已发布商品的分类)，将分类id拼成url，进入新发布页面(选择地址)，进入地址列表页面(如果新用户没有地址，点击添加地址)，进入新地址页面(添加后)，将地址id拼成url。进入另一个新的发布页面(编辑信息后点击发布)，进入发布成功页面(点击查看产品详情)，进入产品详情页面。这个场景是同一个页面，其中不同的内容项需要跳转到不同的页面进行操作，然后返回到原来的页面更新状态。

如果产品详细信息页面上没有“返回主页”条目，则该用户希望返回主页。您需要按“返回”8次==！

经过这次体验，我觉得一般用户没有勇气再发内容了。

当然，还有另一种这样的妥协

正如商品中所提到的，某个标志位被添加到连接中，例如，_ _ isonshowrefresh=1被添加到url中。webview将在打开连接时读取此参数。如果是这样的话，每次都是onShow，重新加载url并通过刷新页面来更新页面状态。

这种体验也是不愉快的，就是复杂的页面会被刷新很多次。

声明

我接下来要讲的计划还不在试验阶段，已经上线了

想看效果的朋友可以在微信小程序中搜索：

“掉头二手交易网”——“0元免费领”——(下)“送闲钱赚星星