React Native 鸿蒙 2026 路线发布，为什么它的适配成本那么高？

不久前我们刚聊过了 ，今天我们要聊的是 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 as Default 版本 ，所以都是比较大变动的版本更新。

而对于 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 ，升级 AI 也是很费 Token 的。

那么，你用过 RNOH 适配鸿蒙呢？我还是很好奇有多少勇士？