新人如何在大搜車寫小程序

2018 年 11 月25 日，由又拍雲舉辦的 Open Talk 丨2018 小程序開發者沙龍系列活動杭州站圓滿落幕，本次會議吸引了 200 多人次報名到場率高達 90%，同時也爲數千線上直播觀衆提供了一場關於小程序開發的饕餮大餐。大搜車前端開發工程師夏心雨在活動做了《新人如何在大搜車寫小程序》的分享。

「2018 小程序開發者沙龍」是又拍雲 Open Talk 繼「2018 音視頻技術沙龍」後推出的重磅活動，與大部分偏重營銷、流量的小程序活動不一樣，本系列活動更熱衷於分享小程序開發過程的種種有趣經歷和有益的經驗。

夏心雨目前在大搜車作前端開發，包括移動端和小程序開發，她認爲技術棧和實踐方案的選擇，適合本身業務的纔是最好的。大搜車的網約車小程序項目選擇了原生框架，並基於這個項目的開發分享了一些實踐經驗，包括生命週期的使用、小程序路由、setData 數據驅動耗時等問題的解決思路。

如下是分享實錄：

 

選擇適合本身的技術棧

微信小程序的推出帶來了熱潮，市面上也出現了不少小程序的應用，大搜車在支付寶小程序、微信小程序、百度智能小程序以及快應用上都開發過業務。從用戶流量的角度上來看，大搜車更偏向於支付寶和微信小程序。在宏觀上對這兩個小程序作一個對比，從服務類型來看，支付寶小程序憑藉芝麻信用延伸出來的商業類型的小程序佔比會比較大，而微信小程序憑藉用戶量以及用戶活躍度，在社交和內容推廣等方面有着較大的優點。從開發技術的角度來看，微信小程序和支付寶小程序的基礎語法很是類似，開發者能夠將微信小程序的代碼進行轉化爲支付寶小程序的代碼。另外一方面，支付寶小程序是對第三方的服務商以及企業開發者開放權限，而微信小程序增長了我的開發者的權限，也給開發者有更多實踐的機會。

在大搜車正在運行的交互業務線上，統計出支付寶小程序在交易的轉化率上要比微信小程序更高，不過當前的業務須要依賴於用戶進行推廣和招募，因此選擇用戶活躍度更高的微信小程序更適合大搜車當前的業務。

微信小程序的框架有不少，除了經常使用的 WePY、mpVue 框架，還有京東推出的 Taro 框架和網易考拉的 megalo 框架，這些框架最終都是將項目代碼編輯打包成支持原生框架的代碼，都是往多端統一開發這個方向開發的。騰訊官方推出的 WePY 框架採用了類 Vue 的語法，能夠給使用類 Vue 的開發者下降開發成本。並且 WePY 框架對原生的大部分原生的異步 API 進行了處理，幫助開發者避開回調地問題。同時，WePY 框架也對數據綁定和事件綁定進行了優化，但一樣也沒有實現數據的雙向綁定能力，並且 WePY 框架是對原生框架的二次封裝，語法中仍是支持原生語法的。

拿生活中的例子來對比一下 WePY 和原生框架，好比說媽媽讓你去買醬油，首先你得知道超市裏什麼東西是醬油，也就是開發者起碼要掌握開發小程序的基本知識；出行方式你能夠選擇步行或者騎車，選擇騎車是快一點，可是前提是你得會騎車，也就是說開發者曾經使用過或者學習過 Vue 框架。而在這個過程當中，它的安全係數是沒有辦法來保證的，就是你使用任何一個框架，都會有它本身的一些規則，會遇到一些不同的坑，都須要你們本身去體驗一下才能感覺獲得。因此在實際開發中，咱們要考慮多方面的因素來選擇適合本身項目的框架。

 

大搜車原生小程序框架實踐

微信小程序將應用分爲了視圖層和邏輯層，分別運行在兩種獨立的線程中。上圖能夠理解爲每一個頁面都有本身的 webView 線程，全部的邏輯腳本則運行在同一個 JSCore 線程中，所以邏輯腳本上沒有瀏覽器對象，不能直接對 DOM 進行操做。另外，同一個邏輯腳本的線程會形成一些衍生問題，好比在頁面中的定時器在跳轉到其餘頁面的時候，並不會被自動清除，須要開發者去手動清除這些定時器，避免形成非預期的問題，相似於 SPA 的開發模式。

小程序的獨立線程的運行模式方式在渲染上也相應會增長一些額外的開銷，它須要視圖線程和邏輯線程的交叉工做，頁面進行初次渲染的時候，視圖層會對頁面進行初始化，並等待邏輯層傳遞過來的初始數據，接收到數據後將初始數據和節點樹進行解析整合渲染到視圖層，這樣就完成了頁面的初始渲染。在頁面初始渲染的過程當中，視圖層會根據頁面的節點來渲染成一個相似於 DOM 樹的結構，因此頁面的節點數量也會影響着頁面渲染的速度。咱們能夠對這個節點的使用進行優化，好比減小一些沒必要要節點的使用，減小富文本標籤 text 的使用，在條件渲染、列表渲染的時侯，多選擇使用不會被渲染到節點樹的 block 標籤代替 view 標籤。此外初始渲染的過程當中，數據會有一個從邏輯層到視圖層的跨線程的耗時問題，咱們能夠利用緩存數據進行數據初始化，再異步進行數據的請求，減小用戶等待的時間。當頁面初始渲染完成之後，視圖層的數據須要更新時，頁面會進行重渲染，重渲染的過程是由 setData 數據驅動引發的，咱們要優化使用setData來減小跨線程開銷。好比每次能夠儘可能更新最小單位的數據，甚至能夠將一些更新頻率較大的內容提取成組件，從而實現頁面的局部更新。

小程序的頁面渲染和它的生命週期有着不可分割的關聯。在小程序的實例中，咱們會對小程序的數據進行初始化，以及解決用戶登錄受權的問題。若是在你的項目中，每個接口都須要對用戶的登錄態進行判斷的話，爲了不首屏頁面接口的異步請求形成屢次的用戶登陸，咱們能夠不在 onLaunch 的生命週期中進行用戶的登錄，而是在數據封裝請求的方法中，對用戶的登錄態進行判斷，作一個接口的同步處理，等待用戶登錄成功後，再以鏈式的方式來請求其餘數據。另外，咱們能夠巧妙地利用 onLaunch 生命週期中能夠獲取參數這個功能，在小程序碼中拼接包含服務器環境的參數來進行項目環境的判斷以及切換，好比一些測試環境和預發環境。

頁面實例的生命週期使用會比較頻繁，頁面的 onLoad 生命週期只會在頁面 onLoad 的狀況下才會被執行，好比頁面的重定向事件觸發頁面的卸載。若是用戶的需求是每次進入到頁面的時候都須要對數據進行刷新，能夠在 onShow 函數中進行數據請求，或者使用頁面實例的下拉刷新鉤子函數，讓用戶手動來進行刷新數據。分享一個關於上拉加載鉤子函數的小坑，可使用元素僞類解決設置容器 padding 的問題。另外，邏輯層初始化時data的加載和頁面的 onLoad、onShow 生命週期是異步進行的。若是咱們直接獲取本地緩存數據進行 data 數據的賦值，咱們並不能在頁面初始渲染的時候，及時地將數據渲染到初始化的頁面上。

小程序的頁面跳轉分爲兩種類型：tabbar 的跳轉和其餘類型的跳轉。tabbar 只能使用 switchTab 進行跳轉，通常狀況下咱們會在跳轉 url 上進行一些參數的拼接，但這種方法在小程序的 switchTab 和 navigateBack 方法中都不能使用，不過可使用全局變量或者本地緩存的方式進行參數的傳遞。並且小程序的頁面棧是有上限的，雖然官方已經把這個上限從 5 增長到了 10，可是你們在使用路由的時候仍是須要進行合理的優化。好比用戶屢次點擊跳轉形成屢次的頁面跳轉，會浪費頁面棧的內存。能夠經過控制一個全局的布爾變量，結合定時器的使用，阻止用戶在必定時間內的屢次點擊事件。相似的咱們須要對用戶屢次點擊提交表單操做進行控制，能夠藉助官方提供的提示框功能，在用戶點擊時觸發 showLoading 方法，顯示加載提示框，阻止用戶對頁面進行交互。並在數據請求完成以後，調用 hideLoading 方法將提示框關閉掉。

上文提到的使用 setData 數據驅動耗時問題，以及數據綁定的 mustache 語法不能使用 JS 函數的問題，咱們能夠合理使用 WXS 腳本，這個腳本的功能相似於咱們日常使用的 Filters。WXS 與 HTML 運行在同一個線程上，會減小跨線程的開銷，能夠代替 JS 文件中的一些處理數據方法。由於 WXS 只提供 5 個基礎庫，並且對 ES6 的語法不太支持，不能使用 let 來定義變量。我在開發的過程當中遇到了使用 try、catch 語法會終止編譯卻不會有編譯報錯的狀況，因此你們在使用的時候要多加註意。另外一方面，WXS 和 JS 性能差別在不一樣系統上也有所不一樣，在 iOS 上的使用比在 android 上使用性能優化的更多。

關於微信提供的幾個原生組件的使用，像 input、Textarea 客戶端原生的表單組件會存在樣式問題，須要咱們對默認樣式進行覆蓋，並且它們在視圖上有較高層級，須要咱們使用cover-view 組件來進行補救。幸運的是，近期官方已經對 input 組件進行了同層處理，並在後期也會逐漸對其餘原生組件進行同層處理。

 

Vue 技術棧結合小程序開發

目前大搜車全部的前端項目都是基於 Vue 技術棧開發的，除了一些使用 Vue1 的老項目，其餘項目都使用 Vue2 框架。在這個基礎上，大搜車依賴於 Vue 技術作出了大量的技術沉澱，好比各端的 UI 組件庫，各類插件例如 AB Test 插件，造成了一套相對成熟的代碼結構統一框架，另外還有 CI/CD 和支持所有前端項目的腳手架服務。

由於 Vue 技術棧在大搜車前端的比重相對較大，因此上文提到的京東基於 React 技術棧的 Taro 框架就不太適合咱們了。所以大搜車規劃了一套基於 Vue 技術棧的小程序開發解決方案，採用原生結合 H5 的混合開發模式，藉助原生框架提供的 WebView 組件，以及它提供的一些 SDK 中的通訊 API，對不一樣平臺的 API 進行統一的封裝，在底層封裝的時候對項目的平臺進行判斷，再使用原生語法開發各個應用平臺的原生插件加以支持，保證一個 H5 的項目能夠和不一樣平臺的原生框架之間正常進行通訊，這樣就造成了一套跨平臺的小程序開發解決方案，能夠大幅度減小小程序項目的開發成本。

這個方案的使用方法，就是咱們在不一樣的 H5 項目中引用插件，保證跟原生框架的正常通訊，再嵌入到原生框架中進行維護，這樣咱們就能夠以 H5 的開發迭代來推進小程序的開發迭代。

在這個的基礎上，結合目前已經有的 H5 的技術沉澱，對這個方案進行延伸賦能。好比爲小程序的項目提供腳手架服務，同時這個方案能夠繼承一些咱們現有的例如 UI 組件庫、各類插件、多環境切換、自動部署等技術沉澱。

上圖是在建立項目時能夠選擇小程序的類別、渠道以及其餘的一些配置項，能夠一鍵生成一個自定義的小程序項目。

在 H5 項目中能夠手動選擇一個小程序的通訊插件使這個項目能夠在小程序原生框架中使用。

最後，夏心雨提到開發者們在實際的開發過程當中，應該多關注官方社區的動態，及時的跟進官方的迭代以保證本身的項目能獲得及時維護，多去看看其餘開發者遇到的問題，你們一塊兒學習進步。雖然這種填坑經驗並不算是真正的基礎知識，也並非基於對底層的理解，可是經驗積累多了，總會有一些質的進步，這就須要你們多去親自實踐體驗，至於技術棧和實踐方案的選擇，適合本身業務的纔是最好的。

 

推薦閱讀：

新人如何在大搜車寫小程序（演講視頻+ppt）

小程序設計與運營的思考 - 二爺​