浅谈微信小程序前端生态

微信小程序去年刚推出内测，就刷屏了笔者朋友圈好几天，而后来几个月单从技术生态来看，并不像人们预期那般火热。不过最近刚推出的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同构的需求逐渐显现，虽然 wepy、 mpVue等框架在尝试从语法层面尽可能做到与 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应用与小程序的同构成本，相信这对小程序开发生态甚至产品生态发展都有积极影响。

——————————————————

长按二维码，关注大转转FE