微信小程序去年刚推出内测,就刷屏了笔者朋友圈好几天,而后来几个月单从技术生态来看,并不像人们预期那般火热。不过最近刚推出的web-view组件,算是再次引发了一波小高潮。

web-view组件中运行纯web应用

web-view 是一个可以用来承载网页的容器,会自动铺满整个小程序页面”,也就是说,微信小程序中可以直接运行web页了。大胆猜想,这一功能,可能直接导致小程序数量增长迎来一波高峰。毕竟磨刀霍霍却一直资源不足的团队应该不少,现在可以把已有H5应用嵌入到小程序webview容器中,以最低的开发成本坐蹭微信流量红利,何乐而不为呢?

对于 web-view 组件,笔者做了些demo测试:

  • 所测试的线上M页功能未见异常,dom,bom操作API未被屏蔽;

  • 顶部栏显示M页title,且优先级高于小程序页面title;

  • 小程序页面跳转轨迹和 web-view 中web页跳转轨迹会被连贯记录,包括hashchange;

  • M页间跳转层级不受限,不同于小程序页面最多5层的限制;

  • 经测试内嵌M页调起转转APP正常;

  • web-view 组件 src 属性支持动态赋值;

从以上结果来看,仅以小程序 web-view 组件为容器,迁移已有web应用到小程序中的方案应该可行,包括基于hash路由的SPA。

还有一点值得注意,随着 web-view 组件推出, Page.onShareAppMessage(options) 函数参数中新增了 webViewUrl 属性值,当用户调起转发面板时, options.webViewUrl 返回 web-view 组件中当前加载的 url ,通过把 url 添加到小程序页面分享路径中,可以变相实现转发M页到好友会话的功能。

以往的小程序开发体验

过去几个月笔者一直在参与小程序项目,从个人观点来说,之前小程序的开发体验还有很大提升空间。

  • 首先小程序推出时间不长,稳定性还不是特别理想;

  • 其次小程序与web同构的需求逐渐显现,虽然 wepympVue 等框架在尝试从语法层面尽可能做到与 vue 技术栈的web项目同构,但是两端特性API兼容依旧是个棘手问题;好在现在 web-view 组件的推出,一下使得同构问题不那么严峻了;

  • 最重要一点是之前小程序组件化机制不完善,代码复用相对困难。而对于我们团队并行开发多个小程序且功能复用频繁的情况,高效的代码复用方案又极为重要;

针对代码复用问题,我们选用了 wepy框架 解决。 wepy 提供了系统的组件化开发方案,类似Vue语法,支持npm引用,能够方便的引入ES6语法,CSS预处理器,打包过程支持插件化扩展。整体来说,wepy极大地提高了小程序组件化开发体验,但是在具体组件开发中,我们也遇到了一些问题。由于小程序不支持动态模板,且小程序的视图更新只能基于 page data 中挂载的数据,这些与web开发不同的地方必然会对框架设计有所限制,在实际开发中,对 slot 模板片段,嵌套组件间 computed 数据同步等复杂组件应用上体验还是有些缺陷。

好在从基础库SDK v1.6.3 开始,小程序新增了 Component构造器 ,开始原生支持自定义组件开发。正当笔者还在想 wepy 等以往的组件化框架是不是会逐渐过渡到基于 Component构造器 时,发现蘑菇街团队已经高效的开源了基于 Component 的组件化方案 Min ,Min采用单文件的方式来开发组件, 在单文件编译环节提供了CSS预处理器等一些额外的赋能,同时也支持插件扩展。很期待新版基础库覆盖率足够高后,能够尝试 Component构造器 的组件化方案,相信开发体验一定会大有提升。

未来的混合开发需求

小程序隔离了JSCore和webview渲染内核,通过中间层数据传输接口异步的将数据从JS逻辑层发送到视图层;这使得微信可以更好的对小程序数据传递和响应时间等做监控,但在渲染性能和开发体验方面并未明显优于web开发。同时,2M代码限制也使得像“转转官方”这样已经2000+KB的小程序必须考虑引入web内容,再有就是小程序审核发布机制使得它终究不能像web一样迭代迅速。综上,也许“小程序页面+web页”混合开发(甚至web更重)会成为以后的新趋势。

考虑混合开发,必然会遇到“web-view网页与小程序页面通信”的场景,而现在两者之间不支持除JSSDK提供的接口之外的通信。

  • 从web页新开一个小程序页面: 可使用 wx.miniProgram.navigateTo 等几个跳转接口,通过path参数携带数据跨页面;

  • 从小程序页面新开一个web页:可以把携带数据的url动态赋值给 <web-view/>.src 属性实现数据传递。这里有一点要说明, <web-view/>.src 属性是一个单向传递的数据, web-view 内的url变更并不能反馈到src属性值中;

而对于回退到上一页面需要携带数据的场景,目前能想到的通信方式只有通过服务端中转,在回退到的页面 onShow 钩子中拉新数据;因为 navigateBack 或者 wx.miniProgram.navigateBack 等方法并没有能够携带跨页面数据的参数。在之前的小程序页面开发中,两个小程序页面的返回场景下我们可以在 A页面 中把数据存入 storage或者js模块 ,返回 B页面 后在 onShow 中获取数据。而混合模式下 web-view 组件环境中 localstorage 和小程序 storage 并不共用存储空间, web-view 中JS执行引擎和小程序页面的JSCore环境也不能共享JS模块。

期待

展望未来的小程序功能升级,笔者最期待的大概有两点:

  • 小程序页面和 web-view 页面间的通信能有比较系统高效的接口支持;

  • 支持打包部分web静态资源到小程序包中,并可在 web-view 内嵌网页中本地加载。

总结来说,在笔者看来,最希望小程序的功能迭代能够往“提供更高效、微信开放功能更强大的定制化webview容器”方向发展。尽可能减小web应用与小程序的同构成本,相信这对小程序开发生态甚至产品生态发展都有积极影响。