背景
webview是小程序内承载网页的组件，官方开放这样一个能力的本意应该是扩展小程序访问网页信息的功能。但对于某些场景，以小程序为中心的开发并不适用。例如营销活动，针对节日／事件的活动页追求时效且量大，如果都做成小程序，时间和人力成本都很高，再加上支付宝、百度、抖音相继推出各自平台的小程序，适配工作量将成倍增长；另一方面，小程序的发布前需要审核，审核就存在不通过的风险，审核时长也是不可控因素。
也许你会想，这类需求直接用H5（后续用“H5”代表移动端web）来做不就得了？在以往的语境下确实如此，比如图片保存到本地相册这种常用操作，以往通用的做法，都是指引用户“长按图片”。但在小程序已经提供了访问系统相册能力的今天，类似的事情难道不应该被做的更好一些么？
针对上述场景，和改善用户体验的想法，需要思考一种开发模式来把小程序的能力提供给H5。让营销业务逻辑仍然集中于一处（H5），小程序通过webview组件承载H5并通过统一接口，将各项能力提供给H5调用。能力封装和暴露，由各个平台的小程序事先完成并上线。从而可以隔离小程序审核引入的不可控因素，并实现公共功能逻辑的复用，即“以webview为中心的小程序开发模式”
演示
文字描述或许不够直观，可以用浏览器／APP扫码看看这个简单的助力应用demo做参考。
业务逻辑很简单：
- 用户访问的时候，客户端分配一个id标识；
- 可以分享自己的主页，邀请好友来助力；
- 好友助力后，出现在自己主页的“已助力好友”列表中；
- 可以通过列表中的链接，访问好友的主页。
这个演示的基础业务是记录助力关系，并且自带用户系统（保存用户id），是纯粹的web应用，不依赖第三方环境。
但是id毕竟不够直观，普通浏览器内复制地址栏的链接分享操作，也比较繁琐。所以可以判断如果网页在小程序环境中，可利用小程序的获取用户信息和分享能力。结合API成熟度和用户体量，考虑先接入微信小程序。
于是我们在自己的主页中间，新增了“邀请好友助力“按钮，点击后，进入分享页面，可以分享小程序卡片到微信会话或者合成海报分享到朋友圈。
在个人信息右边（个人主页右上角）新增”绑定微信“链接，点击后，进入登陆页，支持微信一键登录和手机号登陆（已授权过个人信息），登陆后回到个人主页用带回的微信资料根据unionId完成账号绑定。
可以发现，两个调用都需要跳转小程序页面后完成。这是由小程序webview通信机制决定的，webview组件虽然可以通过bindmessage让小程序接收来自H5（wx.miniProgram.postMessage）的数据，但是由于只在特殊时机触发，无法满足通信需求，所以考虑用小程序页面跳转（wx.miniProgram.navigateTo）实现传参。
至于小程序向H5传參，可以通过设置src中的hash部分，实现无刷新通信。通信机制并非独创这里不再赘述，具体细节网上有很多参考资料。
webview SDK
把H5对小程序能力的调用和回调过程中通用部分抽出来对外提供统一接口，可以降低学习成本，方便接口变动时统一升级。
小结
通过简单的演示应用，展示了通过小程序webview组件，为H5提供小程序能力的思路。适用于上线频繁、且时效性要求高的场景，如营销活动页开发。这种模式的优点是增强H5应用调用设备的能力和交互形式、提升用户体验的同时，控制小程序开发可能引入的风险。
