[[330713]]

小程序的開發(fā)不可避免的會面臨跨平臺開發(fā)的問題。各小程序平臺有哪些特點?如何處理各平臺的差異?本文分享淘票票在跨平臺開發(fā)上的經(jīng)驗總結(jié)，包含了技術(shù)演進及差異控制策略，希望能幫助同學(xué)們提前避坑。

在 2019 年，阿里巴巴文娛的淘票票幾乎涉足了當時市面上所有的小程序，其中在不少平臺上，我們是阿里第一批吃螃蟹的技術(shù)團隊。回顧過往，我們做過很多嘗試，也踩過很多坑。

我們特別整理了支付寶小程序、百度小程序、字節(jié)跳動小程序、快應(yīng)用的開發(fā)經(jīng)驗，希望為你帶來啟發(fā)。

一 支付寶小程序

支付寶內(nèi)的淘票票用戶主要是以購票為主，工具屬性比較明顯。淘票票入口眾多，均引導(dǎo)跳轉(zhuǎn)到小程序，引導(dǎo)用戶在小程序內(nèi)進行購票、娛樂消費、收藏、添加到首頁/桌面、分享等行為。

淘票票支付寶小程序，經(jīng)歷了近一年的起步開發(fā)，以及一年多的版本迭代，業(yè)務(wù)開發(fā)涵蓋了購票、視頻、資訊、社區(qū)等多個場景。

1 小程序開發(fā)

1) 在核心業(yè)務(wù)中慎用 web-view

實際項目線上運行情況及用戶反饋表明：web-view 初始化較慢、易受網(wǎng)絡(luò)干擾、性能差(對比離線包及普通 H5 頁面)、問題較多，建議不要在核心業(yè)務(wù)中使用 web-view 進行承載。

2) 自有城市體系與支付寶城市組件的適配技巧

由于支付寶的城市組件是基于自身城市體系的，淘票票擁有獨立的城市體系，所以需要城市選擇組件適配不同城市體系的場景。經(jīng)過幾輪推動迭代，淘票票線上已使用城市選擇組件，已支持復(fù)寫當前定位城市、歷史訪問城市、熱門城市、城市列表信息等。使用my.chooseCity、my.onLocatedComplete、my.setLocatedCity 三個 JSAPI 可實現(xiàn)對應(yīng)效果。

3) 如何實現(xiàn)沉浸式效果(透明導(dǎo)航欄)?

• 首先在 page.json 配置 “transparentTitle” 為 “auto” 屬性，開啟沉浸式布局。
• 其次，頁面布局適配沉浸式頂部透明導(dǎo)航欄即可，通過 my.getSystemInfo 獲取 titleBarHeight 及 statusBarHeight 可計算出頂部透明高度。

注意：Android 5.0 以下由于不支持沉浸式狀態(tài)欄，所以頁面會從狀態(tài)欄下開始布局。

4) 小程序 tabBar 換膚、紅點

主要使用的JSAPI及event：my.setTabBarStyle、my.setTabBarItem、page.onTabItemTap，參數(shù)參考官方文檔即可。注意事項如下：

• 小程序觸發(fā) relaunch 時，tabBar 的樣式會被清除，需要再次設(shè)置，目前建議在 app.onShow 里多次觸發(fā)設(shè)置邏輯。
• 盡量使用本地圖片，在線圖片有個下載的過程，體驗不太好，且弱網(wǎng)下圖片載入可能失敗。
• my.setTabBarItem 的參數(shù)每一項均需要賦值，否則 Android 可能會報 “invalid parameter”。

2 小程序開發(fā)注意事項

• 不要使用 tnpm 安裝依賴，tnpm 軟連接目前支持有問題。
• devDependencies 和 dependencies 需要分開，將 devDependencies 移到項目代碼外層，否則會額外增加包大小。
• 設(shè)置 transparent/pullRefresh 等 window 配置時，跳轉(zhuǎn)別的頁面會被繼承，需要在 app.json 初始化此類配置信息規(guī)避。
• web-view 里面的頁面會失去下拉刷新、resume 等特性。
• Android 低版本不支持 sticky 屬性。
• 某個值控制 dom 是否渲染，下次更新時此值若為 undefined 時不會銷毀掉會被忽略掉。
• window.atob、window.btoa 需要第三方庫來替代。
• lodash 某些方法不能直接使用，因為小程序構(gòu)建時無 global 對象。

3 小程序監(jiān)控

使用阿里云的 ARMS 平臺，參考官方文檔接入即可。

優(yōu)點：有實時大盤，排查用戶日志方便，上報更自由、豐富。

缺點：有接入成本、需要開發(fā)，增加包大小，且要收費。

4 小程序權(quán)限

小程序有權(quán)限管控，無論是申請 JSAPI 權(quán)限還是 H5 域名配置，都是需要打新的包上傳才能生效。

二 百度小程序

1 背景

以微信小程序為藍本的百度小程序，也同樣具備相似的商業(yè)定位。依賴百度這樣的老牌搜索門戶，百度小程序更加偏向目的性強的搜索熱詞進行小程序的關(guān)聯(lián)調(diào)起和互動，這也是百度小程序和其他小程序的區(qū)別。

由此，我們在 2018 年底進行了百度小程序的開發(fā)工作，由于在前期積累了小程序開發(fā)經(jīng)驗，百度小程序的開發(fā)更加的平穩(wěn)和快速，不到一個月就上線運營了。

2 應(yīng)用場景

百度小程序入口：

三種入口：百度App搜索關(guān)聯(lián)、百度貼吧關(guān)聯(lián)、其他百度生態(tài)搜索關(guān)聯(lián)。

3 開發(fā)實戰(zhàn)

下面是淘票票百度小程序開發(fā)過程中遇到的坑和總結(jié)：

1)基礎(chǔ)開發(fā)

百度小程序的開發(fā)與微信、頭條小程序的開發(fā)方式和框架概念非常相似，都屬于前端開發(fā)的一塊子集，主要可以分為 4 塊來構(gòu)建百度小程序的頁面：

• 第一塊：HTML。構(gòu)建頁面框架：使用 xxx.swan 文件進行頁面元素框架的搭建，具有獨特的 HTML 標簽如 view，scroll-view 等。
• 第二塊：CSS。管理頁面樣式：使用 xxx.css 文件進行頁面樣式的管理，基本的 CSS 的樣式都大部分支持。
• 第三塊：JS。編寫頁面邏輯：使用 xxx.js 文件進行頁面邏輯的書寫，小程序具有其獨特的生命周期管理方法。
• 第四塊：JSON。組件注冊：百度小程序支持通過組件的方式進行頁面的搭建，通過在 xxx.json 中注冊組件供頁面使用。

2)template 模板使用

與其他的小程序相同，百度小程序也提供了模板 template 的能力，使用模板可以提高工程化和代碼可維護性，開發(fā)者可以在模板中設(shè)計代碼片段，向外暴露接口注入外界變量之后，可以在合適的時機去使用該代碼片段。

但是在百度小程序使用 template 使用時，需要注意傳遞數(shù)據(jù)時需要使用 {{{ }}} 三層花括號包裹對象，否則數(shù)據(jù)注入時會出現(xiàn)異常。

百度小程序的 template 的使用：

<template is="xxx" data="{{{item}}}"/> 

作為對比，頭條、微信小程序 template 需要兩層花括號：

<template is="xxx" data="{{item}}"/> 

3)組件屬性的 observer 使用

在使用組件(Component)是大概率會使用到屬性的 observer 方法，當屬性被改變時會執(zhí)行屬性對應(yīng)的 observer 方法，此處需要注意在使用 observer 方法時，避免使用下劃線開頭的方法名，可能會造成 observer 方法的循環(huán)調(diào)用問題。

或者當發(fā)現(xiàn) properties 中的 observer 方法被循環(huán)調(diào)用時，檢查一下 observer 綁定的方法是否有下劃線。方法命名移除下劃線，大概率可以解決循環(huán)調(diào)用問題。

會出現(xiàn) observer 循環(huán)調(diào)用的情況：

isShowLoadMore: {           
  type: Boolean,           
  value: false,           
  observer: '_isshowChange'       
}, 

推薦的寫法：

isShowLoadMore: {           
  type: Boolean,           
  value: false,           
  observer: 'isshowChange'       
}, 

4)scroll-view 的使用

在使用 scroll-view 的開發(fā)過程中，對存在多個可滑動區(qū)域的頁面且其中一個滑動區(qū)域為 fixed 樣式時，iOS 機型會偶現(xiàn) scroll-view 空白的問題。

可能存在異常的頁面布局如下:

<view class='頭部組件' style='position:fixed'/> 
 
<scroll-view class='可滑動區(qū)域1' style='position:fixed' /> 
 
<view class='可滑動區(qū)域2' /> 

其中 “可滑動區(qū)域 2” 為依賴內(nèi)容撐開的頁面 View，當內(nèi)容到達一定長度時，頁面 View 會提供滑動能力。如果使用上述寫法可能會出現(xiàn) scroll-view 空白的問題。

推薦的寫法：

<view class='頭部組件' style='position:fixed'/> 
 
<scroll-view class='可滑動區(qū)域1' style='position:fixed;height:44px' /> 
 
<scroll-view class='可滑動區(qū)域2' style='height:80vh' /> 

5)小程序 DSL 頁與 WebView 頁的登錄流程

小程序的頁面實現(xiàn)方式可以分為兩種：一種為小程序原生的頁面;另外一種是使用 WebView 組件，將 H5 頁面展示在小程序中。處理兩種頁面的登錄時一般是先進行 DSL 頁登錄(小程序原生頁面)，完成 DSL 頁登錄后，再進行 H5 容器頁的登錄。

a) DSL 頁登錄

先進行小程序的登錄授權(quán)，獲取到小程序的登錄憑證，拿著登錄憑證去自己的業(yè)務(wù)服務(wù)端獲取真實的小程序登錄信息，當開發(fā)者完成上述流程之后，將登錄態(tài)信息加密后存儲在本地。下次進行需要登錄校驗的頁面時，進行本地登錄信息的登錄校驗，則 DSL 頁的登錄流程就完成了。

b) WebView 容器頁登錄

由于百度小程序無法操作到 WebView 容器的 cookie 信息，所以在 WebView 容器頁進行登錄時，勢必要進行一次從服務(wù)端獲取登錄 cookie 的過程。目前可以在進入需要登錄校驗登錄的 WebView 容器頁之前，先發(fā)起獲取 cookie 的服務(wù)端請求，服務(wù)端處理好用戶登錄信息校驗之后就可以提供一個同步 cookie 的專用頁面。當接口返回鏈接之后，小程序的 WebView 容器需要做的就是訪問這條鏈接將服務(wù)端返回的 cookie 同步到 WebView 容器中，這樣 WebView 容器就具備了可供校驗的登錄信息。

完成上述頁面的登錄操作之后，小程序登錄流程就結(jié)束了。

4 百度小程序總結(jié)

本文著重描述的是開發(fā)過程中大概率會遇到的問題和解決方案，最好結(jié)合官方文檔一起查看。

三 字節(jié)跳動小程序

1 背景

字節(jié)跳動小程序是基于字節(jié)跳動全產(chǎn)品矩陣開發(fā)， 與圖文、視頻等場景有著天然的搭配性，帶動小程序分發(fā)，由內(nèi)容為小程序帶量以及裂變。作為一個大流量且高度活躍的平臺，具有很大用戶增量挖掘空間。

對于頭條系應(yīng)用，同一小程序可以同步上線多個宿主端，目前已開放今日頭條、抖音、頭條極速版。無論是抖音，還是今日頭條，都屬于內(nèi)容分發(fā)平臺，相比公眾號讀者，抖音用戶相對更年輕，而頭條則擁有大量三四線城市讀者，這正好契合了電影作為內(nèi)容消費的特質(zhì)，幫助淘票票更好的拉動下沉用戶?；陬^條、抖音平臺自身的優(yōu)勢，我們在 2019 年上線了淘票票字節(jié)跳動小程序。

2 應(yīng)用場景

今日頭條的六個主要場景：

• 信息流推薦
• 搜索直達
• 頭條號掛載小程序
• 分享
• 中心化入口
• 留存入口

今日頭條

抖音的四個主要場景：

• 小視頻掛載
• 企業(yè)號主頁
• 搜索展示
• 留存入口

廣告投放

3 基礎(chǔ)介紹

字節(jié)跳動小程序基本開發(fā)思路類似于前端開發(fā)，并增強調(diào)用大量端能力，性能體驗優(yōu)于普通 Web 。上層架構(gòu)基于 JS 開發(fā)，可以輔助開發(fā)者進行良好得開發(fā)?？蚣芙Y(jié)構(gòu)和開放式類似于支付寶小程序、微信小程序和百度小程序。

目錄結(jié)構(gòu)：主要分為以下幾類的文件：

• .json 為后綴的 JSON 配置文件，這個文件配置了小程序所有頁面的路徑和界面展現(xiàn)樣式等。
• .ttml 結(jié)尾的模板文件，用來描述當前這個頁面的文件結(jié)構(gòu)，類似于網(wǎng)頁中的 HTML 文件。
• .ttss 結(jié)尾的樣式文件，描述頁面樣式，類似于網(wǎng)頁中的 CSS 文件。
• .js 結(jié)尾的 JS 文件，處理這個頁面和用戶的交互。

目錄結(jié)構(gòu)

四 快應(yīng)用卡片

1 概述

當前，基于超級 APP 推出的各種小程序，對手機廠商的分發(fā)能力及話語權(quán)有明顯削弱趨勢。因此國內(nèi)各手機廠商在推出快應(yīng)用后，也逐漸對外開放手機負一屏的能力，為快應(yīng)用及其他服務(wù)提供直接的入口。

2 卡片類型

快應(yīng)用的卡片類型可以分為：應(yīng)用類型的卡片、服務(wù)類型的卡片和其它類型的卡片。

• 應(yīng)用類型的卡片：是用戶訂閱的一種卡片，內(nèi)容相對固定。
• 服務(wù)類型的卡片：針對用戶關(guān)心數(shù)據(jù)的狀態(tài)，內(nèi)容實時變更。
• 其它類型的卡片：自定義卡片，根據(jù)實現(xiàn)對應(yīng)內(nèi)容展示及跳轉(zhuǎn)。

3 應(yīng)用卡片的具體接入

卡片的開發(fā)基于快應(yīng)用，所使用的 API 是快應(yīng)用的子集，部分 API 不能在卡片中使用。目前已知的 vivo，OPPO，NUBIA 都需要卡片的開發(fā)不依賴主 rpk，也就是需要保證卡片能脫離主 rpk 獨立渲染，為保證卡片的獨立渲染，不能使用 this.$app 相關(guān)對象及文件 app.ux 中聲明的工具類或生成的對象。

1)卡片的初始化配置

a) 配置文件

所有的卡片都需要和快應(yīng)用中聲明頁面一樣在 manifest.json 中聲明。具體是在 router.widgets 中配置，各廠商之間有部分差異，但差異不大。

b) 卡片配置文件注意事項

• widgets 中配置的 key 值請使用路徑名字，如果路徑為兩級(例：/A/B)，則 key 值配置為 "A/B"，且該值最終對應(yīng)到廠商后臺上傳卡片時填入的卡片路徑，基于此廠商才能正確解析到上傳到聯(lián)盟上統(tǒng)一的快應(yīng)用包中對應(yīng)的卡片。
• 卡片的屬性 features 中需要聲明該卡片會用到的系統(tǒng) API，這些 API 在外層應(yīng)用的 features 中已經(jīng)聲明過，此處需要再次聲明，否則不能使用。

2)應(yīng)用類型卡片接入(以 vivo 為例)

負一屏卡片線上效果圖

a) 卡片的聲明

在 manifest.json 中的除了上面提到的配置之外，對于卡片需要注意卡片屬性中的以下字段：

• params 字段用來配置卡片更為詳細的參數(shù)，及特有的支持參數(shù)，需要按照文檔進行配置。
• targetManufactorys 為對應(yīng)廠商適配標明該卡片匹配的廠商，具體參看文檔。

b) 卡片的開發(fā)的不同點(所使用的 API 及組件為其子集具體參看官方文檔)

• vivo 卡片是單獨工程，不能配置在快應(yīng)用工程中，需要另外建立新的工程。
• 對應(yīng)包打出也需要單獨配置和主快應(yīng)用不相同，需要用到 vivo 給出的相關(guān)工具。
• 卡片有單獨設(shè)置主題的功能。
• 卡片有折疊功能。
• 卡片視覺稿由內(nèi)容提供方給出。
• 卡片開發(fā)只需開發(fā)內(nèi)容區(qū)域，title 區(qū)域無需開發(fā)(由 vivo 負一屏容器完成繪制)同時意味著下半部分的圓角需要自己繪制。
• 上傳卡片包時需要提供對應(yīng)的 icon。

c) 卡片調(diào)試

卡片調(diào)試需要使用 vivo 方提供的工具打出來的 rpk 文件，同時需要使用 vivo 方提供的專用內(nèi)核及容器，具體按照文檔執(zhí)行即可。

d) 卡片提交

首先需要完成自測，自測之后需要使用 vivo 提供的專用打包工具，打包之后到 Jovi 后臺地址提交，同時需要提供一個應(yīng)用圖標。

4 負一屏服務(wù)類型卡接入

以下以 OPPO 服務(wù)卡接入為例：

觸發(fā)場景：用戶在淘票票快應(yīng)用中購票之后，在影片上映前的固定時間內(nèi)觸發(fā)該卡片內(nèi)容展示，進而提醒用戶取票，即消息觸發(fā)場景。

OPPO 負一屏卡片線上效果圖

1)OPPO服務(wù)卡卡片的聲明

在 manifest.json 中的 router 字段中添加 widgets 字段，并在該字段中添加對應(yīng)的配置，與 OPPO 應(yīng)用卡片完全相同。

2) 卡片開發(fā)

OPPO 服務(wù)卡開發(fā)涉及用戶關(guān)心數(shù)據(jù)狀態(tài)改變觸發(fā)卡片的場景，因此整體需要解決以下幾個問題：首先是觸發(fā)時機問題，然后是要確認觸發(fā)的卡片 ID，還要解決要觸發(fā)哪一個 OPPO 用戶。

3)OPPO 服務(wù)卡整體開發(fā)流程

前提：要開通 OPPO 賬號服務(wù)，保證在快應(yīng)用中能夠拿到 OPPO 當前登錄的用戶的授權(quán)碼。

a) 賬號綁定，即 OPPO 賬號和快應(yīng)用賬號的綁定

賬號綁定的入口：該入口由 OPPO 負一屏容器統(tǒng)一提供，位置如下圖左：

OPPO 服務(wù)卡綁定入口及自定義綁定頁面

該入口對應(yīng)一個快應(yīng)用內(nèi)的綁定頁面。

b) 綁定頁面開發(fā)，該頁面是快應(yīng)用頁面，主要提供綁定功能

作用是讓內(nèi)容商服務(wù)端知道自己的賬號和 OPPO 測的對應(yīng)關(guān)系，及換取發(fā)消息到 OPPO 端時所需要的 TOKEN 值。

c) 觸發(fā)對應(yīng) OPPO 用戶負一屏的卡片

內(nèi)容服務(wù)商在用戶關(guān)心數(shù)據(jù)變更時，觸發(fā)推送消息到 OPPO 服務(wù)端，該消息按 OPPO 文檔約定，帶上對應(yīng)的 TOKEN 值，要觸發(fā)的卡片 ID，消息內(nèi)容，要觸發(fā)的時機及時長，OPPO 服務(wù)端會根據(jù)該 TOKEN 找到對應(yīng)的用戶下發(fā)消息，并在需要的時機拉起對應(yīng) ID 的卡片。

d) 卡片消失

由發(fā)送消息中定義的卡片時長決定，展示時間到點后，負一屏容器會自動移除該卡片。

e) 調(diào)試

• 首先，需要 OPPO 服務(wù)端參與
• 其次，需要 OPPO 提供負一屏開發(fā)環(huán)境版本，以保證 OPPO 服務(wù)端日常環(huán)境的數(shù)據(jù)能夠到達。
• 再次，需要提供初步測試完成包含服務(wù)卡的 rpk 到 OPPO 側(cè)，把該 rpk 配置到 OPPO 對應(yīng)的環(huán)境。

f) 提交市場

測試完成可以在 OPPO 后臺提交該卡片，同時同步正式生成的卡片標示到自己的服務(wù)端用來推送消息使用。

g) 綜上涉及各端的開發(fā)工作如下：

• 首先，涉及服務(wù)端賬號綁定開發(fā)，TOKEN 刷新維護，觸發(fā)的消息推送到 OPPO。
• 其次，涉及前端的服務(wù)卡片開發(fā)以及綁定頁面開發(fā)。
• 涉及其他：OPPO 賬號服務(wù)開通。

5 踩坑記錄

• 負一屏的 UA 和快應(yīng)用中不同如果有與 UA 相關(guān)的配置需要注意。
• 對于調(diào)試時更新了 rpk 之后，實際打開對應(yīng)更改沒有體現(xiàn)時，可以嘗試清除對應(yīng)卡片容器的 cache，同時保證該容器有相應(yīng)的讀取存儲的權(quán)限。
• 對于同一個業(yè)務(wù)，由于各廠商適配不同及平臺不同，需要多處代碼編寫，但基本業(yè)務(wù)邏輯基本一致，唯一不同是 UI 展示，所以在一開始還是需要抽離數(shù)據(jù)邏輯，不同廠商給不一樣的 UI 展示即可。

四 淘票票小程序構(gòu)建演進

我們做了很多的小程序，對多端同構(gòu)也做了一些嘗試。

1 從一端到多端

1) 起步：小程序原生開發(fā)

2018 年，隨著小程序平臺爆發(fā)，我們首次踏出了淘寶域內(nèi)，進行了頭條小程序的嘗試。這次嘗試，使用的是原生的小程序 DSL 語法編寫。為了方便復(fù)用已有的 H5 樣式，加入了 Gulp，用來編譯 Less。

這種開發(fā)方式輕快，但是同時也暴露出了很多問題：

• 包體積很難控制。
• 原生 DSL 沒有任何復(fù)用性，并且需要重新學(xué)習(xí)。
• 無法使用 NPM，一些很常用的社區(qū)包，團隊基礎(chǔ)工具鏈無法使用。
• 機型兼容性不好，沒有 babel 支持。

2) 摸索：兩個端，一套代碼?

在開發(fā)百度小程序的過程中，吸取了第一次的教訓(xùn)，加入了 webpack 來做一層編譯，一是解決了包引入問題，二是加入了 babel 插件，解決 JS 兼容性問題，開啟 CommonChunk 插件，解決包大小問題。

總體上，從輸出一端變?yōu)檩敵鰞啥?，所以出現(xiàn)一些差異。對這些差異，編寫了一個插件，對業(yè)務(wù)層抹平。比如微信端引入 index.wx.js，頭條端引入 index.tt.js。

脫離了刀耕火種，開發(fā)效率明顯提升，但是還不夠好，視圖層還是兩份，而且以后每新增一端就要新拉出來一份。

3) 優(yōu)化：走向社區(qū)，跨多端

在開發(fā)頭條和百度小程序時，業(yè)內(nèi)也已經(jīng)有了在小程序 DSL 上封裝的框架，但是當時看都不是很成熟，基本都是專注于一個平臺，沒有什么跨端能力，就沒有用到生產(chǎn)環(huán)境，而是持續(xù)關(guān)注更新近況。

2019 年進軍微信小程序，再次看市面上的框架，發(fā)展的很快，同時也注意到跨端開發(fā)這個需求點，選擇了 Taro 作為主力框架。這種框架橫評就不展開了，市面上很多，簡單說幾個選擇 Taro 的原因：社區(qū)相對活躍、支持漸進式切換、TS、react like。

a) 平滑遷移

Taro 支持漸進式切換，也就是 Taro 和 DSL 混寫的能力，所以遷移成本可以接受。我們先將首頁 Taro 化，后面慢慢迭代將所有的頁面都切換為了 Taro，這里值得一提的是，Taro 的跨端差異化處理和我們之前的處理思路一樣，因此 Util 遷移起來幾乎 0 成本，成本主要集中在視圖層。

b) 好處是什么，缺點在哪里

使用 Taro 的好處是解決了我們之前遇到的主要問題，是一個一攬子解決方案。

同時這種上層框架在擴展新端時成本低，機動性很高，框架提供了新平臺包，適配成本低。

當然也遇到了一些新的問題，比較嚴重的是調(diào)試，因為代碼被轉(zhuǎn)譯過一次，同時不支持 Soucemap，導(dǎo)致 debug 時體驗很差。

2 多端差異

多端必然會有一些差異，業(yè)務(wù)的差別、端上 API 的差異等，比如微信上的分享能力，抖音上的抖音拍攝器，百度的 feed 流等。最終落在業(yè)務(wù)上，差別可以分為三部分，輸出不同的頁面、不使用同的組件(有的端使用原生組件)，細到不同的邏輯。

1) 輸出不同的頁面

在使用 Taro 時發(fā)現(xiàn)不支持，想到可以使用 babel-preval 來編譯時輸出頁面配置，這樣包體積也不會受影響，最后我們也反哺回社區(qū)。

使用不同的組件，不同的邏輯。根據(jù)端上不同的組件我們使用的最多的是多態(tài)模式，底層組件對外暴露相同的接口，端上調(diào)用時不需要考慮端上的差異，在 import 層會根據(jù)不同的端來引入不同的具體組件。

2) 端上邏輯

如果是一些簡單的邏輯差異，可以直接使用環(huán)境變量來做控制，走不同的邏輯。這種方式針對小一些的邏輯還可以，不過這種代碼一多，就不容易維護。

3) 針對維護性的建議

這里推薦幾種維護性比較強的差異處理方式：

• 設(shè)計組件時插件化：比如路由，不同端在跳轉(zhuǎn)前后需要有一些不同的操作，實現(xiàn)了插件化后，每一個端只需掛載不同的插件即可。
• 配置抽離：針對一些端上不同的配置，比如一些文案、固定內(nèi)容等，可以抽離到一個統(tǒng)一的地方維護，可以少很多 ifelse 邏輯。
• 用好函數(shù) hook：針對不同端相同的邏輯放在函數(shù)中，有差異的邏輯可以單拆函數(shù)作為 beforeHook 和 afterHook。

3 項目維護策略

項目輸出多端后，每次改動回歸就成為一個比較重要的問題，如何保證自己的代碼不會再其它端上出問題?每次改一個小程序其他都要立即回歸嗎?如何快速整理其他端的改動?下面針對多端項目的維護總結(jié)了一些經(jīng)驗。

1) 單測

針對核心邏輯編寫測試，unit test 和 snapshot test，我們內(nèi)部維護了一個針對端上 API 的 mock 測試庫，整個測試可以在 node 環(huán)境中運行，保證運行效率。

2) Commit 規(guī)范

指定一個 commit message 規(guī)范，可一眼看出你在做什么，在改哪一個端，以及后面回歸策略時用到。

3) git-hook

使用 githook 能保證上面的規(guī)范能夠真正的遵循，保證每次提交的質(zhì)量。pre-commit 時跑一下 Eslint，然后校驗一下 commit-message 是否符合規(guī)則，最后 push 時會跑一次整體的測試。

4) 多端的回歸策略

沒有做 E2E 的主要原因是小程序限制，case 編寫難度比較大，并且維護性低，無法自動化。

目前我們是人工回歸的，如何保證代碼不會再其他端上出問題?難道每一次改一個小程序其它都要立即回歸嗎?回答下這兩個問題，編寫代碼時考慮影響面，提交時提供足夠的改動信息，合并時主要測當前端即可，不需要回歸所有端。等另一個端需要發(fā)布時，拉出版本的 commit-message，然后梳理出變更范圍，在該端做回歸即可。這樣做減少對測試的集中消耗，保障質(zhì)量。

4 展望

以上是我們對跨端項目的經(jīng)驗總結(jié)，包含技術(shù)演進歷史以及差異控制策略?？缍隧椖康碾y點就是處理差異。

• 端上能力的參差不齊、業(yè)務(wù)針對不同場景的定制，一旦控制不好，整個人項目的維護性就會大大降低。
• 業(yè)務(wù)方面要思考清楚，不同的端，是相似的更多，還是差異多。
• 框架方面，最近看到有開發(fā)者已經(jīng)給 W3C 提小程序的白皮書了，總體朝著良性方向發(fā)展，這是一個好的開始，期待能夠標準化小程序框架。