webview个人小程序_小程序webview应用实践

作者&＃xff1a;张所勇(转转开放业务部前端负责人)

公众号&＃xff1a;大转转FE

Fundebug经授权转载&＃xff0c;版权归原作者所有。

大家好&＃xff0c;我是转转开放业务部前端负责人张所勇&＃xff0c;今天主要来跟大家分享小程序 webview 方面的问题&＃xff0c;但我并不会讲小程序的 webview 原理&＃xff0c;而我主要想讲的是小程序内如何嵌入 H5。

那么好多同学会想了&＃xff0c;不就是用 web-view 组件就可以嵌入了吗&＃xff0c;是的&＃xff0c;如果咱们的小程序和 H5 的业务比较简单&＃xff0c;那直接用 webview 接入就好了&＃xff0c;但我们公司的 H5 除小程序之外&＃xff0c;还运行在转转 app、58app、赶集 app 等多个端&＃xff0c;如何能实现一套代码在多端运行&＃xff0c;这是我今天主要想分享的&＃xff0c;因此今天分享更适合 H5 页面比较复杂&＃xff0c;存在多端运行情况的开发者&＃xff0c;期待能给大家提供一些多端兼容的思路。

下面我先跟大家介绍下今天演讲主要的提纲。

1 转转小程序演进过程

相信在座的很多同学的产品跟转转小程序经历了类似的发展过程&＃xff0c;我们转转小程序是从去年五月份开始开发的&＃xff0c;那时候也是小程序刚出来不久&＃xff0c;我们就快速用原生语法搭建了个 demo&＃xff0c;功能很简单&＃xff0c;就是首页列表页详情页。

然后我们从7月份开始进入了第二个阶段&＃xff0c;这时候各种中大型公司已经意识到了&＃xff0c;借助微信的庞大用户群&＃xff0c;小程序是一个很好的获客渠道&＃xff0c;因此我们也从 demo 阶段正式的开始了小程序开发。

那时候我们整个团队从北京跑到广州的微信园区里面去封闭开发&＃xff0c;我们一方面在做小程序版本的转转&＃xff0c;实现了交易核心流程&＃xff0c;苦苦的做了两三个月&＃xff0c;DAU 始终也涨不上去&＃xff0c;另一方面我们也在做很多营销活动的尝试&＃xff0c;我们做了一款简单的测试类的小游戏&＃xff0c;居然几天就刷屏了&＃xff0c;上百万的 pv&＃xff0c;一方面我们很欣喜&＃xff0c;另一方面也很尴尬&＃xff0c;因为大家都是来玩的&＃xff0c;不是来交易的&＃xff0c;所以我们就开始了第三阶段。

这个阶段我们进行了大量的开发工作&＃xff0c;让我们的小程序功能和体验接近了转转 APP&＃xff0c;那到了今年6月份&＃xff0c;我们的小程序进入了微信钱包里面&＃xff0c;我们的 DAU 峰值也达到了千万级别&＃xff0c;这时候可以说已经成为了一个风口上的新平台&＃xff0c;这个时候问题来了&＃xff0c;公司的各条线业务都开始想接入到小程序里面。

于是乎就有了上面这段对话。 所以&＃xff0c;为了能够更好接入各业务线存量 h5 页面和新的活动页&＃xff0c;我们开始着手进行多端适配的工作。

那我们会考虑三种开发方案(我这里只说缺点)

在 webview 这个组件出来以前&＃xff0c;我们是采用第一种方案&＃xff0c;用纯小程序开发所有业务页面&＃xff0c;那么适合的框架有现在主流的三种&＃xff0c;wepy&＃xff0c;mpvue、taro&＃xff0c;缺点是不够灵活&＃xff0c;开发成本巨大&＃xff0c;真的很累&＃xff0c;尤其是业务方来找我们想介入小程序&＃xff0c;但他们的开发者又不会小程序&＃xff0c;当时又不能嵌入 H5&＃xff0c;所以业务方都希望我们来开发&＃xff0c;所有业务都来找&＃xff0c;你们可以想想成本又多高&＃xff0c;这个方案肯定是不可行&＃xff0c;第二种方案&＃xff0c;就是一套代码编译出多套页面&＃xff0c;在不同端运行&＃xff0c;mpvue 和 taro 都可以&＃xff0c;我们公司有业务团队在使用 mpvue&＃xff0c;编译出来的结果不是特别理性&＃xff0c;一是性能上面没有达到理想的状态&＃xff0c;二是 api 在多端兼容上面二次改造的成本很高&＃xff0c;各个端 api 差异很大&＃xff0c;如果是一个简单的活动页还好&＃xff0c;但如果是一个跟端有很大功能交互的页面&＃xff0c;那这种方式其实很难实现。

那我们采用的是第三种方案&＃xff0c;目前我们的小程序是作为一个端存在&＃xff0c;像 app 一样&＃xff0c;我们只做首页、列表、详情、购买等等核心页面都是用小程序开发&＃xff0c;每个业务的页面、活动运营页面都是H5&＃xff0c;并且用 webview 嵌入&＃xff0c;这样各个业务接入的成本非常低&＃xff0c;但这也有缺点&＃xff0c;一是小程序与 h5 交互和通信比较麻烦&＃xff0c;二是我们的 app 提供了很大功能支持&＃xff0c;这些功能在小程序里面都需要对应的实现

2 webview VS 小程序

这张图是我个人的理解。(并不代表微信官方的看法) 把 webview 和小程序在多个方面做了比对。

3 h5多端兼容方案

未来除了小程序之外&＃xff0c;可能会多的端存在&＃xff0c;比如智能小程序等等&＃xff0c;那我们期望的结果是什么呢&＃xff0c;就是一套 H5 能运行于各个环境内。

这可能是最差的一个 case&＃xff0c;h5 判断所在的环境&＃xff0c;去调用不同 api 方法&＃xff0c;这个 case 的问题是&＃xff0c;业务逻辑特别复杂&＃xff0c;功能耦合非常严重&＃xff0c;也基本上没有什么复用性。

那我们转转采取的是什么方案呢&＃xff1f;

分三块&＃xff0c;小程序端&＃xff0c;用WePY框架&＃xff0c;H5这块主要是vue和react&＃xff0c;中间通过一个adapter来连接。我们转转的端特别多&＃xff0c;除了小程序还包括纯转转app端&＃xff0c;58端&＃xff0c;赶集端&＃xff0c;纯微信端&＃xff0c;qq端&＃xff0c;浏览器端&＃xff0c;所以H5页面需要的各种功能&＃xff0c;在每个端都需要对应的功能实现&＃xff0c;比如登录、发布、支付、个人中心等等很多功能&＃xff0c;这些功能都需要通过adapter这个中间件进行调用&＃xff0c;接下来详细来讲。

我这里就不贴代码了&＃xff0c;我只讲下adapter的原理&＃xff0c;首先adapter需要初始化&＃xff0c;做两件事情&＃xff0c;一是产出一个供h5调用的native对象&＃xff0c;二是需要检测当前所处的环境&＃xff0c;然后根据环境去异步加载sdk文件&＃xff0c;这里的关键点是我们要做个api调用的队列&＃xff0c;因为sdk加载时异步的过程&＃xff0c;如果期间页面内发生了api调用&＃xff0c;那肯定得不到正确的响应&＃xff0c;因此你要做个调用队列&＃xff0c;当sdk初始化完毕之后再处理这些调用&＃xff0c;其实adapter原理很简单&＃xff0c;如果你想实现多端适配&＃xff0c;那么只需要根据所在的环境去加载不同的sdk就可以了。

做好adapter之后&＃xff0c;你需要让每个h5的项目都引入adapter文件&＃xff0c;并且在调用api的时候&＃xff0c;都统一在native对象下面调用。

4 小程序sdk设计

我们总结小程序提供给H5的功能大体分为这四种&＃xff0c;第一是基于小程序的五种跳转能力&＃xff0c;比如关闭当前页面。

那我们看到小程序提供了这五种跳转方式。

第二是直接使用微信sdk提供的能力&＃xff0c;比如扫码&＃xff0c;这个比较简单。第三是h5打开小程序的某些页面&＃xff0c;这个是最常用的&＃xff0c;比如进入下单页等。

对应每个api&＃xff0c;小程序这边都需要实现对应的页面功能&＃xff0c;大家看这几个图&＃xff0c;skipToChat就是进到我们的IM页面&＃xff0c;下面依次是进入个人主页&＃xff0c;订单详情页&＃xff0c;下单页面&＃xff0c;其实我们的小程序开发的主要工作也是去做这些基础功能页面&＃xff0c;然后提供给H5&＃xff0c;各个业务基本都是H5实现&＃xff0c;接入到小程序里面来&＃xff0c;我们只做一个平台。

这是进入个人主页方法的实现&＃xff0c;其实就是进入了小程序profile这个页面。

第四就是h5与小程序直接的通信能力&＃xff0c;这个比较集中体现在设置分享信息和登录这块。

4.1 设置分享

上面(adapter)做好了以后&＃xff0c;在h5这块调用就一句话就可以了。

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

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

我们看下分享信息设置这块&＃xff0c;小程序这端&＃xff0c;首先通过bindmessage事件接收h5传回来的数据&＃xff0c;然后在用户分享的时候onShareAppMessage判断有没有回传的数据&＃xff0c;如果没有就到webviewurl当中取&＃xff0c;否则就是用默认分享数据。

h5调分享这块&＃xff0c;我们也做了一些优化&＃xff0c;传统方式是要四步才能调起分享面板&＃xff0c;点页面里的某个按钮&＃xff0c;然后给用户个提示层&＃xff0c;用户再去点右上角的点点点&＃xff0c;再点转发&＃xff0c;才能拉起分享面板。

我们后来改成了这样&＃xff0c;点分享按钮&＃xff0c;把分享信息带到一个专门的小程序页面&＃xff0c;这个页面里面放一个button&＃xff0c;type&＃61;share&＃xff0c;点一下就拉起来面板了&＃xff0c;虽然是一个小小的改动&＃xff0c;但能大幅提高分享成功率的&＃xff0c;因为很多用户对右上角的点点点不太敏感。

4.2 登录

接下来我们看看登录功能

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

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

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

5 webview常见问题

5.1 区分环境

第一是你如何区分h5所在的环境是小程序里面的webview还是纯微信浏览器&＃xff0c;为什么要区分呢&＃xff0c;因为你的H5在不同环境需要不同的api&＃xff0c;比如我们的业务&＃xff0c;下单的时候&＃xff0c;如果是小程序&＃xff0c;那么我们需要进入小程序的下单页&＃xff0c;如果是纯微信&＃xff0c;我们直接进纯微信的下单页&＃xff0c;这两种情况的api实现是不一样的&＃xff0c;那么为什么难区分&＃xff0c;大家可能知道&＃xff0c;小程序的组件分为内置组件和原生组件&＃xff0c;内置组件就是小程序定义的view、scroll-view这些基本的标签&＃xff0c;原生组件就是像map啊这种&＃xff0c;这其实是调用了微信的原生能力&＃xff0c;webview也是一种类似原生的组件&＃xff0c;为什么说是类似原生的组件&＃xff0c;微信并没有为小程序专门做一套webview机制&＃xff0c;而是直接用微信本身的浏览器&＃xff0c;所以小程序webview和微信浏览器的内核都是一样的&＃xff0c;包括UA头都是一模一样&＃xff0c;COOKIE、storage本地存储数据都是互通的&＃xff0c;都是一套&＃xff0c;因此我们很难区分具体是在哪个环境。

还好微信提供了一个环境变量&＃xff0c;但这个变量不是很准确&＃xff0c;加载h5以后第一个页面可以及时拿到&＃xff0c;但后续的页面都需要在微信的sdk加载完成以后才能拿到&＃xff0c;因此建议大家在wx.ready或者是weixinjsbridgeready事件里面去判断&＃xff0c;区别就在于前者需要加载jweixin.js才有&＃xff0c;但这里有坑&＃xff0c;坑在于h5的开发者可能并不知道你这个检测过程需要时间&＃xff0c;是一个异步的过程&＃xff0c;他们可能页面一加载就需要调用一些api&＃xff0c;这时候就可能会出错&＃xff0c;因此你一定要提供一个api调用的队列和等待机制。

5.2 支付

第二个常见问题是支付&＃xff0c;因为小程序webview里面不支持直接调起微信支付&＃xff0c;所以基本上需要支付的时候&＃xff0c;都需要来到小程序里面&＃xff0c;支付完再回去。

上面做好了以后&＃xff0c;在h5这块调用就一句话就可以了。

我们转转的业务分两种支付情况&＃xff0c;一是有的业务h5有自己完善的交易体系&＃xff0c;下单动作在h5里面就可以完成&＃xff0c;他们只需要小程序付款&＃xff0c;因此我们有一个精简的支付页&＃xff0c;进来直接就拉起微信支付&＃xff0c;还有一种情况是业务需要小程序提供完整的下单支付流程&＃xff0c;那么久可以直接进入我们小程序的收银台来&＃xff0c;图上就是sdk里面的基本逻辑&＃xff0c;我们通过payOnly这个参数来决定进到哪个页面。

我们再看下小程序里面精简支付怎么实现的&＃xff0c;就是onload之后直接调用api拉起微信支付&＃xff0c;支付成功以后根据h5传回来的参数&＃xff0c;如果是个小程序页面&＃xff0c;那直接跳转过去&＃xff0c;否则就刷新上一个webview页面&＃xff0c;然后返回回去。

5.3 formId收集

第三个问题是formId&＃xff0c;webview里面没有办法收集formId&＃xff0c;这有什么影响呢&＃xff0c;没有formId就没法发服务通知&＃xff0c;没有服务通知&＃xff0c;业务就没办法对新用户进行召回&＃xff0c;这对业务来讲是一个很大的损失&＃xff0c;目前其实我们也没有很好的方案收集。

我们目前主要通过两种方式收集&＃xff0c;访问量比较大的这种webview落地页&＃xff0c;我们会做一版小程序的页面或者做一个小程序的中转页&＃xff0c;只要用户有任何触摸页面的操作&＃xff0c;都可以收集到formId&＃xff0c;另外一种就是h5进入小程序页面时候收集&＃xff0c;比如支付&＃xff0c;IM这些页面&＃xff0c;但并不是每个用户都会进到这些页面的&＃xff0c;用户可能一进来看不感兴趣&＃xff0c;就直接退出了&＃xff0c;因此这种方式存在很大的流失。

5.4 左上角返回

那怎么解决这种流失呢&＃xff0c;我们加了一个左上角返回的功能。

首先进入的是一个空白的中转页&＃xff0c;然后进入h5页面&＃xff0c;这样左上角就会出现返回按钮了&＃xff0c;当用户按左上角的返回按钮时候&＃xff0c;页面会被重载到小程序首页去&＃xff0c;这个看似简单又微小的动作&＃xff0c;对业务其实有很大的影响&＃xff0c;我们看两个数字&＃xff0c;经过我们的数据统计发现&＃xff0c;左上角返回按钮点击率高达70%以上&＃xff0c;因为这种落地页一般是被用户分享出来的&＃xff0c;以前纯h5的时候只能通过左上角返回&＃xff0c;所以在小程序里用户也习惯如此&＃xff0c;第二个数字&＃xff0c;重载到首页以后&＃xff0c;后续页面访问率有10%以上&＃xff0c;这两个数字对业务提升其实蛮大的。

其实现原理很简单&＃xff0c;都是通过第二次触发onShow时进行处理。

以上就是我今天全部演讲的内容&＃xff0c;谢谢大家&＃xff01;

这是我们“大转转FE”的公众号。里面发表了很多FE和小程序方向的原创文章。感兴趣的同学可以关注一下&＃xff0c;如果有问题可以在文章底部留言&＃xff0c;我们共同探讨。

同时也感谢掘金举办了这次大会&＃xff0c;让我有机会同各位同仁进行交流。在未来的前端道路上&＃xff0c;与大家共勉&＃xff01;