不久前我们刚聊过了 《Flutter 鸿蒙 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 适配鸿蒙呢？我还是很好奇有多少勇士？