小程式開發實踐總結

從微信釋出小程式以來，各大公司紛紛跟進都想從微信這個流量池裡撈一杯羹。我司也不例外，我們整個前端團隊這半年來基本上都是在開發小程式。前前後後也開發了四五個小程式了。總覺得要留下點什麼，既是記錄那些年我們踩過的坑，也是希望大家別再掉坑。

那些年我們踩過的坑

• css樣式不能引用本地圖片資源，只能引用線上資源(background-image)，引用本地圖片資源只能用<image>標籤。
• {{}}不能執行函式方法，{{}}只支援基本的簡單運算和ES6擴充運算子。如價格格式化這種常用的處理，只能在js程式碼中處理好然後再模板中渲染。
  
  JavaScript

  this.setData({ price: this.formatPrice(this.data.price) })

  1 2 3

  this.setData({ price: this.formatPrice(this.data.price) })

• 可以通過wxs模組解決{{}}中不能執行函式的問題。可以做到模擬vue.js中過濾器的功能。
  
  JavaScript

  <!-- wxml模板 --> <wxs src="../../modules/formatPrice.wxs" module="tools" /> <view>價格：{{tools.formatPrice(price)}}</view> // wxs模組 var formatPrice = function (price){ price = price >> 0; return Number(price / 100).toFixed(2); } module.exports = { formatPrice }

  1 2 3 4 5 6 7 8 9 10 11 12 13

  <!-- wxml模板 --> <wxs src="../../modules/formatPrice.wxs" module="tools" />   <view>價格：{{tools.formatPrice(price)}}</view> // wxs模組 var formatPrice = function (price){     price = price >> 0;     return Number(price / 100).toFixed(2); }   module.exports = {     formatPrice }

• 小程式不支援分享連結到朋友圈，暫時的通用做法是生成儲存有頁面小程式碼的圖片到本地相簿。又使用者自行發朋友圈轉發。前端可以利用canvas來實現，減輕服務端壓力。但是會有圖片鋸齒不清晰的問題。建議預覽圖和儲存到真機的圖片採用不同的尺寸。儲存在真機的圖片按照750的寬度實現。相比於預覽圖要大一些，這樣儲存到手機的圖片會清晰很多。
• 小程式佈局採用rpx單位，UI稿按照750的寬度出圖。可直接使用UI稿的尺寸。但是在某些機型上1rpx會無法顯示。可以用H5的方式實現1px效果。
• iphoneX吸底按鈕的適配，可以用媒體查詢獲取wx.getSystemInfo獲取機型。參考
  
  JavaScript

  @media only screen and (device-width : 375px) and (device-height : 812px) and (-webkit-device-pixel-ratio : 3) { }

  1 2 3 4

  @media only screen     and (device-width : 375px)     and (device-height : 812px)     and (-webkit-device-pixel-ratio : 3) { }

• 頁面A -> 頁面B，頁面B的操作觸發了頁面A的資料更新。返回更新頁面A的資料，通常有兩種方式來實現(我司採用了方案二)：
  1. 在頁面A監聽onShow事件，在onShow事件觸發時無腦更新頁面資料。
  2. 通過EventBus來實現跨頁面通訊。
• 複雜元件的開發，省市區三級聯動選擇器的開發，獲取微信地址庫的地址的編碼和業務採用的省市區編碼對不上。
• 頁面路徑的層級，最大不能超過10層。
• 小程式小程式分包載入，微信對小程式包的大小有如下限制。

• 整個小程式所有分包大小不超過 8M
• 單個分包/主包大小不能超過 2M

微信小程式主流框架對比

• wepy
• mpvue
• Taro

wepy

wepy應該算是最早釋出的小程式開發框架，提供了類vue.js的語法風格和特性，現階段應該也是應用最廣泛的框架吧。我開發的幾個小程式也都是採用了wepy這個框架。我先來說說當初為什麼選擇這個框架的原因吧。

1. 類Vue.js的語法風格，適合我們團隊原有的的技術棧
2. 支援元件化（當時微信官方的API還不支援元件化）
3. 支援載入外部npm包
4. 支援ES6的寫法

前期使用wepy的過程中，wepy自帶bug。不過好在開發者響應及時，基本上都能覆蓋大部分場景。

但是有個最大的坑點就是，wepy元件的實現方式。元件使用的是靜態編譯元件，即元件是在編譯階段編譯進頁面的，每個元件都是唯一的一個例項。 多個元件共享同一個資料。並且靜態編譯元件。導致元件A，在頁面A和頁面B被引用，會copy兩份程式碼到頁面A和頁面B內部。導致拆分元件並沒有對包的體積有任何減少。後期微信官方API支援元件化程式設計後，我們逐步把一些比較核心，體積較大的元件用原聲API重構了。

mpvue

由美團團隊開發，mpvue和wepy一樣也是在小程式上提供了類vue.js的開發體驗。作為後來者，搶佔了很多wepy的市場份額（ps：我們團隊近期也在考慮從wepy遷移到mpvue）。這個框架的原理相比wepy要更加複雜一點，mpvue 修改了 Vue.js 的 runtime 和 compiler 實現，提供了更加接近於vue.js的開發體驗。

Taro

Taro是由京東團隊開源的一套遵循 React 語法規範的多端開發解決方案。本身我對React和Taro都不是很瞭解，就不多解釋了。具體可以看開發團隊的部落格和程式碼瞭解更多細節多端統一開發框架 – Taro

我看小程式

我想從技術的角度來談談我對微信小程式的理解，我覺得小程式本身是一個非常優秀的Hybrid App的技術方案。有很多值得學的地方，可以應用到我們Hybrid App的技術方案設計中來。瞭解和學習小程式技術原理也能更好的優化我們的程式碼。

渲染層和邏輯層分離

相比於之前常見的Hybrid的方案，小程式使用了雙執行緒模型：小程式的渲染層和邏輯層是是分開的，邏輯層通過JSCore來解析和執行，渲染層是通過webview來渲染。之前的常見Hybrid離線包的方案大多使用webview同時實現頁面的渲染和js的解析。這樣做的的結果就是隔離了js的runtime，在js程式碼中無法操作webview中的DOM物件和BOM物件。Js無法做任何和頁面渲染有關的操作。只能通過setData把資料從JsCore傳遞到webview。

獨立的JS執行環境，相比於webview同時處理頁面的渲染和JS的執行帶來了一些好處：

1. js無法動態的在頁面插入節點和干預頁面的渲染，解決了安全和管控的問題，否則小程式的上線稽核就變得毫無意義。
2. 渲染層和邏輯層的分離，減輕了webview的壓力，js的執行和頁面的渲染可以並行，不會出現js執行卡主頁面渲染的情況。
3. 多個頁面可以共享一個JS執行環境，資料很方便的共享，整個小程式的生命週期共享同一個上下文，接近App的體驗。

壞處在於：

1. 多了很多webview和JSCore資料傳輸的消耗，資料需要序列化成字串格式進行傳輸。

離線包載入

離線包載入，常見的Hybrid App通過webview載入H5頁面，前端頁面都是放在伺服器端。雖說保證了靈活性。但是載入效能收網速影響大。頁面切換白屏時間長。小程式離線包的載入方式。一次性載入所有的前端資源到本地再解壓。大大提升了使用者體驗。不過微信官方為了防止下載離線包的時間過程，也嚴格限制了小程式包的體積。（分包載入情況下子包大小不能超過2M，也就是初次開啟載入的資源不能超過2M）

多webview架構

多webview的頁面架構，小程式每新開一個頁面，都會用一個新的webview來渲染。為了防止webview對記憶體的消耗。小程式限制層級不能超過10層。

預載入webview

預載入webview，微信會預載入多一個wkwebview(ios平臺)放後臺，使用者開啟小程式時省去初始化wkwebview時間。