小程序开发实践总结

1、css样式不能引用本地资源,只能引用线上资源(background-image),引用本地资源只能用image标签。

2、{{}}不能执行函数方法，{{}}只支持基本的简单运算和ES6扩展运算符（...）。如价格格式化这种常用的处理,只能在js代码中处理好后再模板中渲染。例：this.setData({price:this.formatPrice(this.data.price)}).

3、可以通过wxs模板解决{{}}中不能执行函数的问题。可以做到模拟vue.js中过滤器的功能。

图1

4、小程序不支持分享链接到朋友圈，暂时的通用做法是生成保存有页面小程序码的图片到本地相册。又用户自行发朋友圈转发。前端可以利用canvas来实现，减轻服务端压力。但是会有图片锯齿不清晰的问题。建议预览图和保存到真机的图片采用不同的尺寸。保存在真机的图片按照750的宽度实现。相比于预览图要大一些，这样保存到手机的图片会清晰很多。

5、小程序布局采用rpx单位，UI稿按照750的宽度出图。可直接使用UI稿的尺寸。但是在某些机型上1rpx会无法显示。可以用H5的方式实现1px效果。

6、iphoneX吸底按钮的适配，可以用媒体查询获取wx.getSystemInfo获取机型。

图2

7、页面A -> 页面B，页面B的操作触发了页面A的数据更新。返回更新页面A的数据，通常有两种方式来实现(我司采用了方案二)：@1、在页面A监听onShow事件，在onShow事件触发时无脑更新页面数据。@2、通过EventBus来实现跨页面通信。

8、复杂组件的开发，省市区三级联动选择器的开发，获取微信地址库的地址的编码和业务采用的省市区编码对不上。

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

10、独立的JS运行环境，相比于webview同时处理页面的渲染和JS的执行带来了一些好处：@1、js无法动态的在页面插入节点和干预页面的渲染，解决了安全和管控的问题，否则小程序的上线审核就变得毫无意义。@2、渲染层和逻辑层的分离，减轻了webview的压力，js的执行和页面的渲染可以并行，不会出现js执行卡主页面渲染的情况。@3、多个页面可以共享一个JS运行环境，数据很方便的共享，整个小程序的生命周期共享同一个上下文，接近App的体验。坏处在于：多了很多webview和JSCore数据传输的消耗，数据需要序列化成字符串格式进行传输。

作者：Darko 

segmentfault.com/a/1190000016027966