作者：京東零售 朱天健

基于 Taro 打造的京東鴻蒙 APP 已跟隨鴻蒙 Next 系統公測，本系列文章將深入解析 Taro 如何實現使用 React 開發高性能鴻蒙應用的技術內幕

背景

在鴻蒙生態系統中，雖然原生應用通常基于 ArkTS 實現，但在實際研發過程中發現，使用 C++ 可以顯著提升應用框架和業務的性能表現。隨著鴻蒙系統的不斷迭代升級，不同語言環境間的協作已成為不可或缺的開發范式，共同構建了更豐富的研發生態。

Taro 通過接入鴻蒙端的 C-API 相關能力，將組件、樣式布局等運行時邏輯下沉到 C++ 層，從而極大地提升了頁面的渲染性能。

在這樣的背景下，構建一套在 C++、ArkTS 等不同語言環境之間高效通信的事件系統，成為了一個極具價值，對于 Taro 來說也是必修的課題。

多語言環境的事件處理機制

在 Harmony 端的適配過程中，事件系統扮演著雙重角色：不僅驅動應用、頁面和各模塊組件的生命周期，還因為 ArkTS 和業務代碼（JS）之間存在人為設定的界限，需要事件作為橋梁，以便 JS 能夠調用 ArkTS 的原生能力。

跨語言環境事件驅動架構的設計考量

在設計跨語言環境的事件驅動架構時，需要同時考慮 ArkTS、JS 和 C++ 等多個語言環境的限制和運行時差異。如何實現事件在這些環境之間的有序傳遞，以驅動頁面和組件的生命周期，是事件系統設計的重要考量。

通過 C++ 實現事件的底層邏輯，構建一個高效的事件管理系統，可以有效避免冗余接口的設計。同時，與鴻蒙的 C-API 支持的事件系統對接，將各類事件分發到不同語言環境，確保跨語言環境的事件分發與處理的有序性、高效性。

回顧 Taro 開始適配鴻蒙至今，事件系統也隨之經歷了從簡單到完善的演進歷程。從最初在 ArkTS 方案中的基礎實現，到隨著 Taro for Harmony 方案迭代發展，事件系統的設計也面臨 ArkTS 帶來的一些限制。

在 ArkTS 語言環境中事件架構的局限性

基于 ArkTS 語言環境實現的事件架構，在性能方面存在較大局限性。特別是在事件冒泡過程中，性能較差的語法，和回調邏輯可能會導致性能嚴重劣化，甚至阻塞主線程。這不僅會影響應用的響應速度，更有甚者可能對整體用戶體驗產生負面影響。

為了解決這些問題，提升性能以保證用戶體驗成為關鍵目標。通過將事件處理邏輯下沉到 C++ 層，并置于后臺線程執行等優化手段。能夠有效提高代碼執行效率，同時避免邏輯阻塞主線程導致的延遲響應，以提升應用的流暢性，提供更佳的用戶體驗。

構建多語言環境下的事件系統

在構建多語言環境下的事件系統時，首要考慮各種類型的事件，比如：鴻蒙提供的組件通用事件、手勢等。事件系統需要有效地管理這些不同的事件來源，并根據框架和用戶的監聽行為有序進行事件的分發。

在這些事件類型中，大致可以分為普通事件和節點事件兩類。前者涵蓋系統層面和應用、組件等生命周期的變化，通常由系統或應用狀態的改變觸發，主要由事件中心（eventCenter）來處理；節點事件則與 DOM Tree 緊密相關，這些事件通常需要快速響應，以確保用戶界面的流暢性和交互的即時性。

事件中心（eventCenter）的實現

作為 Taro 運行時中的基礎模塊，事件中心專注于處理系統事件和生命周期。它允許框架和應用開發者在后臺線程注冊事件隊列，并異步分發事件，從而有效減輕主線程的負擔。事件中心能夠快速響應各種事件，同時具備健壯的錯誤處理機制，幫助開發者快速定位和解決事件回調中的問題，從而提升開發效率和系統穩定性。

事件監聽與分發

開發者可以在 C++ 和 ArkTS 等多種語言環境中創建事件監聽器，并將相應的回調函數添加到事件隊列中。這一機制允許開發者在不同的編程語言中靈活地定義和處理事件響應邏輯。

當事件觸發時，會根據不同語言環境的運行時差異，將事件參數轉換為對應的格式。這種參數轉換確保了各語言環境能夠正確理解并處理事件及包含的數據，無論是簡單的數據類型還是復雜的對象結構，都能在不同語言之間無縫傳遞。

事件隊列會根據監聽器的類型，按照預定義的順序，將事件分發到相應的語言環境中。這樣一來，每個監聽器都能在其所屬的環境中高效地執行對應的回調函數。通過這種方式，不僅可以實現了跨語言的事件處理，優化事件的分發效率，并確保應用在響應用戶交互時保持高性能和高穩定性。

需要注意的是，受限于底層限制，在 ArkTS 環境中注冊的事件需要回到主線程執行，同時在鴻蒙端不支持 Symbol 類型的事件。

節點事件處理（domEvent）

在 HTML 中，節點事件處理流程會如下圖所示，事件從根節點開始向下傳播至目標節點，觸發后再從目標節點順著節點樹向上冒泡。在鴻蒙端實現中，Taro 基于這一事件傳播流程，為開發者提供一致的事件處理機制。

事件類型

在 Taro 框架中，節點主要處理三種類型的事件：鴻蒙事件、鴻蒙手勢事件和自定義事件。這些事件都是從TaroElement上進行監聽和觸發的。根據事件的類型不同，節點會從相應的事件源設置Receiver（事件接收器）來進行監聽并處理回調邏輯。

鴻蒙事件和鴻蒙手勢事件分別通過RenderNode注冊到Receiver，確保事件能夠正確地傳遞和觸發。而自定義事件則根據節點實現或用戶自行觸發，以滿足各種不同類型的交互響應。

事件傳播

當TaroElement上的事件被觸發后，事件會沿著節點樹向上傳播。每個節點依次接收到事件，并執行相應的回調。執行完回調后，會檢查開發者是否阻止冒泡，以決定是否繼續向上傳播。事件從目標節點開始，逐級往上直到根節點或者冒泡被阻止。

這允許開發者在事件傳播過程中，通過任意節點處理或攔截事件來調整業務邏輯實現，以更靈活的方式在特定節點上執行邏輯，或通過阻止冒泡避免對上層節點的影響。這樣的設計對于前端開發者來說，更加熟悉、直觀。

鴻蒙系統的底層節點事件也有自己的傳播邏輯，但由于其機制與 ArkNode 節點樹差異，為避免其事件干擾，需要阻止其冒泡行為并接管其傳播流程，以確保事件傳播與節點樹正確關聯。

事件回調

由于節點事件也需要回調 JS 環境中執行，根據事件類型的不同，按照 Web 標準將相應的節點、值和方法如 target、stopPropagation、value 等等掛載到事件對象上。通過執行當前回調的序列化方法，確保事件在不同語言環境傳遞時，可以保證其回調對象能力一致、參數完整。

在 C++ 中，許多組件依賴于事件機制來實現功能。例如，通過鴻蒙事件更新組件屬性，還有各個組件節點間的事件傳遞等。這些組件利用事件機制來確保數據變化能夠及時反映，并且用戶交互能夠順利傳遞到系統的各個部分。

總結與展望

在多語言環境中，確保事件在不同語言環境傳遞時的一致性尤為重要，各個模塊以及應用內不同頁面或組件通過事件解耦驅動來提升可維護性。當前的解決方案有效提升了系統的響應速度和模塊間的協作能力。

當下方案實現中仍然存在一些問題，比如早期通過事件繞過 ArkTS 與 JS 之間相互調用限制等場景，可以通過 TurboModule 來提供更加直接的調用方案。

未來，在 Taro for Harmony 場景下，各語言模塊的協同將進一步增強。基于事件系統的設計，可以有效地解耦模塊間邏輯，實現更靈活的組合。

審核編輯 黃宇