2017年1月9日，微信官方在2017微信公開課Pro上釋出的小程式正式上線，開創了小程式開發的時代。我們的美團外賣的業務也逐步加入到小程式開發的隊伍中。小程式有著無需安裝、觸手可及、用完即走、無須解除安裝的特點，屬於“輕”量級的應用。
但是這樣的“輕”量級應用卻承載我們非常複雜的外賣業務，對於我們外賣團隊來說，也面臨著很多新的機遇和挑戰。本文將詳細介紹我們外賣小程式的解決方案與經驗，希望能夠對大家有所啟發。本次分享主要由以下四個部分展開：
第一部分：技術架構
小程式釋出時，其定位主要是功能比較簡單的輕應用，所以原生框架設計相對比較簡單，而對於業務相對複雜的中大型網際網路企業，小程式產品支援還不夠完善，專案較難進行管理和維護。
業務場景
針對業務場景的多樣性，我們採用了較開放的框架策略：專案既支援原生框架開發，又支援自由引入第三方框架，以滿足各業務場景的需求。
-
原生框架開發：對主流程等相對獨立且穩定性要求高的業務採用了原生框架進行開發。
- 一方面，我們考慮小程式原生框架不夠完善，隨著基礎版本庫的升級，存在需要處理的相容性問題，避免引入第三方框架增加除錯難度或引入新的問題。
- 另一方面，小程式程式碼體積限制比較嚴格，避免引入第三方框架在編譯過程中引入較大的框架程式碼。
-
支援mpvue（第三方框架）：營銷業務需要支援Web頁、小程式頁等多種渠道，通過引入mpvue，可以使各渠道複用Vue元件，進而提升開發效率。
通用元件
針對我們面對的業務場景，我們將各業務通用的基礎功能進行了梳理，抽離成一些元件來進行統一管理和維護。高複用性元件能夠有效提升開發效率，而且研發質量也可以得到很好的保障。
協同開發
多團隊合作開發小程式的模式下，我們將核心的主流程業務放在主包，其他各業務都存放在各自子包當中。這樣做的目的，是確保每個包中的業務相關性較強，避免了使用者使用中會有頻繁的子包模組載入過程，也能保證各業務團隊之間的隔離，避免出現業務衝突。
我們的通用元件和各業務子包都託管在npm上，然後進行模組化的管理。並通過對構建指令碼的改造，將npm引入到小程式主包中，進一步保證各業務間的隔離性，如下圖所示：
同時我們在小程式開發週期中，制定了版本管理、准入流程、釋出流程等，規範化小程式各環境版本的使用，進一步確保各團隊間的順暢合作。整體架構圖如下圖所示：
我們的系統架構，最底層是微信小程式的原生API，中層是各業務通用的核心元件，如登陸、WebView封裝元件、監控、資料上報等，均由統一的團隊建設和維護。對編譯構建工具進行外掛化改造，可以自由引入第三方框架進行開發。最上層是各業務方通過拆包將業務隔離開來。
第二部分：流程與工具
- 工具規範方面：我們提供了子包專案、元件建立腳手架。比如登陸、WebView等通用元件以及業務元件都使用我們的元件腳手架來進行建立，簡化並較低成本規範了子包專案搭建和構建過程，提升專案搭建效率與合作效率。
- 測試方面：我們為元件接入了單元測試。小程式整個專案的單元測試和UI的自動化測試也在建設中。我們在小程式開發週期中，制定了版本管理、准入流程、釋出流程等，規範化小程式各環境版本的使用，進一步確保各團隊間的順暢合作。
開發過程
在本地開發過程的整個構建流程如下圖所示。開發者在本地工作目錄執行操作，通過gulp構建目標檔案到本地工作目錄中，再通過微信開發者工具對生成的程式碼進行除錯和釋出。同時我們的構建支援Mock服務，模擬後端伺服器介面，提高聯調效率。
釋出過程
我們的釋出規範過程如下圖所示。和一般的前端釋出過程類似，差異點在於必須經過微信開發工具才能上傳程式碼進行微信方的稽核與釋出。
而我們的期望和後期規劃是將整個CI構建和釋出過程一體化。如下圖所示：
近期微信開發者工具提供了命令列工具和HTTP方式來支援小程式的預覽和上傳，我們正在將整個流程進行整合與改造。通過在伺服器中安裝微信開發者工具，將整個過程使用CI連線起來，減少人工操作的過程，來提升釋出流程的效率和質量。
不過在實現完全自動化釋出的道路上依然面臨著一些問題：
- 開發者工具的登陸，公眾後臺的提交稽核和釋出都需要人工介入。
- 由於微信開發者工具目前僅有macOS和Windows兩個版本，而CI伺服器大多是在Linux系統上，還需要額外啟動伺服器來部署開發者工具，改造過程也相對複雜。
第三部分：元件化
原生元件化演進
小程式原生框架對於模組和元件的支援也處在不斷完善的過程中。最早小程式框架支援CommonJS規範，可以使用require、module關鍵詞定義和引入js模組，支援通過@import來引入樣式檔案，支援在佈局檔案wxml中支援定義template模板，可以通過include、import和wxs等標籤引用外部檔案。
而實現一個元件，常常wxs邏輯，wxss樣式和wxml佈局三個檔案都需要進行定義，這就意味著引用一個元件時，需要在三個檔案中同時引入。元件獨立性差，與頁面檔案高耦合，不利於開發和維護，使用起來非常不便。
因此在基礎庫1.6.3版本中，小程式開始支援自定義元件，只需要通過標籤就可以很方便的引入自己開發的元件。但早期的自定義元件版本，只允許繫結JSON相容格式的資料，並不支援回撥函式，在使用上存在很大侷限性。直到2.0.9版本才開始支援函式傳入。
近期，小程式原生支援了npm，但基礎版本庫要求在2.2.1及以上，並且需要通過微信開發者工具進行一遍構建。總體來說，小程式框架在不斷完善對元件的支援，但如果考慮低版本使用者的相容性，開發者開始有較多工作要做。
元件分類
我們將元件劃分為三種型別，頁面元件、UI元件、功能元件。
- 頁面元件：功能相對比較獨立的頁面，如用於內嵌H5的WebView封裝頁面等；
- UI元件：頁面中區域性功能較獨立的UI部分，比如頁面中嵌入的登陸元件，商家列表等；
- 功能元件指：無UI和互動，純JS的模組。
通用元件關注方向
我們基於微信元件的演化也在擴充和完善我們的通用元件過程中，同時也相同存在著一些侷限性，之後針對通用元件的關注方向主要在以下兩方面：
- 小程式元件原生功能的補充和完善。
- 通用基礎及業務功能統一封裝。
Storage元件
大小約100k隨機物件讀寫清空快取各100次，小程式Storage與Web LocalStorage 耗時比較如下圖所示：
可見小程式的效能遠低於Webview的LocalStorage，所以針對這樣的現狀，我們Storage元件的封裝與設計必須重點考慮效能問題的解決與規避。
Storage元件優化
針對小程式Storage的讀寫效能差，且儲存量有限的情況下，我們Storage的設計有以下特點：
- 記憶體高效能讀寫資料：利用記憶體儲存資料替代大量資料存在小程式Storage中，從而規避Storage讀寫操作的效能瓶頸，同時減輕儲存量的佔用率。
- 檔案持久化儲存：採用記憶體與Storage相結合的形式，保證快取資料的可用性。
- 資料同步：由於持久化的策略，所以需要有完整並保證準確性的流程來同步記憶體資料與Storage資料。
整個流程如下圖所示：
防止誤呼叫底層API導致資料不同步：
- 寫入檔案時key追加特殊字首
- 編譯時進行語法檢查，誤呼叫及時告警
第四部分：展望與規劃
目前小程式開發工具也在不斷完善中，最近增加了很多諸如npm 支援、命令列呼叫、HTTP呼叫、Git版本管理、雲開發、體驗評分等功能，工具的完善為開發者帶來了一定便利。
小程式的特殊性導致小程式開發人員與微信提供的開發工具的強粘黏性，可以感知到微信小程式開發工具的設計是期望實現一個小程式開發的閉環。
但這樣的一個“黑盒”工具也存在著一定問題——無法滿足不同團隊和業務的一些需求。所以我們也希望，未來小程式開發工具能提供一些工具開放功能的API，我們可以對開放功能進行改造實現，最終滿足各個團隊不同的需求。
同時小程式在最初的定位（功能比較簡單的輕應用）和設計下，效能不會太高。如果承載較大型複雜的業務，勢必會遇到一些效能問題，所以效能問題的關注是比較重要的。官方對於效能問題在開發上的建議是控制setData 的資料體積大小、控制setData的頻率。但真實的業務場景中有很多是無法避免頻繁setData的，如對滑動操作（較高頻的動作）後的一些特殊需求、複雜頁面點選快速響應等。
美團外賣在基於這些問題的規劃包括：
- 小程式效能的測試指標定製：及時發現專案的效能瓶頸，進行有針對性的優化。經過測試小程式渲染資料達到100Kb時卡頓明顯，尤其在安卓手機，所以其中就包括對渲染資料大小制定一定指標。
- 效能分析工具：開發一些工具對效能進行分析。
- 框架優化：從框架層來針對性規避遇到的一些問題。
- 長列表元件的實現：使用官方提供的長列表元件。
此外，與效能並存的一個問題是小程式體積的限制（不超過2M，包含子包的主包，總包不超過8M）。這樣的限制有一定道理，因為小程式渲染前，需要經過下載整個小程式的包體、後端請求資料、對資料進行渲染這樣相對較長的週期，包體過大必然影響使用者感知渲染的時間，影響使用者體驗。
減小體積的規劃採取方案包括：
- npm依賴優化：npm包之間內部的依賴包會存在重複的情況，重複的部分都佔用包體積，採取對程式碼預解析簡化npm包程式碼來縮小包體。
- 圖片部署CDN：圖片體積佔包較大，非關鍵圖片部署到CDN。
- 非關鍵頁面遷移子包：採用子包、獨立子包的方式減少對主包體積的佔用。
- 頁面動態下發：小程式不支援動態下發功能，目前我們正在探索和考慮。
這兩大重點問題在我們的業務場景和當前架構設計下，都是未來長期需要關注和解決的問題。
總結
我們複雜的業務在開發小程式時雖然面臨著這樣一些問題：“輕”量應用的小程式對於較大型的應用和較複雜的業務場景存在著一定的侷限性，“輕”量理念的原生框架稍簡單，不足以完美支撐我們較大型和複雜的業務；多團隊合作如何保證高效性；如何更友好地滿足不同的業務場景。
最終我們通過在技術框架層面優化設計和規避一些小程式侷限性問題，制定更合理的流程和建設更強大的工具來提高工作效率，基於微信小程式元件化演進建設我們的元件化生態，來解決我們所面臨的問題。同時也對微信小程式工具、效能、體積等方面進行展望和規劃我們的後續程式，保持我們的深度探索和實踐。
