小程序开发实践总结

从微信发布小程序以来，各大公司纷纷跟进都想从微信这个流量池里捞一杯羹。我司也不例外，咱们整个前端团队这半年来基本上都是在开发小程序。前先后后也开发了四五个小程序了。总以为要留下点什么，既是记录那些年咱们踩过的坑，也是但愿你们别再掉坑。

那些年咱们踩过的坑

• css样式不能引用本地图片资源，只能引用线上资源(background-image)，引用本地图片资源只能用<image>标签。

• {{}}不能执行函数方法，{{}}只支持基本的简单运算和ES6拓展运算符。如价格格式化这种经常使用的处理，只能在js代码中处理好而后再模板中渲染。

  this.setData({
   price: this.formatPrice(this.data.price)
  })

• 能够经过wxs模块解决{{}}中不能执行函数的问题。能够作到模拟vue.js中过滤器的功能。

  <!-- wxml模板 -->
  <wxs src="../../modules/formatPrice.wxs" module="tools" />
  
  <view>价格：{{tools.formatPrice(price)}}</view>

  // wxs模块
  var formatPrice = function (price){
      price = price >> 0;
      return Number(price / 100).toFixed(2);
  }
  
  module.exports = {
      formatPrice
  }

• 小程序不支持分享连接到朋友圈，暂时的通用作法是生成保存有页面小程序码的图片到本地相册。又用户自行发朋友圈转发。前端能够利用canvas来实现，减轻服务端压力。可是会有图片锯齿不清晰的问题。建议预览图和保存到真机的图片采用不一样的尺寸。保存在真机的图片按照750的宽度实现。相比于预览图要大一些，这样保存到手机的图片会清晰不少。
• 小程序布局采用rpx单位，UI稿按照750的宽度出图。可直接使用UI稿的尺寸。可是在某些机型上1rpx会没法显示。能够用H5的方式实现1px效果。

• iphoneX吸底按钮的适配，能够用媒体查询获取wx.getSystemInfo获取机型。参考

  @media only screen 
      and (device-width : 375px) 
      and (device-height : 812px) 
      and (-webkit-device-pixel-ratio : 3) { }

• 页面A -> 页面B，页面B的操做触发了页面A的数据更新。返回更新页面A的数据，一般有两种方式来实现(我司采用了方案二)：

  1. 在页面A监听onShow事件，在onShow事件触发时无脑更新页面数据。
  2. 经过EventBus来实现跨页面通讯。
• 复杂组件的开发，省市区三级联动选择器的开发，获取微信地址库的地址的编码和业务采用的省市区编码对不上。
• 页面路径的层级，最大不能超过10层。
• 小程序小程序分包加载，微信对小程序包的大小有以下限制。

• 整个小程序全部分包大小不超过 8M
• 单个分包/主包大小不能超过 2M

微信小程序主流框架对比

• wepy
• mpvue
• Taro

wepy

wepy应该算是最先发布的小程序开发框架，提供了类vue.js的语法风格和特性，现阶段应该也是应用最普遍的框架吧。我开发的几个小程序也都是采用了wepy这个框架。我先来讲说当初为何选择这个框架的缘由吧。

1. 类Vue.js的语法风格，适合咱们团队原有的的技术栈
2. 支持组件化（当时微信官方的API还不支持组件化）
3. 支持加载外部npm包
4. 支持ES6的写法

前期使用wepy的过程当中，wepy自带bug。不过好在开发者响应及时，基本上都能覆盖大部分场景。

可是有个最大的坑点就是，wepy组件的实现方式。组件使用的是静态编译组件，即组件是在编译阶段编译进页面的，每一个组件都是惟一的一个实例。 多个组件共享同一个数据。而且静态编译组件。致使组件A，在页面A和页面B被引用，会copy两份代码到页面A和页面B内部。致使拆分组件并无对包的体积有任何减小。后期微信官方API支持组件化编程后，咱们逐步把一些比较核心，体积较大的组件用原声API重构了。

mpvue

由美团团队开发，mpvue和wepy同样也是在小程序上提供了类vue.js的开发体验。做为后来者，抢占了不少wepy的市场份额（ps：咱们团队近期也在考虑从wepy迁移到mpvue）。这个框架的原理相比wepy要更加复杂一点，mpvue 修改了 Vue.js 的 runtime 和 compiler 实现，提供了更加接近于vue.js的开发体验。

Taro

Taro是由京东团队开源的一套遵循 React 语法规范的多端开发解决方案。自己我对React和Taro都不是很了解，就很少解释了。具体能够看开发团队的博客和代码了解更多细节多端统一开发框架 - Taro

我看小程序

我想从技术的角度来谈谈我对微信小程序的理解，我以为小程序自己是一个很是优秀的Hybrid App的技术方案。有不少值得学的地方，能够应用到咱们Hybrid App的技术方案设计中来。了解和学习小程序技术原理也能更好的优化咱们的代码。

渲染层和逻辑层分离

相比于以前常见的Hybrid的方案，小程序使用了双线程模型：小程序的渲染层和逻辑层是是分开的，逻辑层经过JSCore来解析和执行，渲染层是经过webview来渲染。以前的常见Hybrid离线包的方案大多使用webview同时实现页面的渲染和js的解析。这样作的的结果就是隔离了js的runtime，在js代码中没法操做webview中的DOM对象和BOM对象。Js没法作任何和页面渲染有关的操做。只能经过setData把数据从JsCore传递到webview。

独立的JS运行环境，相比于webview同时处理页面的渲染和JS的执行带来了一些好处：

1. js没法动态的在页面插入节点和干预页面的渲染，解决了安全和管控的问题，不然小程序的上线审核就变得毫无心义。
2. 渲染层和逻辑层的分离，减轻了webview的压力，js的执行和页面的渲染能够并行，不会出现js执行卡主页面渲染的状况。
3. 多个页面能够共享一个JS运行环境，数据很方便的共享，整个小程序的生命周期共享同一个上下文，接近App的体验。

坏处在于：

1. 多了不少webview和JSCore数据传输的消耗，数据须要序列化成字符串格式进行传输。

离线包加载

离线包加载，常见的Hybrid App经过webview加载H5页面，前端页面都是放在服务器端。虽然说保证了灵活性。可是加载性能收网速影响大。页面切换白屏时间长。小程序离线包的加载方式。一次性加载全部的前端资源到本地再解压。大大提高了用户体验。不过微信官方为了防止下载离线包的时间过程，也严格限制了小程序包的体积。（分包加载状况下子包大小不能超过2M，也就是初次打开加载的资源不能超过2M）

多webview架构

多webview的页面架构，小程序每新开一个页面，都会用一个新的webview来渲染。为了防止webview对内存的消耗。小程序限制层级不能超过10层。

预加载webview

预加载webview，微信会预加载多一个wkwebview(ios平台)放后台，用户打开小程序时省去初始化wkwebview时间。