作者簡介

Frank，攜程前端研發，專注前端性能優化、一碼多端、工程化建設等領域。

一、業務背景

隨著移動互聯網和智能設備的普及，前端開發人員需要采用多端同構技術來適配不同的終端（小程序、App和Web）。這些終端之間存在著明顯的差異，包括瀏覽器引擎、操作系統、交互方式以及代碼語言等方面。

這些差異給前端開發人員帶來了不少挑戰。一方面，不同終端采用不同的瀏覽器引擎和操作系統，導致頁面渲染和交互行為的表現各不相同。另一方面，不同終端所使用的代碼語言和開發工具也存在差異，需要開發人員具備不同的技術背景和知識，才能編寫多份代碼來適配不同的終端。這樣做不僅增加了研發人員的開發工作量和代碼維護的難度，還可能導致用戶在不同設備上遇到不一致的用戶體驗，影響產品的質量和用戶滿意度。

為了解決這些問題，多端同構技術應運而生。通過多端同構技術，旅游前端和公共團隊合作多端探索與實踐，根據不同終端的特性進行靈活的適配和定制。這樣可以減少開發成本和維護難度，提高開發效率和代碼的可復用性。同時，多端同構技術還能提供一致的用戶體驗，無論用戶使用哪種設備訪問應用程序，都能獲得相似的界面和功能。

行業現狀 

三端同構

二、多端同構技術選型

在進行多端同構技術選型時，我們需要綜合考慮跨端能力、成本、性能、代碼語言通用性以及現有技術的支持度。這將有助于我們選擇最適合的技術方案，以下是對當前前端主流跨端技術的分析：

Hybrid：使用JavaScript語言，支持快速構建多端應用。由于依賴于Webview容器來運行，所以其用戶體驗和性能受到一定的限制的。這種限制會導致應用的響應速度變慢，頁面加載時間變長等問題。適用于三端業務述求比較高，研發成本又比較低，性能要求不高場景，比如營銷廣告頁。

React Native：使用JavaScript語言開發的React的組件，支持構建App、Web，不支持原生小程序。App上有接近原生應用的性能和用戶體驗。適用于對小程序性能要求不高的場景。

Flutter：使用Dart語言和自帶的渲染引擎，支持范圍同ReactNative。在渲染速度和用戶體驗方面表現比ReactNative更加出色。由于ios平臺規則限制，目前對于熱更新支持并不友好。適用于對App性能要求較高，小程序性能要求不高的場景。

Weex：使用JavaScript語言開發的Vue的組件，支持范圍與性能同ReactNative，社區活躍度不如ReactNative。

Taro：開放式跨端跨框架解決方案，它提供了一套統一的開發語法和組件規范，使開發人員能夠使用一套代碼來開發適配不同平臺的原生應用程序。適用于對于三端述求高，性能要求也高的場景。由于設計之初是面向小程序的，所以規范上對ReactNative研發來說并不友好。

考慮到我們業務對于多端和性能的要求都很高，結合現有團隊技術儲備能力，所以選擇Taro多端同構技術方案。在本文中，我們會重點講述旅游事業部門票活動前端團隊和公共無線技術團隊合作將Taro技術棧與現有技術進行融合后，遇到的問題以及相應的解決方案。

三、Taro如何與現有技術融合

Taro提供的多端同構技術，在不需要考慮與現有技術棧的結合的前提下，是可以直接使用的。針對本身已有一套技術方案情況，就需要考慮如何將Taro與現有的App或Web技術進行融合。

Taro跨端方案是基于靜態編譯的解決方案，最終生成的是將源代碼編譯為目標代碼并打包成可執行的文件。該文件既不能直接集成到業務方（攜程）RN、Web的框架中，也不能直接調用攜程提供的業務組件，如城市、日歷、支付等。因此，開發者需要對Taro進行適配后，才能解決與現有框架融合的問題。

如上圖，Taro的核心原理是在編譯構建時通過注入自定義配置，將原本的小程序組件和API替換為適應不同平臺的組件和API，從而實現多端能力。這樣一來，業務開發中可以使用相同的代碼來適配不同的終端，消除多端開發中的差異。

3.1 融合App（與攜程React Native技術融合）

1）在Taro的配置文件中，注入自定義plugins插件

2）通過Metro打包配置，進行別名替換（原有的taro引用替換成新的RN路徑）

3）抹平Taro的組件和APIs方法

Text組件

頁面跳轉API

按照以上步驟，并且結合ReactNative的腳手架，就可以運行起來。

3.2 融合Web（與攜程NFES技術融合）

Taro同構技術已在Web端的非SSR和SSR模式。SSR模式是以NextJS框架未基礎的，通過提供編譯插件tarojs-plugin-platform-nextjs來支持。但由于這個編譯插件并不支持基于NextJS技術擴展的Web框架或其它Web框架，所以需利用Taro腳手架中開放的編譯能力，在構建時通過babel插件將APIs和組件庫替換為支持服務端同構的版本，同時生成適配當前框架的目錄及項目配置，使得Taro具備轉換為對應Web框架的能力，具體參考如下步驟：

1）同RN，注入自定義H5 plugins插件

2）通過Webpack打包配置，進行別名替換

3）抹平Taro的組件和APIs方法

Text組件

頁面跳轉APIs

4）根據自身框架的調整路由、中間件等項目配置，以下是攜程NFES示例圖

按照以上步驟，并且結合自身Web的腳手架，就可以運行起來。

四、技術實踐

在解決好Taro多端框架與現有技術融合的問題之后，還需要進一步完善組件和API的豐富度，提升應用程序的性能，并解決CSS適配的問題，以實現降低開發成本和提升用戶體驗的目標。

4.1 組件庫與API

1） 組件和API豐富度

Taro多端同構技術的核心方案是通過抹平組件庫和API差異，實現跨端同構，從而使得性能和用戶體驗與獨立開發單一端的應用程序相一致。然而，這種方法的不足之處在于需要開發各端的組件庫和API，以與Taro小程序相對齊，這需要較大的初始成本。

Taro多端設計時已考慮到了降低研發人員首次投入的成本，所以提供對齊Taro小程序的組件庫和API，共計60多個。經過實踐驗證，已滿足大部分常用的業務需求。

除了已提供的組件和API外，仍舊需要開發面向業務的擴展組件和API，例如，彈層、折疊、日歷和城市選擇等組件以及支付、登錄等（如上圖）。大部分組件只需要在官方提供組件上做二次封裝，研發成本不大。

2） 多端組件和API差異性

多端組件和API在不同平臺上可能存在一些差異，無法完全抹平。每個平臺有自己的特性和限制，因此在開發多端應用時，需要對這些差異進行適配和處理。

比如在動畫實現方面就存在不同平臺之間的差異。在ReactNative中，只能使用Animation組件來實現動畫效果，在小程序和Web端是使用CSS樣式來實現動畫效果，為了盡量保持多端一致性，將動畫實現封裝成一個統一的組件，以便在不同平臺上使用。封裝后的動畫組件，在RN端調用的是Animation組件，在小程序和Web端則使用組件內通過Js添加Css樣式來實現動畫。這種方式解決了動畫實現的差異性，使得開發人員可以通過使用統一的接口來調用動畫效果，無需過多關注不同平臺的具體實現細節。

把以上遇到抹平問題，可以歸納為以下3類情況：

4.2 CSS適配 

CSS的跨端支持性是較弱的，受限于ReactNative的平臺限制，所以支持并不友好。

ReactNative不支持CSS樣式的嵌套。只能將樣式拆分成多個獨立的對象，并通過StyleSheet.flatten方法將它們合并成一個對象，從而實現在一個層級節點上設置獨立樣式。目前只能通過差異抹平適配多端方法，犧牲其他端CSS靈活性。

ReactNative不支持CSS中的偽元素選擇器。如::before和::after，因為它沒有DOM元素并且不支持這些選擇器。可以通過添加HTML節點來適應選擇器寫法。

上述的寫法限制了多端開發的效率，但并不影響產品的功能實現。另外一些樣式等問題，大部分可以使用Babel插件（如rn-style-transformer）來抹平。

平臺默認屬性差異 

平臺屬性支持差異

4.3 性能

Taro由于采用的是靜態編譯時生成平臺代碼，所以性能優于動態編譯時生成的方式。在App端性能和原生RN性能相當，但是在Web端會將Dom節點替換為Web Component，而Web Component的渲染能力相對于原生組件較低。因此，如果在轉換過程中，如果存在大量Web Component，會導致頁面渲染的變慢。在電腦型號為MacBook Pro（14英寸，2021年），瀏覽器型號為chrome，瀏覽器版本為113.0.5672.63（正式版本）(arm64)的測試條件下，以taro-view-core（View）組件為例，重復渲染2000次，總耗時大約在123ms。如果換成div重復渲染2000次耗時大約在17ms，大概相差7倍左右，實驗截圖如下：

Web Component耗時：

原生div耗時：

從以上實驗可以得出，不要直接使用 Taro 提供的 View 和 Text 等組件，而是在 Web 原生組件上再包一層具備 Taro 功能的組件。

五、 適用場景和成本

5.1 View層同構

根據交互和產品設計的需要，對于App、H5、小程序交互方式相似度大于70%建議可以采用一套View，差異部分可以用Taro工程提供的文件擴展名方式實現各自的差異部分。

由于 PC 端的交互方式差異較大，因此通常需要編寫兩套View組件，這樣做比較合適。

5.2 多端同構適用場景

多端同構適用于需要在多個平臺上提供相同功能的應用程序，達到提高開發效率和用戶體驗的目的。

不適用于對性能要求較高以及高度依賴平臺的專屬特性的應用程序，比如基于canvas制作的游戲，對于不適用場景且多個平臺都需要支持的話，只能各自實現各自效果。

5.3 多端同構的成本

盡管多端同構技術可以減少開發的成本，但不同平臺之間仍存在樣式和API的差異，需要研發人員進行適配和補充。實際各端的研發成本對比可參考下表：

隨著開發經驗的積累和組件的豐富化，研發和測試成本也會進一步降低。

學習成本：多端同構開發需要研發人員具備跨端開發的能力和經驗，需要了解各個平臺的特性和差異，同時還需要關注代碼的性能、可維護性和可擴展性等方面。我們可以通過多種培訓和分享來提高他們的能力和技能。

測試成本：在多端同構的開發模式下，如果不慎改錯一端會影響到所有端，所以測試成本會增加。測試范圍更廣，測試時間也會更長，因此測試成本也會相應地增加。另外，由于不同平臺之間的差異，測試人員需要具備跨平臺測試的能力，這也會對測試人員的研發能力提出更高的要求。為了解決這些問題，可以普及 UT（單元測試）和 AT（自動化測試），這可以降低測試成本，提高測試效率。

生產穩定性：因為多端同構技術采用的是統一的代碼邏輯和組件封裝，一旦出現問題，多個平臺都會受到影響。因此，在開發過程中需要進行嚴謹的測試和質量控制，以確保代碼的穩定性和可靠性。

六、總結與展望

本文介紹的是通過使用Taro實現多端同構，在跨多平臺業務場景中降低研發成本，提升用戶體驗。通過使用同一開發語言和代碼框架，實現在不同端上復用代碼，達到統一業務邏輯的目的。

可以預見在不久的將來，無論是基于業務需求還是技術實踐與創新，都將出現更多的解決方案，使得多端開發之路變得更加平坦。同時，這套方案將成為公司主推的多端框架。