vivo多进程webview开不开启,vivo手机webview更新在哪

首页 > 实用技巧 > 作者:YD1662023-11-23 15:22:03

总结下来是两点:

绑定一个hashchange事件(这里做了防止重复绑定事件的处理),将传入的onShow自定义事件缓存在一个数组中,hashchange触发时,根据特有的标志位__isonshow和__wachangehash确定是否触发。

触发条件:immediately表示最近的一次onShow触发,或者自己指定url通过wx.miniProgram.postMessage发送数据。

浏览器访问资源是通过 URL 地址,如果内嵌 H5 的地址不发生变化,那么 web-view 访问资源会从缓存里取,而缓存里并没有最新的数据,这就导致了服务端的最新资源根本无法到达浏览器,这也解释了为什么修改 Nginx 的 Cache-Control 配置也无法生效的原因。

所以,要想彻底解决及时刷新,必须让 web-view 去访问新的地址。我们假定小程序访问的 URL 地址为:https://www.yourdomain.com/101/#/index ,其中 101 就是构建的一个版本号,每次递增,保证次次不同即可。

四、webview常见难题与解决方案

小程序和h5 之间的通信基本上常用两种方式,一个是postMessage,这个方法大家都知道,只有在三种情况才可以触发,后退、销毁和分享。但也有个问题,就是需要注意这个方法是基础库1.7.1才开始支持的,1.7.1以下就只能通过第二种方法来传递数据,也就是设置和检测webview组件的url变化,类似pc时代的iframe的通信方式。

sdk这块怎么做呢,定义一个share方法,首先需要检测下基础库版本,看是否支持postMessage,如果支持直接调用,如果不支持,把分享参数拼接到url当中,然后进行一次重载。也就是说,通过url传递数据有个缺点,就是页面可能需要刷新一次才能设置成功。

目前在webview环境下支持支持的几种通用业务:

4.1 左上角返回

在访问小程序webview页面时,首先进入的是一个空白的中转页,然后进入h5页面,这样左上角就会出现返回按钮了,当用户按左上角的返回按钮时候,页面会被重载到小程序首页去,这个看似简单又微小的动作,对业务其实有很大的影响。

经过我们的数据统计发现,左上角返回按钮点击率高达70%以上,因为这种落地页一般是被用户分享出来的,以前纯h5的时候只能通过左上角返回,所以在小程序里用户也习惯如此;第二个数字,重载到首页以后,后续页面访问率有10%以上,这两个数字对业务提升其实蛮大的。其实现原理很简单,都是通过第二次触发onShow时进行处理。

4.2 H5和小程序登录态同步问题

分两种情况,接入的H5可能一开始就需要登录,也可能开始不需要登录态中途需要登录,这两种情况我们约定了h5通过自己的url上一个参数进行控制。

vivo多进程webview开不开启,vivo手机webview更新在哪(5)

一开始就需要登录态的情况,具体来讲就是在加载webview之前,首先进行授权登录,然后把登录信息拼接到url里面,再去来加载webview,在h5里面通过adapter来把登录信息提取出来并且存到cookie里,这样h5一进来就是有登录态的。

一开始不需要登录态的情况,一进入小程序就直接通过webview加载h5,h5调用login方法的时候,把needLogin这个参数拼接到url中,然后利用api进行重载,就走了第一种情况进行授权登录了。

Q:可能出现的登录同步问题

A: 跳到个人页登录完成,此时是新开的webview同步两端登录态,点返回,到上一个webview,此时这个webview嵌套的首页,没有触发react-imvc onshow事件。这个页面是老的,退出登录也是一样,所以在首页会去跳h5的登录而不是小程序登录,导致登录不同步。

解决思路:需要返回首页刷一下h5页面。

误区:直接在个人登录之后,relaunch到首页,会导致没有直接调用注销webview把token置换,无法退出。

解决方案:判断从个人页返回的时候,设置webview的url加个参数,重新刷一下。

4.3 Webviwe分享

vivo多进程webview开不开启,vivo手机webview更新在哪(6)

在没接入websocket之前,小程序主要通过bind。首先通过bindmessage事件接收h5传回来的数据,然后在用户分享的时候onShareAppMessage判断有没有回传的数据,如果没有就到webviewurl当中取,否则就是用默认分享数据。

4.4 支付

1)webview页面刷新问题

因为小程序webview里面不支持直接调起微信支付,所以基本上需要支付的时候,都需要来到小程序里面,支付完再回去。上面做好了以后,在h5这块调用一句话就可以了。

针对产品有大量内嵌H5页面的情况下,最好根据业务分两种支付页面,一是有的业务h5有自己完善的交易体系,下单动作在h5里面就可以完成,他们只需要小程序付款,因此我们有一个精简的支付页,进来直接就拉起微信支付。

还有一种情况是业务需要小程序提供完整的下单支付流程,通过直接进入小程序的收银台来,图上是sdk里面的基本逻辑,通过payOnly这个参数来决定进到哪个页面。再看下小程序里面精简支付怎么实现的,onload之后直接调用api拉起微信支付,支付成功以后根据h5传回来的参数,如果是个小程序页面,直接跳转过去,否则就刷新上一个webview页面,然后返回回去。

新的问题与挑战:webview返回上一页数据刷新问题

有客户反馈在A页面点击任务后跳转到B页面,待任务完成后,手机手势左滑返回或点击默认导航栏的左上角返回,上一个页面不会触发任务的更新。原因是上一个页面已经初始化并没有执行重渲染,在APP环境下JSBridge 没有提供侦听手势左滑返回、左上角物理返回的回调事件,且在小程序webview页面也会遇到上述同样的情况。

由于微信并没有提供侦听手势左滑返回、左上角物理返回的,且webview页面也不支持自定义导航栏,这导致下一个页面触发的新事件,在返回上个页面时 无法做到针对性的更新。前期可以简单粗暴地通过约定参数 doRefreshWhileBack=true 作为options,来通过webview页面每次onShow刷新页面,但是刷新整个页面的成本太大,且用户体验不好。

2)引入websocket

带着这些疑问,我们进行一系列的尝试与试验,最终采用了 websocket 的方式,解决并封装出我们市场业务的轻量的websocket服务,主要用于解决webview跨页面通信和游戏方面的业务。

在这个过程中,我们总结出了一些经验,希望能给从事相关研究的同学带来一些帮助。上述做法是针对不同的应用环境,分别使用或约定不同的api派发给各自的事件系统,从而解决页面物理回退时页面不主动刷新的方案。

简要介绍一下websocket,websocket标准诞生于2011年,RFC 文档编号是 6455。TML 5 规范定义了 WebSocket 协议,它可以通过 HTTP 的端口(或者 HTTPS 的端口)来完成,从而最大程度上对 HTTP 协议通透的防火墙保持友好。但是,它是真正的双向、全双工协议,也就是说,客户端和服务端都可以主动发起请求,回复响应,而且两边的传输都互相独立。和上文的 Comet 不同,WebSocket 的服务端推送是完全可以由服务端独立、主动发起的,因此它是服务端的"真 Push"。

WebSocket 是一个可谓"科班出身"的二进制协议,也没有那么大的头部开销,这样就解决了接线员要反复解析HTTP协议,还要查看identity info的信息,因此它的传输效率更高。同时,和 HTTP 不一样的是,它是一个带有状态的协议,双方可以约定好一些状态,而不用在传输的过程中带来带去。而且,WebSocket 相比于 HTTP,它没有同源的限制,服务端的地址可以完全和源页面地址无关,即不会出现的浏览器"跨域问题"。

vivo多进程webview开不开启,vivo手机webview更新在哪(7)

优势:

劣势:

借助websocket的辅助,在小程序webview内嵌H5的业务场景中,可做的事情就更多了。在市场的webview容器加载流程中。

vivo多进程webview开不开启,vivo手机webview更新在哪(8)

上一页123下一页

栏目热文

文档排行

本站推荐

Copyright © 2018 - 2021 www.yd166.com., All Rights Reserved.