作者：Darko

http://segmentfault.com/a/1190000016027966

從微信發(fā)布小程序以來(lái)，各大公司紛紛跟進(jìn)都想從微信這個(gè)流量池里撈一杯羹。我司也不例外，我們整個(gè)前端團(tuán)隊(duì)這半年來(lái)基本上都是在開(kāi)發(fā)小程序。前前后后也開(kāi)發(fā)了四五個(gè)小程序了?？傆X(jué)得要留下點(diǎn)什么，既是記錄那些年我們踩過(guò)的坑，也是希望大家別再掉坑。

那些年我們踩過(guò)的坑

{{}}不能執(zhí)行函數(shù)方法，{{}}只支持基本的簡(jiǎn)單運(yùn)算和ES6拓展運(yùn)算符。如價(jià)格格式化這種常用的處理，只能在js代碼中處理好然后再模板中渲染。

this.setData({

price: this.formatPrice(this.data.price)

})

可以通過(guò)wxs模塊解決{{}}中不能執(zhí)行函數(shù)的問(wèn)題?？梢宰龅侥Mvue.js中過(guò)濾器的功能。

價(jià)格：{{tools.formatPrice(price)}}

// wxs模塊

var formatPrice = function (price){

price = price >> 0;

return Number(price / 100).toFixed(2);

}

module.exports = {

formatPrice

}

小程序不支持分享鏈接到朋友圈，暫時(shí)的通用做法是生成保存有頁(yè)面小程序碼的圖片到本地相冊(cè)。又用戶自行發(fā)朋友圈轉(zhuǎn)發(fā)。前端可以利用canvas來(lái)實(shí)現(xiàn)，減輕服務(wù)端壓力。但是會(huì)有圖片鋸齒不清晰的問(wèn)題。建議預(yù)覽圖和保存到真機(jī)的圖片采用不同的尺寸。保存在真機(jī)的圖片按照750的寬度實(shí)現(xiàn)。相比于預(yù)覽圖要大一些，這樣保存到手機(jī)的圖片會(huì)清晰很多。

小程序布局采用rpx單位，UI稿按照750的寬度出圖?？芍苯邮褂肬I稿的尺寸。但是在某些機(jī)型上1rpx會(huì)無(wú)法顯示?？梢杂肏5的方式實(shí)現(xiàn)1px效果。

iphoneX吸底按鈕的適配，可以用媒體查詢獲取wx.getSystemInfo獲取機(jī)型。

@media only screen

and (device-width : 375px)

and (device-height : 812px)

and (-webkit-device-pixel-ratio : 3) { }

頁(yè)面A -> 頁(yè)面B，頁(yè)面B的操作觸發(fā)了頁(yè)面A的數(shù)據(jù)更新。返回更新頁(yè)面A的數(shù)據(jù)，通常有兩種方式來(lái)實(shí)現(xiàn)(我司采用了方案二)：

在頁(yè)面A監(jiān)聽(tīng)onShow事件，在onShow事件觸發(fā)時(shí)無(wú)腦更新頁(yè)面數(shù)據(jù)。

通過(guò)EventBus來(lái)實(shí)現(xiàn)跨頁(yè)面通信。

復(fù)雜組件的開(kāi)發(fā)，省市區(qū)三級(jí)聯(lián)動(dòng)選擇器的開(kāi)發(fā)，獲取微信地址庫(kù)的地址的編碼和業(yè)務(wù)采用的省市區(qū)編碼對(duì)不上。

頁(yè)面路徑的層級(jí)，最大不能超過(guò)10層。

小程序小程序分包加載，微信對(duì)小程序包的大小有如下限制。

整個(gè)小程序所有分包大小不超過(guò) 8M

單個(gè)分包/主包大小不能超過(guò) 2M

微信小程序主流框架對(duì)比

wepy

mpvue

Taro

wepy

wepy應(yīng)該算是最早發(fā)布的小程序開(kāi)發(fā)框架，提供了類vue.js的語(yǔ)法風(fēng)格和特性，現(xiàn)階段應(yīng)該也是應(yīng)用最廣泛的框架吧。我開(kāi)發(fā)的幾個(gè)小程序也都是采用了wepy這個(gè)框架。我先來(lái)說(shuō)說(shuō)當(dāng)初為什么選擇這個(gè)框架的原因吧。

類Vue.js的語(yǔ)法風(fēng)格，適合我們團(tuán)隊(duì)原有的的技術(shù)棧

支持組件化（當(dāng)時(shí)微信官方的API還不支持組件化）

支持加載外部npm包

支持ES6的寫(xiě)法

前期使用wepy的過(guò)程中，wepy自帶bug。不過(guò)好在開(kāi)發(fā)者響應(yīng)及時(shí)，基本上都能覆蓋大部分場(chǎng)景。

但是有個(gè)最大的坑點(diǎn)就是，wepy組件的實(shí)現(xiàn)方式。組件使用的是靜態(tài)編譯組件，即組件是在編譯階段編譯進(jìn)頁(yè)面的，每個(gè)組件都是唯一的一個(gè)實(shí)例。 多個(gè)組件共享同一個(gè)數(shù)據(jù)。并且靜態(tài)編譯組件。導(dǎo)致組件A，在頁(yè)面A和頁(yè)面B被引用，會(huì)copy兩份代碼到頁(yè)面A和頁(yè)面B內(nèi)部。導(dǎo)致拆分組件并沒(méi)有對(duì)包的體積有任何減少。后期微信官方API支持組件化編程后，我們逐步把一些比較核心，體積較大的組件用原聲API重構(gòu)了。

mpvue

由美團(tuán)團(tuán)隊(duì)開(kāi)發(fā)，mpvue和wepy一樣也是在小程序上提供了類vue.js的開(kāi)發(fā)體驗(yàn)。作為后來(lái)者，搶占了很多wepy的市場(chǎng)份額（ps：我們團(tuán)隊(duì)近期也在考慮從wepy遷移到mpvue）。這個(gè)框架的原理相比wepy要更加復(fù)雜一點(diǎn)，mpvue 修改了 Vue.js 的 runtime 和 compiler 實(shí)現(xiàn)，提供了更加接近于vue.js的開(kāi)發(fā)體驗(yàn)。

Taro

Taro是由京東團(tuán)隊(duì)開(kāi)源的一套遵循 React 語(yǔ)法規(guī)范的多端開(kāi)發(fā)解決方案。本身我對(duì)React和Taro都不是很了解，就不多解釋了。具體可以看開(kāi)發(fā)團(tuán)隊(duì)的博客和代碼了解更多細(xì)節(jié)多端統(tǒng)一開(kāi)發(fā)框架 – Taro

我看小程序

我想從技術(shù)的角度來(lái)談?wù)勎覍?duì)微信小程序的理解，我覺(jué)得小程序本身是一個(gè)非常優(yōu)秀的Hybrid App的技術(shù)方案。有很多值得學(xué)的地方，可以應(yīng)用到我們Hybrid App的技術(shù)方案設(shè)計(jì)中來(lái)。了解和學(xué)習(xí)小程序技術(shù)原理也能更好的優(yōu)化我們的代碼。

渲染層和邏輯層分離

相比于之前常見(jiàn)的Hybrid的方案，小程序使用了雙線程模型：小程序的渲染層和邏輯層是是分開(kāi)的，邏輯層通過(guò)JSCore來(lái)解析和執(zhí)行，渲染層是通過(guò)webview來(lái)渲染。之前的常見(jiàn)Hybrid離線包的方案大多使用webview同時(shí)實(shí)現(xiàn)頁(yè)面的渲染和js的解析。這樣做的的結(jié)果就是隔離了js的runtime，在js代碼中無(wú)法操作webview中的DOM對(duì)象和BOM對(duì)象。Js無(wú)法做任何和頁(yè)面渲染有關(guān)的操作。只能通過(guò)setData把數(shù)據(jù)從JsCore傳遞到webview。

獨(dú)立的JS運(yùn)行環(huán)境，相比于webview同時(shí)處理頁(yè)面的渲染和JS的執(zhí)行帶來(lái)了一些好處：

js無(wú)法動(dòng)態(tài)的在頁(yè)面插入節(jié)點(diǎn)和干預(yù)頁(yè)面的渲染，解決了安全和管控的問(wèn)題，否則小程序的上線審核就變得毫無(wú)意義。

渲染層和邏輯層的分離，減輕了webview的壓力，js的執(zhí)行和頁(yè)面的渲染可以并行，不會(huì)出現(xiàn)js執(zhí)行卡主頁(yè)面渲染的情況。

多個(gè)頁(yè)面可以共享一個(gè)JS運(yùn)行環(huán)境，數(shù)據(jù)很方便的共享，整個(gè)小程序的生命周期共享同一個(gè)上下文，接近App的體驗(yàn)

壞處在于：

多了很多webview和JSCore數(shù)據(jù)傳輸?shù)南?，?shù)據(jù)需要序列化成字符串格式進(jìn)行傳輸。

離線包加載

離線包加載，常見(jiàn)的Hybrid App通過(guò)webview加載H5頁(yè)面，前端頁(yè)面都是放在服務(wù)器端。雖說(shuō)保證了靈活性。但是加載性能收網(wǎng)速影響大。頁(yè)面切換白屏?xí)r間長(zhǎng)。小程序離線包的加載方式。一次性加載所有的前端資源到本地再解壓。大大提升了用戶體驗(yàn)。不過(guò)微信官方為了防止下載離線包的時(shí)間過(guò)程，也嚴(yán)格限制了小程序包的體積。（分包加載情況下子包大小不能超過(guò)2M，也就是初次打開(kāi)加載的資源不能超過(guò)2M）

多webview架構(gòu)

多webview的頁(yè)面架構(gòu)，小程序每新開(kāi)一個(gè)頁(yè)面，都會(huì)用一個(gè)新的webview來(lái)渲染。為了防止webview對(duì)內(nèi)存的消耗。小程序限制層級(jí)不能超過(guò)10層。

預(yù)加載webview

預(yù)加載webview，微信會(huì)預(yù)加載多一個(gè)wkwebview(ios平臺(tái))放后臺(tái)，用戶打開(kāi)小程序時(shí)省去初始化wkwebview時(shí)間。