不久前我们刚聊过了 ，今天我们要聊的是 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 适配鸿蒙呢？我还是很好奇有多少勇士？
热门跟贴