探索Taro：跨平臺(tái)開發(fā)的實(shí)踐與原理
引言
在如今不斷增長的小程序市場中，小程序的數(shù)量迅速增多。這是因?yàn)樾〕绦蚓哂兄T多優(yōu)勢，例如輕量化、便捷性和良好的用戶體驗(yàn)，吸引了越來越多的開發(fā)者和企業(yè)加入這一領(lǐng)域。隨著小程序的普及，各個(gè)行業(yè)都紛紛推出自己的小程序，以滿足用戶的多樣化需求。
然而，正是因?yàn)樾〕绦蚴袌龅亩鄻有院涂焖侔l(fā)展，每個(gè)小程序客戶端的 Api 差異也變得十分顯著。不同的小程序平臺(tái)為了滿足自身的特殊需求和功能定位，往往會(huì)對(duì) Api 進(jìn)行定制和調(diào)整。這導(dǎo)致了各個(gè)小程序客戶端之間的 Api 存在差異，不同平臺(tái)的開發(fā)者需要針對(duì)不同的 Api 進(jìn)行開發(fā)和適配。
對(duì)于開發(fā)者來說，針對(duì)不同平臺(tái)重新開發(fā)一套小程序應(yīng)用將變成一場無盡的噩夢。開發(fā)者需要熟悉并掌握每個(gè)客戶端的api差異，編寫大量重復(fù)的代碼，并進(jìn)行平臺(tái)特定的調(diào)試和適配工作。這不僅增加了開發(fā)的工作量和時(shí)間成本，還容易導(dǎo)致錯(cuò)誤和兼容性問題。
在這樣的背景下，Taro 的出現(xiàn)為開發(fā)者提供了一種解決方案。它通過提供一套統(tǒng)一的開發(fā)框架和組件，使開發(fā)者能夠編寫一套代碼，同時(shí)在多個(gè)小程序平臺(tái)上運(yùn)行。Taro 的編譯工具能夠?qū)㈤_發(fā)者的代碼轉(zhuǎn)換為不同平臺(tái)所需的代碼，從而實(shí)現(xiàn)跨平臺(tái)的開發(fā)和適配，減輕了開發(fā)者的負(fù)擔(dān)，提高了開發(fā)效率。
Taro是一套遵循 React 語法規(guī)范的多端統(tǒng)一開發(fā)框架（ps：Vue 語法也支持）。主要用于構(gòu)建跨平臺(tái)的小程序、H5和移動(dòng)應(yīng)用。市面上還存在其他的多端框架，包括但不限于：
- uni-app：uni-app是 DCloud 推出的一款基于 Vue.js 的跨平臺(tái)開發(fā)框架，可用于構(gòu)建微信小程序、支付寶小程序、H5、App等多個(gè)平臺(tái)的應(yīng)用。
- React Native：React Native 是由 Facebook 開發(fā)的框架，用于構(gòu)建原生移動(dòng)應(yīng)用。它使用JavaScript和React語法，允許開發(fā)者通過一套代碼同時(shí)在 iOS 和 Android 上構(gòu)建應(yīng)用。
- Flutter：Flutter是由 Google 開發(fā)的UI工具包，用于構(gòu)建跨平臺(tái)的移動(dòng)、Web 和桌面應(yīng)用。它使用 Dart 編程語言，提供了豐富的UI組件和渲染能力。
- Weex：Weex 是由阿里巴巴開發(fā)的跨平臺(tái)開發(fā)框架，使用 Vue.js 語法，用于構(gòu)建移動(dòng)應(yīng)用。它支持在 iOS、Android和 Web 上運(yùn)行。
- NativeScript：NativeScript 是由 Progress 開發(fā)的開源框架，用于構(gòu)建原生移動(dòng)應(yīng)用。它支持使用 JavaScript 或 TypeScript 編寫代碼，并提供了訪問原生 Api 的能力。
在上述的這些中，只有uni-app是支持小程序場景的，它占據(jù)了多端框架的半壁江山。
概括來講，Taro的主要特點(diǎn)和優(yōu)勢，參照官方說法：“使用 Taro，我們可以只書寫一套代碼，再通過 Taro 的編譯工具，將源代碼分別編譯出可以在不同端（微信小程序、H5、App 端等）運(yùn)行的代碼。”
一次編譯，多端運(yùn)行
這里需要解釋一下“編譯時(shí)配置”機(jī)制。官方說的“一次編譯”，并不是真的打一個(gè) dist 包，能跑遍所有的平臺(tái)。
而是根據(jù)你想要運(yùn)行的平臺(tái)，用對(duì)應(yīng)的指令，打出適合該平臺(tái)運(yùn)行的包。
舉個(gè)例子：
微信小程序 編譯命令 yarn build:weapp
百度小程序 編譯命令 yarn build:swan
支付寶小程序 編譯命令 yarn build:alipay
H5 編譯命令 yarn build:h5
RN 編譯命令 yarn build:rn --platform ios
……所以我們需要真正關(guān)心的，其實(shí)是針對(duì)目標(biāo)的平臺(tái)，Taro 都做了哪些事。下面以微信小程序?yàn)槔樱?/p>
Taro 框架內(nèi)置了對(duì)應(yīng)的編譯器和構(gòu)建工具，在 @tarojs/plugin-platform-weapp 微信小程序平臺(tái)插件中。在此注冊(cè)微信小程序平臺(tái)的配置項(xiàng)。
//taro-weapp/src/index.ts
//在此注冊(cè)微信小程序平臺(tái)
ctx.registerPlatform({
name: 'weapp',
useConfigName: 'mini',
async fn ({ config }) {
const program = new Weapp(ctx, config, options || {})
await program.start()
}
})預(yù)先定義一個(gè)名為微信小程序的 Template 模版類，該類繼承自 UnRecursiveTemplate。其主要功能是處理 Taro 框架中的模板相關(guān)操作，并根據(jù)特定需求進(jìn)行定制。
//taro-weapp/src/template.ts
export class Template extends UnRecursiveTemplate {
...
//構(gòu)建wxs模板
buildXsTemplate () {
return '<wxs module="xs" src="./utils.wxs" />'
}
//創(chuàng)建小程序組件
createMiniComponents (components): any {
const result = super.createMiniComponents(components)
// PageMeta & NavigationBar
this.transferComponents['page-meta'] = result['page-meta']
this.transferComponents['navigation-bar'] = result['navigation-bar']
delete result['page-meta']
delete result['navigation-bar']
return result
}
//替換屬性名稱
replacePropName (name: string, value: string, componentName: string, componentAlias) {
...
}
//構(gòu)建wxs模板中與焦點(diǎn)相關(guān)的方法，根據(jù)插件選項(xiàng)判斷是否啟用鍵盤附件功能，并返回相應(yīng)的字符串
buildXSTepFocus (nn: string) {
...
}
//修改模板結(jié)果的方法，根據(jù)節(jié)點(diǎn)名稱和插件選項(xiàng)對(duì)模板進(jìn)行修改。
modifyTemplateResult = (res: string, nodeName: string, _, children) => {
...
}
//構(gòu)建頁面模板的方法，根據(jù)基礎(chǔ)路徑和頁面配置生成頁面模板字符串。
buildPageTemplate = (baseTempPath: string, page) => {
...
}
}Taro 的編譯工具，根據(jù)所選擇的平臺(tái)，轉(zhuǎn)換成對(duì)應(yīng)平臺(tái)所需的代碼。使用 ctx.applyPlugins ，去調(diào)用相應(yīng)平臺(tái)的插件處理函數(shù)，其中 platform 參數(shù)指定對(duì)應(yīng)的平臺(tái):
//taro-cli/src/build.ts
...
await ctx.applyPlugins(hooks.ON_BUILD_START)
await ctx.applyPlugins({
name: platform,
opts: {
config: {
...config,
isWatch,
mode: isProduction ? 'production' : 'development',
blended,
isBuildNativeComp,
newBlended,
async modifyWebpackChain (chain, webpack, data) {
await ctx.applyPlugins({
name: hooks.MODIFY_WEBPACK_CHAIN,
initialVal: chain,
opts: {
chain,
webpack,
data
}
})
},
...除此之外呢，代碼轉(zhuǎn)換過程，還涉及：
- 語法轉(zhuǎn)換：Taro 支持使用類似于 React 的 JSX 語法進(jìn)行開發(fā)，它將 JSX 代碼轉(zhuǎn)換為不同平臺(tái)所支持的語法，如小程序的 WXML、React Native 的組件等。
- 樣式轉(zhuǎn)換：Taro 支持使用 CSS 預(yù)處理器編寫樣式，例如 Sass、Less 等。編譯過程中，Taro 將這些樣式文件轉(zhuǎn)換為不同平臺(tái)所支持的樣式表，如小程序的 WXSS、H5 的 CSS 等。
在編譯過程中，Taro 還會(huì)執(zhí)行：
- 靜態(tài)資源處理：Taro 會(huì)處理項(xiàng)目中的靜態(tài)資源文件，如圖片、字體等，將其轉(zhuǎn)換為適用于不同平臺(tái)的格式，并進(jìn)行壓縮和優(yōu)化。
- 文件復(fù)制：Taro 會(huì)將一些不需要編譯的文件直接復(fù)制到輸出目錄中，如項(xiàng)目配置文件、靜態(tài)頁面等。
- 文件合并與分割：Taro 會(huì)根據(jù)配置和代碼中的引用關(guān)系，將多個(gè)文件進(jìn)行合并或分割，以提高代碼加載性能。
- 代碼壓縮與混淆：Taro 可以對(duì)生成的代碼進(jìn)行壓縮和混淆，以減小文件體積和提高執(zhí)行效率。
跨平臺(tái)適配和差異處理
不通平臺(tái)的api或多或少，總有一些差異。Taro如何實(shí)現(xiàn)api的適配和差異化處呢？
Taro 通過適配層和條件編譯等機(jī)制實(shí)現(xiàn) api 的適配和差異化處理。
它提供了一套統(tǒng)一的 api 接口，開發(fā)者可以在代碼中使用這些 api，而 Taro 在編譯過程中會(huì)將這些 api 轉(zhuǎn)換為適用于各個(gè)平臺(tái)的具體實(shí)現(xiàn)。
以getLocation 為例。
如果我們要使用定位功能，在 Taro 中只需要在項(xiàng)目中使用 Taro 提供的 api getLocation :
Taro.getLocation().then(res => {
console.log(res.latitude, res.longitude);
});在編譯過程中，Taro 會(huì)根據(jù)目標(biāo)平臺(tái)的差異，將這段代碼轉(zhuǎn)換為適用于不同平臺(tái)的具體實(shí)現(xiàn)。
對(duì)于微信小程序來說，轉(zhuǎn)換為微信小程序的 wx.getLocation，同時(shí)保留原始的參數(shù)和回調(diào)函數(shù)：
wx.getLocation().then(res => {
console.log(res.latitude, res.longitude);
});而對(duì)于支付寶小程序而言，Taro 則會(huì)將其轉(zhuǎn)換為支付寶小程序的 my.getLocation，同樣保留原始的參數(shù)和回調(diào)函數(shù)：
my.getLocation().then(res => {
console.log(res.latitude, res.longitude);
});如此，Taro 在編譯過程中根據(jù)目標(biāo)平臺(tái)的差異，將統(tǒng)一的 api 轉(zhuǎn)換為各個(gè)平臺(tái)所支持的具體 api。在這段代碼中，processApis 函數(shù)接收一個(gè) api 集合作為參數(shù)，并對(duì)其中的每個(gè)api進(jìn)行處理：
//shared/native-apis.ts
function processApis (taro, global, config: IProcessApisIOptions = {}) {
...
apis.forEach(key => {
if (_needPromiseApis.has(key)) {
const originKey = key
taro[originKey] = (options: Record<string, any> | string = {}, ...args) => {
let key = originKey
// 第一個(gè)參數(shù) options 為字符串，單獨(dú)處理
if (typeof options === 'string') {
...
}
// 改變 key 或 option 字段，如需要把支付寶標(biāo)準(zhǔn)的字段對(duì)齊微信標(biāo)準(zhǔn)的字段
if (config.transformMeta) {
...
}
...
// 為頁面跳轉(zhuǎn)相關(guān)的 api 設(shè)置一個(gè)隨機(jī)數(shù)作為路由參數(shù)。為了給 runtime 區(qū)分頁面。
setUniqueKeyToRoute(key, options)
// Promise 化：將原本的異步回調(diào)形式轉(zhuǎn)換為返回Promise對(duì)象的形式，使api的調(diào)用更加方便且符合現(xiàn)代JavaScript的異步處理方式。
const p: any = new Promise((resolve, reject) => {
obj.success = res => {
config.modifyAsyncResult?.(key, res)
options.success?.(res)
if (key === 'connectSocket') {
resolve(
Promise.resolve().then(() => task ? Object.assign(task, res) : res)
)
} else {
resolve(res)
}
}
obj.fail = res => {
options.fail?.(res)
reject(res)
}
obj.complete = res => {
options.complete?.(res)
}
if (args.length) {
task = global[key](obj, ...args)
} else {
task = global[key](obj)
}
})
// 給 promise 對(duì)象掛載屬性
if (['uploadFile', 'downloadFile'].includes(key)) {
...
}
return p
}
} else {
...
}
})
...
}ps：雖然 Taro 提供了一套統(tǒng)一的 api 接口，但某些平臺(tái)可能不支持特定的功能或特性。可能需要使用條件編譯來調(diào)用平臺(tái)特定的 api，以處理特定平臺(tái)的差異。
跨平臺(tái)UI組件庫
當(dāng)我們使用 Taro 去編寫多端項(xiàng)目，需要使用 Taro 提供的 View 等Taro組件。
因?yàn)?，這些Taro組件，在不同平臺(tái)上會(huì)被轉(zhuǎn)換為相應(yīng)的原生組件或元素。
舉個(gè)例子，下面的代碼中，我們使用Taro提供的Image,View,Text組件創(chuàng)建視圖：
import Taro from '@tarojs/taro';
import { View, Text, Image } from '@tarojs/components';
function MyComponent() {
return (
<View>
<Text>Hello</Text>
<Image src="path/to/image.png" />
</View>
);
}在編譯生成過程中，Taro 會(huì)根據(jù)目標(biāo)平臺(tái)的差異將組件轉(zhuǎn)換為適用于各個(gè)平臺(tái)的具體組件。比如View 組件會(huì)被轉(zhuǎn)換為微信小程序的 view 組件。對(duì)H5來說，View 組件會(huì)被轉(zhuǎn)換為 <div> 元素。
在微信小程序中：
<view>
<text>Hello</text>
<image src="path/to/image.png"></image>
</view>在 H5 中：
<div>
<span>Hello</span>
<img src="path/to/image.png" />
</div>這樣，我們可以使用相同的代碼編寫視圖，也就是官方說的只要寫一套代碼的意思。
通過抽象層、平臺(tái)適配、跨平臺(tái)編譯等處理，Taro其實(shí)已經(jīng)為多端組件庫的實(shí)現(xiàn)鋪平了道路。如果你要做一個(gè) Taro-UI 那樣適應(yīng)自己的多端組件庫。直接使用Taro提供的基礎(chǔ)組件去搭建復(fù)雜組件即可。
反向轉(zhuǎn)換
如果你說，你以前做過一個(gè)微信小程序，現(xiàn)在老板要你平行移植到支付寶等小程序中。來不及重構(gòu)代碼的話，反向轉(zhuǎn)換也許能救一救急。反向轉(zhuǎn)換，故名思義就是將小程序轉(zhuǎn)換為Taro項(xiàng)目。
相關(guān)的代碼在 @tarojs/cli-convertor 包中，核心邏輯在 parseAst 中，生成 AST 樹，遍歷處理對(duì)應(yīng)的內(nèi)容：
//taro-cli-convertor/src/index.ts
parseAst ({ ast, sourceFilePath, outputFilePath, importStylePath, depComponents, imports = [] }: IParseAstOptions): {
ast: t.File
scriptFiles: Set<string>
} {
...
// 轉(zhuǎn)換后js頁面的所有自定義標(biāo)簽
const scriptComponents: string[] = []
...
traverse(ast, {
Program: {
enter (astPath) {
astPath.traverse({
//對(duì)類的遍歷和判斷
ClassDeclaration (astPath){...},
//表達(dá)式
ClassExpression (astPath) {...},
//導(dǎo)出
ExportDefaultDeclaration (astPath) {...},
//導(dǎo)入
ImportDeclaration (astPath) {...},
//調(diào)用
CallExpression (astPath) {...},
//檢查節(jié)點(diǎn)的 object 屬性是否為標(biāo)識(shí)符 wx，如果是，則將 object 修改為標(biāo)識(shí)符 Taro，并設(shè)置一個(gè)標(biāo)志變量 needInsertImportTaro 為 true。這段代碼可能是將 wx 替換為 Taro，以實(shí)現(xiàn)對(duì) Taro 框架的兼容性處理。
MemberExpression (astPath) {...},
//檢查節(jié)點(diǎn)的 property 屬性是否為標(biāo)識(shí)符 dataset，如果是，則將 object 修改為一個(gè) getTarget 函數(shù)的調(diào)用表達(dá)式，傳遞了兩個(gè)參數(shù) object 和標(biāo)識(shí)符 Taro。它還創(chuàng)建了一個(gè)導(dǎo)入語句，將 getTarget 函數(shù)引入，并將其賦值給一個(gè)對(duì)象模式。這段代碼可能是對(duì)可選鏈?zhǔn)秸{(diào)用中的 dataset 屬性進(jìn)行處理，引入了 getTarget 函數(shù)來實(shí)現(xiàn)相應(yīng)的轉(zhuǎn)換。
OptionalMemberExpression (astPath) {...},
// 獲取js界面所有用到的自定義標(biāo)簽，不重復(fù)
JSXElement (astPath) {...},
// 處理this.data.xx = XXX 的情況，因?yàn)榇吮磉_(dá)式在taro暫不支持, 轉(zhuǎn)為setData
// 將this.data.xx=XX 替換為 setData()
AssignmentExpression (astPath) {...}
})
},
exit (astPath) {...}
},
})
...
return {
ast,
scriptFiles,
}
}ps：盡管官方提供了反向轉(zhuǎn)換這一種工具，但是目前還是有局限性的。并不是所有的小程序都支持反向轉(zhuǎn)換，目前只有微信小程序。且并不是所有的原生 api 都可以被轉(zhuǎn)換，需要注意。希望后續(xù)該功能能夠繼續(xù)擴(kuò)大，完善。
性能優(yōu)化——預(yù)渲染（Prerender）
為什么需要 Prerender?官方給出了解釋：
Taro Next 在一個(gè)頁面加載時(shí)需要經(jīng)歷以下步驟：
框架（React/Nerv/Vue）把頁面渲染到虛擬 DOM 中
Taro 運(yùn)行時(shí)把頁面的虛擬 DOM 序列化為可渲染數(shù)據(jù)，并使用 setData() 驅(qū)動(dòng)頁面渲染
小程序本身渲染序列化數(shù)據(jù)和原生小程序或編譯型小程序框架相比，步驟 1 和 步驟 2 是多余的。如果頁面的業(yè)務(wù)邏輯代碼沒有性能問題的話，大多數(shù)性能瓶頸出在步驟 2 的 setData() 上：由于初始化渲染是頁面的整棵虛擬 DOM 樹，數(shù)據(jù)量比較大，因此 setData() 需要傳遞一個(gè)比較大的數(shù)據(jù)，導(dǎo)致初始化頁面時(shí)會(huì)一段白屏的時(shí)間。這樣的情況通常發(fā)生在頁面初始化渲染的 wxml 節(jié)點(diǎn)數(shù)比較大或用戶機(jī)器性能較低時(shí)發(fā)生。
Taro 預(yù)渲染的工作原理是，在構(gòu)建階段使用服務(wù)器端渲染（SSR）的技術(shù)，將頁面組件渲染成靜態(tài) HTML 文件，并將其保存在靜態(tài)文件目錄中。然后，當(dāng)客戶端請(qǐng)求該頁面時(shí)，直接返回預(yù)渲染的靜態(tài) HTML，而不是動(dòng)態(tài)生成頁面。
通過在構(gòu)建階段將頁面渲染為靜態(tài) HTML 文件，以提升首次加載速度、改善用戶體驗(yàn)和優(yōu)化搜索引擎的索引。
使用方式：
//config/index.js 或 /config/dev.js 或 /config/prod.js
const config = {
...
mini: {
prerender: {
match: 'pages/shop/**', // 所有以 `pages/shop/` 開頭的頁面都參與 prerender
include: ['pages/any/way/index'], // `pages/any/way/index` 也會(huì)參與 prerender
exclude: ['pages/shop/index/index'] // `pages/shop/index/index` 不用參與 prerender
}
}
};
module.exports = config更多使用詳見官網(wǎng)文檔。
總結(jié)
經(jīng)過上面粗淺的分析，我們可以初步了解 Taro 的整套運(yùn)作機(jī)制。以下是對(duì)其運(yùn)作機(jī)制的總結(jié)：
- 代碼轉(zhuǎn)換和條件編譯：Taro 通過將代碼轉(zhuǎn)換和條件編譯應(yīng)用于源代碼，生成適用于目標(biāo)平臺(tái)的代碼。這使得我們可以使用一套代碼編寫多個(gè)平臺(tái)的應(yīng)用程序。
- 抽象層和平臺(tái)適配層：Taro 提供了一個(gè)抽象層和平臺(tái)適配層來處理代碼轉(zhuǎn)換過程，確保 api 在不同平臺(tái)上的兼容性。這使得我們可以在不同的平臺(tái)上使用相同的 api 進(jìn)行開發(fā)。
- Taro 自定義組件和多端適應(yīng)性：Taro 的內(nèi)置組件天然適應(yīng)框架，這意味著我們可以構(gòu)建適用于多個(gè)平臺(tái)的組件庫，如 Taro UI。這樣可以提高開發(fā)效率并實(shí)現(xiàn)跨平臺(tái)的一致性。
- 反向轉(zhuǎn)換：反向轉(zhuǎn)換是一種逆向思路，試圖通過將已有的應(yīng)用程序轉(zhuǎn)換為 Taro 代碼來實(shí)現(xiàn)跨平臺(tái)。然而，反向轉(zhuǎn)換存在不穩(wěn)定性和局限性，并且對(duì)于維護(hù)者來說收益有限。
- 預(yù)渲染（Prerender）作為性能優(yōu)化選擇：Taro 提供了預(yù)渲染（Prerender）技術(shù)作為一種性能優(yōu)化選擇。預(yù)渲染可以在構(gòu)建過程中生成靜態(tài) HTML 頁面，以提升首次加載速度和優(yōu)化搜索引擎的索引。這是一種有效的性能優(yōu)化手段。
