小程序開發(fā)實踐總結(jié)
從微信發(fā)布小程序以來，各大公司紛紛跟進都想從微信這個流量池里撈一杯羹。我司也不例外，我們整個前端團隊這半年來基本上都是在開發(fā)小程序。前前后后也開發(fā)了四五個小程序了。總覺得要留下點什么，既是記錄那些年我們踩過的坑，也是希望大家別再掉坑。
那些年我們踩過的坑
{{}}不能執(zhí)行函數(shù)方法，{{}}只支持基本的簡單運算和ES6拓展運算符。如價格格式化這種常用的處理，只能在js代碼中處理好然后再模板中渲染。
this.setData({price:this.formatPrice(this.data.price)})復(fù)制代碼
可以通過wxs模塊解決{{}}中不能執(zhí)行函數(shù)的問題。可以做到模擬vue.js中過濾器的功能。
價格：{{tools.formatPrice(price)}}復(fù)制代碼
// wxs模塊varformatPrice =function(price){? ? price = price >>0;returnNumber(price /100).toFixed(2);}module.exports = {? ? formatPrice}復(fù)制代碼
小程序不支持分享鏈接到朋友圈，暫時的通用做法是生成保存有頁面小程序嗎的圖片到本地相冊。又用戶自行發(fā)朋友圈轉(zhuǎn)發(fā)。前端可以利用canvas來實現(xiàn)，減輕服務(wù)端壓力。但是會有圖片鋸齒不清晰的問題。建議預(yù)覽圖和保存到真機的圖片采用不同的尺寸。保存在真機的圖片按照750的寬度實現(xiàn)。相比于預(yù)覽圖要大一些，這樣保存到手機的圖片會清晰很多。
小程序布局采用rpx單位，UI稿按照750的寬度出圖。可直接使用UI稿的尺寸。但是在某些機型上1rpx會無法顯示。可以用H5的方式實現(xiàn)1px效果。
iphoneX吸底按鈕的適配，可以用媒體查詢，也可以通過wx.getSystemInfo獲取機型來判斷。參考
@mediaonly screen? ? and (device-width :375px)? ? and (device-height :812px)? ? and (-webkit-device-pixel-ratio :3) { }復(fù)制代碼
頁面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
wepy
wepy應(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)編譯組件，即組件是在編譯階段編譯進頁面的，每個組件都是唯一的一個實例。?多個組件共享同一個數(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ā)體驗。
Taro
Taro是由京東團隊開源的一套遵循 React 語法規(guī)范的多端開發(fā)解決方案。本身我對React和Taro都不是很了解，就不多解釋了。具體可以看開發(fā)團隊的博客和代碼了解更多細節(jié)多端統(tǒng)一開發(fā)框架 - Taro
我看小程序
我想從技術(shù)的角度來談?wù)勎覍ξ⑿判〕绦虻睦斫猓矣X得小程序本身是一個非常優(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ù)需要序列化成字符串格式進行傳輸。
離線包加載
離線包加載，常見的Hybrid App通過webview加載H5頁面，前端頁面都是放在服務(wù)器端。雖說保證了靈活性。但是加載性能收網(wǎng)速影響大。頁面切換白屏?xí)r間長。小程序離線包的加載方式。一次性加載所有的前端資源到本地再解壓。大大提升了用戶體驗。不過微信官方為了防止下載離線包的時間過程，也嚴格限制了小程序包的體積。（分包加載情況下子包大小不能超過2M，也就是初次打開加載的資源不能超過2M）
多webview架構(gòu)
多webview的頁面架構(gòu)，小程序每新開一個頁面，都會用一個新的webview來渲染。為了防止webview對內(nèi)存的消耗。小程序限制層級不能超過10層。
預(yù)加載webview
預(yù)加載webview，微信會預(yù)加載多一個wkwebview(ios平臺)放后臺，用戶打開小程序時省去初始化wkwebview時間。
