不久前我们刚聊过了 《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 的适配版本

正在适配的 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 适配鸿蒙呢？我还是很好奇有多少勇士？