前言

三个月前，微信小程序上线了 web-view 组件，引发了一场小高潮。我所在的前端团队写过一篇简析。详情见：微信小程序前端生态浅谈。

我们大胆推测，这一功能可能直接导致小程序数量的增长迎来峰值。

毕竟肯定有很多团队已经准备好开发，但是缺少资源，现在能把现有的H5应用嵌入到小程序web-view容器中，以最低的开发成本享受微信流量红利，何乐而不为呢？

我们也曾设想，或许“小程序页面+Web页面”（甚至更重Web）的混合开发，会成为未来新的趋势。

2M代码限制（现已更新为4M）使得像“转转官方”这样功能复杂的小程序必须考虑引入网页内容，再加上小程序的审核发布机制，无法像网页一样快速迭代。

正好我所在的业务线有现成的H5应用，但是没有对应的小程序，我们在开发对应的小程序时积累了很多经验（也踩过很多坑），分享给有小程序需求的朋友~

最大坑：不支持服务通知

是的，web-view不支持推送服务通知（也称为模板消息）。

如图所示，类似对话列表中订阅号的模式

为什么说它是最大的坑呢？我们先来了解一下服务通知。以下引述均来自微信小程序官方文档。

基于微信的通知渠道，我们为开发者提供能够高效触达用户的模板消息能力，实现服务闭环，提供更优质的体验。

看上去很强大，但是如果我们的小程序没有这个功能会怎么样呢？

“用完就走”是小程序的口号。没有服务通知意味着失去了高效触达（召回）用户的能力，然后用户就再也不会回来了。如何促进激活和留存？很多功能并不像订阅号里看一篇文章，几分钟就能完成。比如大部分电商的行为：从搜索、浏览比价、与卖家沟通，到加入购物车，只完成了不到一半的生命周期；接下来就是下单、支付、评价，还不包括推荐、复购、取消、退款等，15-30分钟根本不够。然而，没有哪个用户会一直开着小程序，其他人会切换出去聊天、刷朋友圈。没有将同步转化为异步的能力，大部分产品逻辑如何实现服务闭环？

一篇教你突破小程序模版消息推送限制的文章，也总结了服务通知“多、快、好、省”等特点，不展开这些，我们也可以看出：

近30天小程序访问来源数据显示，约有20%的用户通过模板消息进入小程序签到，在各类来源中排名第三（如果将新用户来源去掉分母，占比和排名会靠前）；而且用户基本不会关闭微信的消息推送，而相比App推送和短信推送，小程序的推送触达率会高出不少。

所以，没有一个（正经的）小程序不支持服务通知（有些流氓小程序，比如拼多多，你看到一个商品，就能给你推送N条推送通知），试想一个没有推送通知的小程序，你的产品、运营、老板会同意吗？

为什么不支持

但是，为什么web-view不支持服务通知呢？到底是什么问题呢？请继续阅读微信官方文档中的定义。

发布条件：用户与微信系统内的页面交互后触发

总结一下就是3个付款项目，1个表单提交（表单必须声明为发送模板消息），有效期7天。

首先这里区分了支付和表单提交，需要报不同的情况，你看到了吗？然后，web-view 不支持支付能力（其能力不包含微信支付），这个在微信的文档里没有明确说出来，但是在微信的 web-view 问题总结里可以看到，这个也是挺坑的... 其实支付行为对于小程序本身来说只是非常少的交互，绝大多数小程序甚至都不包含支付，所以我们基本都要依赖表单，但是问题就出在这里：小程序的 web-view 和 form（表单组件）不兼容！！！

PS:我们先区分一下表单组件，它和web-view中的网页表单（form标签）没有任何关系。

PS：RN和Weex也是没有form组件的，为什么我看到form就会想到下面这张图呢？

1999 年 12 月发布的 HTML 4.01 已经支持表单了，从 2005 年 AJAX 风靡全球开始，跨域、文件上传等问题也出现了表单以外的解决方案，谁还会用这个东西？

先不抱怨微信文档中表单组件的定义有多简单，再来看看它的web-view组件的定义~

web-view组件是一个可以用来承载网页的容器，会自动填满整个小程序页面。

不仅填满了，试一下把web-view放在表单组件里面，表单组件也是填不满了。所以，自动填充=页面独占=其他元素直接被覆盖了。。。好吧，有人在文档最下方的Bug&Tip里写了一行小字~

综上所述，web-view与服务通知是隔离的。所以，小程序中网页的交互行为，是不算在微信体系里的！！？

我不禁回想起之前推出的PWA（Web App），这里有一点相似之处。

二者都是基于Web技术，开发出伪原生应用，（或许）可以替代APP；PWA的推送通知没法用，因为它的API太过高级，屏蔽了一些未知的服务（你们懂的）；至于小程序的服务通知，你想用web-view当壳发布到线上，也是没办法使用的。

这个有点题外，但大家都说：PWA是引领下一代潮流的Web技术超集，而小程序则是修复（阉割）和打补丁（hack）Web技术的（黑）魔法……

不多说，请继续看：如何客观评价“小程序”的体验？Web 正在不断远离我们

那我该怎么办？

由于我们团队的业务对服务通知和支付依赖很大，那么我们是不是要彻底抛弃 web-view，把以前的 H5 应用全部重写成原生小程序呢？显然不是。

上面提到，支付只是电商众多环节中的一个，主要在商品或者订单详情页（这些是必须重写的）。关于服务通知，通过几个重写的原生小程序页面就可以收集到足够多的表单。

基于wepy，模板部分就是替换+适配，JS比较麻烦，还差得远，你们的美团呢？

其余业务理论上都可以用web-view实现！！！运营活动页就不说了，开放web-view能力最大的好处就是方便了这类需求。小程序首页，甚至配置好的小程序页面都可以用。因为我们还发现了一个神奇的...

大概使用，web-view可以共存

总结

得益于web-view组件的及时推出，我们只需要重写一些详情页以及其依赖的组件，然后一下就可以了。

定位：小程序的web-view就像一个内嵌在客户端的H5页面，当需要一些基础能力的时候，比如支付、服务通知（IM和召回场景）等，最好使用原生的小程序； 兼容性：这个不用太担心，根据最新的基础库统计，1.6.4+的覆盖率已经达到95%以上； 数据通信：小程序=>web-view中可以使用URL、hash方法，web-view=>小程序中可以使用，一般用来解决分享信息传输问题； 登录：a.微信授权在web-view中进行，b.登录小程序后，进入web-view，通过URL将相关信息传递给web-view。

其他（欢迎讨论补充）：

web-view和小程序是两个独立的环境，它们的数据也完全不一样，包括、、等等；但是小程序内嵌的web-view和微信内置浏览器是一套环境，也就是说你在web-view中留下的上述痕迹，在微信内置浏览器打开时也会有；两个环境中，不太容易区分是哪种环境，小程序官方给出的判断方法是. === ''，但是当web-view进入到第二个页面时，这个变量在设备上是没有的。

其他陷阱（常见错误）：

开启的域名没有在小程序管理后台设置为业务域名（注意是业务域名，不是服务器域名）；打开的页面地址也必须设置过业务域名；可以包含页面，但是地址必须是业务域名；打开的页面必须是一个服务；开发者检查自己的服务是否正常，测试方法为：用普通浏览器打开相应地址；等等，具体可以到web-view问题汇总()参考，或者在此帖子留言。