[[330713]]

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

在 2019 年，阿里巴巴文娛的淘票票幾乎涉足了當(dāng)時(shí)市面上所有的小程序，其中在不少平臺(tái)上，我們是阿里第一批吃螃蟹的技術(shù)團(tuán)隊(duì)?；仡欉^往，我們做過很多嘗試，也踩過很多坑。

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

一 支付寶小程序

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

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

1 小程序開發(fā)

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

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

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

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

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

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

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

4) 小程序 tabBar 換膚、紅點(diǎn)

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

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

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

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

3 小程序監(jiān)控

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

優(yōu)點(diǎn)：有實(shí)時(shí)大盤，排查用戶日志方便，上報(bào)更自由、豐富。

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

4 小程序權(quán)限

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

二 百度小程序

1 背景

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

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

2 應(yīng)用場(chǎng)景

百度小程序入口：

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

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

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

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

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

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

2)template 模板使用

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

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

百度小程序的 template 的使用：

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

作為對(duì)比，頭條、微信小程序 template 需要兩層花括號(hào)：

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

3)組件屬性的 observer 使用

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

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

會(huì)出現(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ā)過程中，對(duì)存在多個(gè)可滑動(dòng)區(qū)域的頁(yè)面且其中一個(gè)滑動(dòng)區(qū)域?yàn)?fixed 樣式時(shí)，iOS 機(jī)型會(huì)偶現(xiàn) scroll-view 空白的問題。

可能存在異常的頁(yè)面布局如下:

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

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

推薦的寫法：

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

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

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

a) DSL 頁(yè)登錄

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

b) WebView 容器頁(yè)登錄

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

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

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

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

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

1 背景

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

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

2 應(yīng)用場(chǎng)景

今日頭條的六個(gè)主要場(chǎng)景：

• 信息流推薦
• 搜索直達(dá)
• 頭條號(hào)掛載小程序
• 分享
• 中心化入口
• 留存入口

今日頭條

抖音的四個(gè)主要場(chǎng)景：

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

廣告投放

3 基礎(chǔ)介紹

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

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

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

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

四 快應(yīng)用卡片

1 概述

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

2 卡片類型

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

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

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

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

1)卡片的初始化配置

a) 配置文件

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

b) 卡片配置文件注意事項(xiàng)

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

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

負(fù)一屏卡片線上效果圖

a) 卡片的聲明

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

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

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

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

c) 卡片調(diào)試

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

d) 卡片提交

首先需要完成自測(cè)，自測(cè)之后需要使用 vivo 提供的專用打包工具，打包之后到 Jovi 后臺(tái)地址提交，同時(shí)需要提供一個(gè)應(yīng)用圖標(biāo)。

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

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

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

OPPO 負(fù)一屏卡片線上效果圖

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

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

2) 卡片開發(fā)

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

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

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

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

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

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

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

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

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

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

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

d) 卡片消失

由發(fā)送消息中定義的卡片時(shí)長(zhǎng)決定，展示時(shí)間到點(diǎn)后，負(fù)一屏容器會(huì)自動(dòng)移除該卡片。

e) 調(diào)試

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

f) 提交市場(chǎng)

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

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

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

5 踩坑記錄

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

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

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

1 從一端到多端

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

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

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

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

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

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

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

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

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

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

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

a) 平滑遷移

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

b) 好處是什么，缺點(diǎn)在哪里

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

同時(shí)這種上層框架在擴(kuò)展新端時(shí)成本低，機(jī)動(dòng)性很高，框架提供了新平臺(tái)包，適配成本低。

當(dāng)然也遇到了一些新的問題，比較嚴(yán)重的是調(diào)試，因?yàn)榇a被轉(zhuǎn)譯過一次，同時(shí)不支持 Soucemap，導(dǎo)致 debug 時(shí)體驗(yàn)很差。

2 多端差異

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

1) 輸出不同的頁(yè)面

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

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

2) 端上邏輯

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

3) 針對(duì)維護(hù)性的建議

這里推薦幾種維護(hù)性比較強(qiáng)的差異處理方式：

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

3 項(xiàng)目維護(hù)策略

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

1) 單測(cè)

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

2) Commit 規(guī)范

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

3) git-hook

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

4) 多端的回歸策略

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

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

4 展望

以上是我們對(duì)跨端項(xiàng)目的經(jīng)驗(yàn)總結(jié)，包含技術(shù)演進(jìn)歷史以及差異控制策略。跨端項(xiàng)目的難點(diǎn)就是處理差異。

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