小編精選 - 技術文章翻譯 · 03月29日

React Native 鸿蒙 2026 路線發佈，為什麼它的適配成本那麼高？

React Native 鴻蒙 2026 路線發布，為什麼它的適配成本那麼高？

不久前我們剛聊過了 [《Flutter 鴻蒙 2026 路線發布》](https://juejin.cn/post/7617667131379613738)，今天我們要聊的是 React Native 的 RNOH（React Native OpenHarmony）社群版本。

RNOH（React Native OpenHarmony）其實開源得比較晚，主要是在適配初期它需要維護的工作量相對比 Flutter 多很多，因為 React Native 是一個 OEM 原生元件的實作，所以它在適配上需要做更多的相容性工作，這也是為什麼一直以來 RNOH 的適配成本會比較高的原因。

而 RNOH 就是這樣一套 HarmonyOS 的原生平台適配層，它在 RN 官方 C++ 核心之上，構建了一個由 ArkTS（ETS）+ C/C++（NAPI/C-API） 組成的雙層適配體系。

為了保證 RNOH 社群與 React Native 上游社群盡可能一致的開發體驗與 API 能力，RNOH 需要：

對齊上游版本節奏：在合理的節奏下跟進上游的主要 Release
聚焦關鍵版本：優先適配對業務與生態影響最大的幾個版本，而不是「全版本覆蓋」
平衡穩定與創新：在保證現有業務穩定性的前提下，引入上游的特性更新與效能優化

實際上，RNOH 一開始直接改為 ArkTS 的實作帶來不少效能瓶頸問題，也是後續完成 C API 路線後才成為一個相對可用的版本：

而對於 React Native 官方在 2026 年上游規劃大概有的 6 個 release 版本，RNOH 社群計畫聚焦適配其中 4 個版本，透過季度節奏逐步推進：

Q1：完成並發布 0.82.x 的適配版本（進行中）
Q2：發布 0.84.x 的適配版本
Q3：發布 0.86.x 的適配版本
Q4：發布 0.88.x 的適配版本

上游版本時間表：

版本	上游分支截止時間	上游發布時間	RNOH 支持策略	RNOH 預計支持時間
0.89.x	2026-11-03	2026-12-07	NA	-
0.88.x	2026-09-07	2026-10-12	適配	2026 Q4
0.87.x	2026-07-06	2026-08-10	NA	-
0.86.x	2026-05-04	2026-06-08	適配	2026 Q3
0.85.x	2026-03-02	2026-04-06	NA	-
0.84.x	2026-01-05	2026-02-09	適配	2026 Q2
0.83.x	2025-11-03	2025-12-08	NA	-
0.82.x	2025-09-01	2025-10-06	適配中	2026 Q1

正在適配的 0.82 屬於 RN 裡的 New Architecture Only 版本，而下一個 0.84 版本是 Hermes V1 預設版本，所以都是比較大的變動。

而對於 RNOH 本身的能力增強，當前 RNOH 已規劃的能力增強包括但不限於：

核心框架能力
- 與上游 React Native 相相容的核心模組（View、Text、Image、ScrollView 等）
- JavaScript/TypeScript 執行環境與基礎橋接能力的對齊
效能與穩定性
- 啟動速度、記憶體佔用、渲染效能等關鍵指標的基線測量與優化，持續優化框架效能
- 針對典型業務場景的壓力測試與長期運行穩定性驗證
問題定位（DFX）能力
- 支援 CPPCrash 情境下取得 JS 業務堆疊（Hermes）
- 支援凍屏情境下取得 JS 業務堆疊
- 支援匯出 JSVM 記憶體快照，方便分析 RN 記憶體問題
多裝置開發能力
- 支援 RN 框架接入平行視界功能
- 提供安全區域佈局元件，支援以安全區方式實現避讓與沉浸效果

近期重點里程碑：

0.82.x（Q1）
- 狀態：適配中
- 目標：完成對上游 0.82.x 的基礎能力對齊與核心功能驗證，為後續版本適配打好基礎
0.84.x（Q2）
- 狀態：方案分析中
- 目標：完成對上游 0.84.x 的功能適配和關鍵場景驗證，計畫在 Q2 內發布社群版本
0.86.x（Q3）
- 狀態：規劃中
- 目標：跟進上游 0.86.x 的新特性與變更，保證與 HarmonyOS 生態的相容性與效能表現
0.88.x（Q4）
- 狀態：規劃中
- 目標：對齊上游 0.88.x，完成全年第四個適配版本，確保 RNOH 社群版本在 2026 年保持與上游同步

當然，做過 RN 的都知道，RN 本身的版本升級成本就比較高，而 RNOH 又是一套適配成本相對較高的存在，所以存在的風險與依賴還是不少：

上游版本節奏變化
- 上游 React Native 可能調整版本規劃或引入較大變更，導致現有路線圖需要同步調整
資源與人力投入不確定
- 核心維護者與貢獻者人力波動，可能影響部分版本的適配深度與發布時間
平台特性差異
- OpenHarmony 與上游預設平台（Android/iOS）在系統能力、權限模型、UI 渲染機制等方面存在差異，可能導致：
- 部分特性無法完全對齊
- 個別第三方套件需要額外適配或功能降級
生態套件相容性
- 社群常用第三方套件更新較快，版本組合複雜，可能出現：
- 某些套件尚未支援當前 React Native 目標版本
- 某些套件未對 OpenHarmony 進行適配或測試

最後，有關第三方套件方面，目前大致情況為：

計畫適配的第三方套件：368 個
已適配：205 個
不需要適配：112 個
還沒適配 / 開發中：51 個
涉及新框架且還需要適配：9 個（也算在未適配中）

從已知訊息來看，目前 RNOH 的適配進度還能跟上，但由於 2026 年幾個大版本變動較大，適配的風險與成本也有所提高，因此整體進度會存在一定風險；另外第三方套件社群跟進相對 Flutter 節奏也弱一些。不過回頭想想，很多專案用 RN 常常是一個版本用到底，除非遇到上架或相容性問題，否則也會儘量不升級，畢竟就算有 AI，升級也會很耗 Token。

那麼，你有用過 RNOH 去適配鴻蒙嗎？我還是很好奇有多少勇士？

原文出處：https://juejin.cn/post/7621107967534301203