258资源分享网

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

“ 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参数携带数据跨页面；