序言
3个月前，陌陌小程序推出了web-view组件引起了一波小高潮，笔者所在的大后端团队写过一篇探讨，详情可见：。
我们曾大胆推测，这一功能，可能直接造成小程序数目下降迎来一波高峰。
虽然磨刀霍霍却始终资源不足的团队应当不少，如今可以把已有H5应用嵌入到小程序web-view容器中，以最低的开发成本坐蹭陌陌流量红利，何乐而不为呢？
我们也曾畅想似乎“小程序页面+web页”混合开发（甚至web更重）会成为之后的新趋势。
2M代码限制（现在已更新至4M）促使像“转转官方”这样功能繁复的小程序必须考虑引入web内容，再有就是小程序初审发布机制促使它终究不能像web一样迭代迅速。
刚好笔者所在的业务线，存在已有的H5应用却无对应小程序的情况。我们在开发对应小程序时也算收获了不少经验（踩了不少坑），分享给有小程序需求的同事们~
最大的坑：不支持服务通知
是的，web-view不支持推送服务通知（或称模板消息)。
#2:1:6:a:9:e:1:e:4:7:e:c:3:5:9:d:3:9:2:2:0:d:d:e:0:1:0:7:7:f:f:2#
如图所示，类似订阅号在对话列表的模式
为何能称为最大的坑？我们先了解一下服务通知，以下引用全部来自陌陌官方小程序文档。
基于陌陌的通知渠道，我们为开发者提供了可以高效触达用户的模板消息能力，便于实现服务闭环并提供更佳的体验。
看上去很厉害，假如俺们的小程序没这个功能会如何？
“用完即走”是小程序的标语，没有服务通知代表丧失了高效触达（召回）用户的能力，之后用户就再也回不来了，促活和存留如何办？
好多功能不是像订阅号里看篇文章一样，几分钟才能搞定的，例如绝大部份电商的行为：从搜索、浏览比价、跟店家交流，到加入购物车仅仅是走完了不到一半的生命周期；之后才是下单支付评价，还不包括推荐复购取消退货等等，没个15-30分钟那里够。但是，没有用户会仍然开着某个小程序，他人还要切出去聊天刷同学圈呢。没有了化同步为异步的能力，绝大部份产品逻辑怎样实现服务闭环？
一篇推送限制的文章中，也总结了服务通知的「多、快、好、省」等特征。这种先不展开，我们就能看见：
该小程序近30天访问来源数据显示，有20%左右的用户通过模板消息步入小打卡，在各类来源中排行第3位（假如分母除去新用户的来源，百分比和排行会更高）；
毕竟，用户基本都不会关掉陌陌的消息推送，相较App的推送和邮件推送来说，小程序的推送触达率会高好多。
so，没有那个（正经的）小程序会不支持服务通知（流氓些的例如拼多多，看了个商品能给你连着推N条）。试想一下没有推送通知的APP，你的产品、运营和老总们会同意么？
为何不支持
但是，为何web-view不支持服务通知？那里坑了？还请继续看陌陌官方文档里的定义。
下发条件：用户本人在陌陌体系内与页面有交互行为后触发
总结上去就是，支付3条、提交表单（该表单需申明为要发模板消息）1条，7天有效。
首先，这儿区别了支付和递交表单两种行为，要分不同的情况上报，开始了看见没…
之后，web-view不支持支付能力（其JSAPI能力不包含陌陌支付），这个在陌陌的文档里没有显式的申明，不过能在陌陌的web-view问题汇总中听到，这个也挺坑的…
虽然，支付行为对小程序本身而言只是极少数的交互，大多数小程序甚至不含支付。所以我们基本还得靠表单，可问题就出在这：小程序的web-view和表单（form组件）不兼容！！！
PS：我们先分辨下form组件，它跟web-view内网页的表单（form标签）没有任何关系。
PS：RN和Weex也没有form组件。为何笔者一听到form就想到如下的图？
#6:6:c:2:f:6:b:b:1:c:7:6:1:8:f:5:1:c:6:9:1:3:8:2:f:b:2:c:e:d:6:2#
1999年12月发布的HTML4.01Specification就支持了form，自AJAX在2005年轰动世界后，跨域、文件上传都有了form之外的解决方案，谁没事还用这玩意儿？
先不吐槽陌陌文档里form组件的定义是有多狭小，再看其web-view组件的定义~
web-view组件是一个可以拿来承载网页的容器，会手动布满整个小程序页面。
何止布满，尝试把web-view置于form组件内，form组件都铺没了。so，手动布满=页面独占=所有其他元素都被直接覆盖…好吧，他人在文档最下方的Bug&Tip里写了行篆字~
综上，web-view跟服务通知己绝缘。so，小程序里网页的交互行为不算在陌陌体系内！！？
我不禁回想起Google之前推出的PWA（ProgressiveWebApp），在这又有这么一丝形似。
二者同是基于Web的技术，开发出（也许）可取代APP的伪原生应用；
PWA的推送通知因其API太超前和一些不著名的服务被和谐用不了（你懂的）；
小程序的服务通知嘛，你要想用web-view做壳就发布上线也用不了。
扯远了点，但你们都说：PWA是推动下一代时尚的Web技术超集，而小程序是对Web技术进行修（阉割）补（Hack）的（黑）魔法…
不做展开，欢迎移步：
那如何办？
因为笔者团队的业务对服务通知与支付有大量依赖，这么我们就要彻底舍弃web-view，把之前的H5应用全部重画至原生小程序了么？其实不是。
正如前文所说，支付仅是电商众多环节中的一环，主要在商品or订单详情页（这种必须重画）。关于服务通知，通过几个重画后的原生小程序页，也能搜集到足够的form。
#4:2:4:b:5:d:0:2:c:9:0:b:a:1:c:6:5:4:2:8:f:c:5:8:e:b:6:8:5:1:1:a#
基于wepy，模板部份就是个替换+适配的活，JS麻烦些。离同构差别不小，美团您的mpVue呢？
剩下的业务，理论上都可以用web-view来实现！！！营运活动页就不说了，开放web-view能力最大的优势就是便捷了这类需求。小程序首页，甚至配置了tabBar的小程序页都可以。由于我们还发觉一个神奇的feature…
#9:a:a:0:8:b:b:9:a:4:3:b:5:e:1:8:3:9:7:3:6:f:7:5:6:b:2:f:0:0:1:d#
大约是用了原生的UITabBar，web-view和tabBar能共存
总结
亏了web-view组件的及时推出，我们只需重画部份详情页和其依赖的组件，最后复盘一下。
定位：小程序的web-view如同是Hybrid顾客端嵌H5页一样，须要一些基础能力的时侯，例如支付、服务通知（IM和召回等场景）等等，最好使用原生小程序；
兼容性：这个无须过多害怕，最新的基础库统计数据，1.6.4+的覆盖率已达95%以上；
数据通讯：小程序=>web-view可以在url中用search、hash的方法，web-view=>小程序可用bindmessage，通常拿来解决分享信息传递的问题；
登陆：a.web-view内走陌陌授权，b.小程序登入后再步入web-view，并把相关cookie通过url传递给web-view。
其它feature（欢迎讨论和补充）：
web-view跟小程序是独立的两个环境，数据完全不通，包括cookie、session、localStorage等等；
但小程序内嵌web-view跟陌陌外置浏览器是一套环境，也就是说你在web-view上面留下的以上痕迹，到陌陌里外置浏览器打开也有；
在两种环境下，不太容易分辨究竟是哪些环境，小程序官方给的判别方式是window.__wxjs_environment==='miniprogram'，而且在web-view步入第二页时侯，安卓机下这个变量就undefined了。
其它的坑（常见错误）：
打开的域名没有在小程序管理后台设置业务域名(注意是业务域名，不是服务器域名)；
打开的页面302过去的地址也必须设置过业务域名；
页面可以包含iframe，然而iframe的地址必须为业务域名；
