摘要：整個小程序所有分包大小不超過單個分包主包大小不能超過微信小程序主流框架對比應(yīng)該算是最早發(fā)布的小程序開發(fā)框架，提供了類的語法風(fēng)格和特性，現(xiàn)階段應(yīng)該也是應(yīng)用最廣泛的框架吧。不過微信官方為了防止下載離線包的時間過程，也嚴(yán)格限制了小程序包的體積。

那些年我們踩過的坑
css樣式不能引用本地圖片資源，只能引用線上資源(background-image)，引用本地圖片資源只能用標(biāo)簽。
{{}}不能執(zhí)行函數(shù)方法，{{}}只支持基本的簡單運算和ES6拓展運算符。如價格格式化這種常用的處理，只能在js代碼中處理好然后再模板中渲染。
this.setData({ price: this.formatPrice(this.data.price)})
可以通過wxs模塊解決{{}}中不能執(zhí)行函數(shù)的問題?？梢宰龅侥Mvue.js中過濾器的功能。
價格：{{tools.formatPrice(price)}}
// wxs模塊var formatPrice = function (price){ price = price >> 0; return Number(price / 100).toFixed(2);}module.exports = { formatPrice}
小程序不支持分享鏈接到朋友圈，暫時的通用做法是生成保存有頁面小程序嗎的圖片到本地相冊。又用戶自行發(fā)朋友圈轉(zhuǎn)發(fā)。前端可以利用canvas來實現(xiàn)，減輕服務(wù)端壓力。但是會有圖片鋸齒不清晰的問題。建議預(yù)覽圖和保存到真機的圖片采用不同的尺寸。保存在真機的圖片按照750的寬度實現(xiàn)。相比于預(yù)覽圖要大一些，這樣保存到手機的圖片會清晰很多。
小程序布局采用rpx單位，UI稿按照750的寬度出圖?？芍苯邮褂肬I稿的尺寸。但是在某些機型上1rpx會無法顯示。可以用H5的方式實現(xiàn)1px效果。
iphoneX吸底按鈕的適配，可以用媒體查詢獲取wx.getSystemInfo獲取機型。參考
@media only screen and (device-width : 375px) and (device-height : 812px) and (-webkit-device-pixel-ratio : 3) { }
頁面A -> 頁面B，頁面B的操作觸發(fā)了頁面A的數(shù)據(jù)更新。返回更新頁面A的數(shù)據(jù)，通常有兩種方式來實現(xiàn)(我司采用了方案二)：

在頁面A監(jiān)聽onShow事件，在onShow事件觸發(fā)時無腦更新頁面數(shù)據(jù)。
通過EventBus來實現(xiàn)跨頁面通信。
復(fù)雜組件的開發(fā)，省市區(qū)三級聯(lián)動選擇器的開發(fā)，獲取微信地址庫的地址的編碼和業(yè)務(wù)采用的省市區(qū)編碼對不上。
頁面路徑的層級，最大不能超過10層。
小程序小程序分包加載，微信對小程序包的大小有如下限制。

整個小程序所有分包大小不超過 8M
單個分包/主包大小不能超過 2M
微信小程序主流框架對比
wepy
mpvue
Taro
wepywepy應(yīng)該算是最早發(fā)布的小程序開發(fā)框架，提供了類vue.js的語法風(fēng)格和特性，現(xiàn)階段應(yīng)該也是應(yīng)用最廣泛的框架吧。我開發(fā)的幾個小程序也都是采用了wepy這個框架。我先來說說當(dāng)初為什么選擇這個框架的原因吧。
類Vue.js的語法風(fēng)格，適合我們團隊原有的的技術(shù)棧
支持組件化（當(dāng)時微信官方的API還不支持組件化）
支持加載外部npm包
支持ES6的寫法
前期使用wepy的過程中，wepy自帶bug。不過好在開發(fā)者響應(yīng)及時，基本上都能覆蓋大部分場景。
但是有個最大的坑點就是，wepy組件的實現(xiàn)方式。組件使用的是靜態(tài)編譯組件，即組件是在編譯階段編譯進(jìn)頁面的，每個組件都是唯一的一個實例。 多個組件共享同一個數(shù)據(jù)。并且靜態(tài)編譯組件。導(dǎo)致組件A，在頁面A和頁面B被引用，會copy兩份代碼到頁面A和頁面B內(nèi)部。導(dǎo)致拆分組件并沒有對包的體積有任何減少。后期微信官方API支持組件化編程后，我們逐步把一些比較核心，體積較大的組件用原聲API重構(gòu)了。
mpvue由美團團隊開發(fā)，mpvue和wepy一樣也是在小程序上提供了類vue.js的開發(fā)體驗。作為后來者，搶占了很多wepy的市場份額（ps：我們團隊近期也在考慮從wepy遷移到mpvue）。這個框架的原理相比wepy要更加復(fù)雜一點，mpvue 修改了 Vue.js 的 runtime 和 compiler 實現(xiàn)，提供了更加接近于vue.js的開發(fā)體驗。
TaroTaro是由京東團隊開源的一套遵循 React 語法規(guī)范的多端開發(fā)解決方案。本身我對React和Taro都不是很了解，就不多解釋了。具體可以看開發(fā)團隊的博客和代碼了解更多細(xì)節(jié)多端統(tǒng)一開發(fā)框架 - Taro

我看小程序我想從技術(shù)的角度來談?wù)勎覍ξ⑿判〕绦虻睦斫?，我覺得小程序本身是一個非常優(yōu)秀的Hybrid App的技術(shù)方案。有很多值得學(xué)的地方，可以應(yīng)用到我們Hybrid App的技術(shù)方案設(shè)計中來。了解和學(xué)習(xí)小程序技術(shù)原理也能更好的優(yōu)化我們的代碼。
渲染層和邏輯層分離
相比于之前常見的Hybrid的方案，小程序使用了雙線程模型：小程序的渲染層和邏輯層是是分開的，邏輯層通過JSCore來解析和執(zhí)行，渲染層是通過webview來渲染。之前的常見Hybrid離線包的方案大多使用webview同時實現(xiàn)頁面的渲染和js的解析。這樣做的的結(jié)果就是隔離了js的runtime，在js代碼中無法操作webview中的DOM對象和BOM對象。Js無法做任何和頁面渲染有關(guān)的操作。只能通過setData把數(shù)據(jù)從JsCore傳遞到webview。
獨立的JS運行環(huán)境，相比于webview同時處理頁面的渲染和JS的執(zhí)行帶來了一些好處：
js無法動態(tài)的在頁面插入節(jié)點和干預(yù)頁面的渲染，解決了安全和管控的問題，否則小程序的上線審核就變得毫無意義。
渲染層和邏輯層的分離，減輕了webview的壓力，js的執(zhí)行和頁面的渲染可以并行，不會出現(xiàn)js執(zhí)行卡主頁面渲染的情況。
多個頁面可以共享一個JS運行環(huán)境，數(shù)據(jù)很方便的共享，整個小程序的生命周期共享同一個上下文，接近App的體驗。
壞處在于：
多了很多webview和JSCore數(shù)據(jù)傳輸?shù)南模瑪?shù)據(jù)需要序列化成字符串格式進(jìn)行傳輸。
離線包加載離線包加載，常見的Hybrid App通過webview加載H5頁面，前端頁面都是放在服務(wù)器端。雖說保證了靈活性。但是加載性能收網(wǎng)速影響大。頁面切換白屏?xí)r間長。小程序離線包的加載方式。一次性加載所有的前端資源到本地再解壓。大大提升了用戶體驗。不過微信官方為了防止下載離線包的時間過程，也嚴(yán)格限制了小程序包的體積。（分包加載情況下子包大小不能超過2M，也就是初次打開加載的資源不能超過2M）
多webview架構(gòu)多webview的頁面架構(gòu)，小程序每新開一個頁面，都會用一個新的webview來渲染。為了防止webview對內(nèi)存的消耗。小程序限制層級不能超過10層。
預(yù)加載webview預(yù)加載webview，微信會預(yù)加載多一個wkwebview(ios平臺)放后臺，用戶打開小程序時省去初始化wkwebview時間。

更多技術(shù)資訊可關(guān)注：gzitcast