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

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

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

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

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

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