自微信发布小程序以来，各大公司纷纷跟进，都想从微信这个流量池中捞一杯羹。我们公司也不例外，我们的整个前端团队这半年基本上都是在开发小程序。前后还开发了四五个小程序。总是想留点什么，既是记录那些年我们踩过的坑，又希望大家不要再掉坑了。
我们历年来踏过的坑
css样式无法引用本地图片资源，并且只能引用一个在线资源(background-image)，对本地图片资源的引用只能使用< image>标签。{{}}无法执行函数方法，{{}}仅支持基本简单操作和ES6扩展运算符。像价格格式化这种常用的处理方式，只能在 js代码中处理，然后再模板中呈现。
this.se tDa ta ({
price: this.formatPrice(this.data.price)
})
{{}}中的功能不能通过 wxs模块解决。在 vue. js中模拟筛选器的功能就可以实现。
价格：{{tools.fo rma tPri ce (price)}}
//wxs模块
var formatPrice = function (price){
price = price >> 0;
return Number(price / 100).toFixed(2);
}
module. exports={
formatPrice
}
applet并不支持分享链接到你的朋友圈，一般临时的做法是将网页代码保存在你的本地相册中。也有用户自己发朋友圈转发。通过使用 canvas来实现前端，可以减轻服务端的压力。但也存在图像锯齿不清的问题。推荐预览图片和保存到真机的图片尺寸不同。真机上保存的图片以750宽显示。与预览图相比，要大一些，以便保存在手机上的图片更清晰。小型布局采用 rpx单元， UI稿宽度按750出图。UI稿的尺寸可以直接使用。但将不能在某些型号上显示1 rpx。在H5中可以达到1 px效果。iphoneX吸底按钮的适配，您可以通过媒体查询获得wx.ge tS yst emInfo以获取型号。
@media only screen
and (device-width : 375px)
and (device-height : 812px)
and (-webkit-device-pixel-ratio : 3) { }
页 A->页 B，页面 B的动作触发页面 A的数据更新。以两种方法返回更新页面 A的数据(我司采用方案二)：在页面 A监听onShow事件，在 onShow事件触发时，不会有脑更新页面数据。跨页通信是通过 EventBus实现的。复合部件的开发、省市区三级选择器的开发、获取微信地址的地址编码与业务采用的省、市区号对不上。网页路径的层次结构，不能超过10层。Gapplet分包载入，微信对于小程序包的大小有以下限制。完整的小程序所有的分包大小不超过8 M，单个的转包/主包大小不得超过2 M
微信小程序框架对比
wepympvueTaro
wepy
wepy被认为是最早发布的小程序开发框架，它提供了 vue. js类的语法风格和特性，并且在目前阶段应该被广泛应用。在我开发的一些小程序中，也全部采用 wepy框架。首先，我要说说为什么当初选择了这个框架。
类Vue. js的语法风格，适合我们团队原来的技术栈对组件化的支持(当时微信官方 API还不支持组件化)，支持加载外部 npm包ES6的方式。
在使用 wepy之前， wepy会自己带 bug。幸好开发人员响应及时，基本上可以覆盖大部分场景。
但其中一个最大的缺点是， wepy组件的实现方式。构件使用的是静态编译组件，在编译阶段，组件被编译到页面中，每个组件都是惟一的实例。许多组件共享相同的数据。以及静态编译组件。生成了在页面 A和页面 B引用的组件 A，而在页面 A和页面 B中将代码 copy两份。造成拆分组件并未对软件包的体积进行任何减少。后来微信官方 API支持组件化编程之后，我们逐渐将一些比较核心、体积较大的组件用原始 API重新构建。
mpvue
mpvue和 wepy是由美团团队开发的，它也是为类 vue. js提供开发体验。紧随其后的是 wepy市场份额(ps：最近，我们团队也正在考虑从 wepy转移到 mpvue)。与 wepy相比，该框架的原理更复杂一些， mpvue修改了 Vue. js的 runtime和 compiler实现，提供了更接近 vue. js的开发体验。
Taro
Taro是一个由京东团队开源的基于 React语法规范的多端开发解决方案。自己对雷克特和塔罗都不太了解，就不多说了。特别是查看开发团队的 blog和代码更详细的多端统一开发框架– Taro
查看小程序
希望能从技术的角度谈谈我对微信小程序的理解，我觉得小程序本身就是 Hybrid App的一种技术方案。在我们的 Hybrid App的技术方案设计中，有很多值得学习的地方。理解并学习小程序技术原理也可以更好的优化我们的代码。
渲染层与逻辑层分离
与以前常见的 Hybrid方案相比，小程序使用了双线程模型：小程序的渲染层和逻辑层是分离的，逻辑层通过 JSCore进行解析和执行，而渲染层通过 webview呈现。以前常见的 Hybrid离线包的方案大部分是用 webview来实现页面渲染和 js解析。因此， js的 runtime被隔离，不能在 webview中处理 DOM对象和 BOM对象。Js不能执行与页面渲染相关的任何操作。数据只能通过 setData从 JsCore传递到 webview。
与 webview相比，独立的 JS运行环境对页面的同时呈现和 JS的执行有一些好处：
js不能动态地在页面中插入节点并介入页面的渲染，解决了安全性和控制问题，否则对小程序的上线审核将失去意义。渲染层与逻辑层的分离，减轻了 webview的压力， js的执行和页面渲染可以并行， js执行卡的主页不会呈现 js。一个 JS运行环境可以由多个页面共享，数据很容易共享，整个小程序的生命周期共享同一个上下文，接近于 App的体验。
缺点是：
webview和 JSCore数据传输的大量消耗，数据需要序列化为字符串格式进行传输。
离线包装入
脱线下载， Hybrid App通过 webview载入H5页面，前端页面全部放置在服务器端。当然，还可以灵活变通。但负荷性能对收网速度影响较大。页切换为白屏幕。applet如何加载离线包。一次装入所有前端资源到本地再解压。极大地改善了用户体验。但是微信官方为了防止下载离线包的时间过程，也严格限制了小包的体积。(外接负载情况下外包件大小不能超过2 M，也就是说外接外接的资源不能超过2 M)
多重视图模式
多种 webview的页面结构，而 applet每打开一页，都会呈现一个新的 webview。为避免 webview占用内存。applet限制级别不能超过10层。
预先装入 webview
预先载入 webview，微信会在后台预装多个 wkwebview (ios平台)，当用户打开这个小程序时，就可以省去初始化 wkwebview时间。
相关推荐
上一篇