React Native for OpenHarmony（RNOH）0.84.1 Release 版本现已正式上线。

本次版本持续跟进 React Native 源社区迭代步伐，在默认 JavaScript 引擎、框架架构精简、性能与内存治理、负载控制、多设备适配以及 DFX 调试排障能力上完成全方位升级，为鸿蒙开发者提供一套更高效、更稳定、更贴近原生体验的跨平台开发方案。

一、RNOH 0.84 全新发布：紧跟源社区，版本同步持续提速

跨平台框架的核心价值，不仅是实现“一套代码、多端运行”，更要保障开发者能够及时享用社区新特性，在不同终端获得一致、可靠的开发体验。

RNOH 持续跟进 React Native 上游关键版本，从 0.72、0.77、0.82 到 0.84，版本适配周期持续缩短。本次发布的 RNOH 0.84.1 完全对齐 React Native 0.84.1，同步升级 React 至 19.2.3 版本。

上游 React Native 0.84 将 Hermes V1 设为默认 JavaScript 引擎，持续清理老旧架构代码。RNOH 在此基础上深度完成鸿蒙平台专属适配，开发者可沿用熟悉的 React Native 技术栈，高效产出鸿蒙应用。

2026 版本路线图：聚焦四个关键版本，按季度稳步迭代

React Native 源社区发布节奏较快，2026 年计划推出约 6 个 Release 版本。RNOH 不盲目跟进每一个上游小版本，兼顾上游能力同步、鸿蒙平台适配深度和版本质量，筛选 4 个高价值关键版本，按照季度节奏完成适配落地。

截至目前，RNOH 已完成 0.72、0.77 和 0.82 三个关键版本的适配， 2026 年正式进入季度化跟进关键版本的新阶段。0.84 的发布不仅带来全新引擎与架构能力，也标志 RNOH 从阶段性适配，转向常态化、连续性版本演进。

版本策略带来三个核心价值：

▪ 迭代节奏更稳定：以 Q1 至 Q4 依次落地 0.82、0.84、0.86 和 0.88 版本，节奏可预期。

▪ 能力聚焦高价值：优先适配对框架架构、性能、开发体验和生态兼容性影响较大的版本。

▪ 开发者预期更清晰：开发团队可结合路线图提前规划版本升级、三方库适配和业务验证工作。

提示：以上为社区规划时间，会随上游发布节奏、版本质量和实际适配进展动态调整，最终以 RNOH 社区官方公告为准。

二、性能、负载与内存全面优化，多设备体验再升级

RNOH 0.84 不只是简单版本号更新。围绕 JavaScript 执行引擎、底层框架架构完成深度演进，同时从负载管控、内存治理、多终端适配等维度释放鸿蒙系统平台能力，全方位提升应用运行表现。

1. Hermes V1 设为默认引擎：JavaScript 执行与内存表现双双提升

在 React Native 0.82 中，Hermes V1 仅作为实验特性，需要开发者手动开启。React Native 0.84 将 Hermes V1 设为默认 JavaScript 引擎，升级版本后无需额外迁移配置，即可获得新一代引擎能力。

Hermes V1 从编译器和虚拟机两大模块深度优化：

▪ 编译器优化：改进 JavaScript 代码生成与执行效率，为复杂业务逻辑和高频交互提供更高效的运行基础。

▪ 虚拟机优化：持续完善运行时执行路径，提高 JavaScript 代码执行效率。

▪ 内存优化：改进运行时内存使用，为降低应用内存压力提供支撑。

▪ 开箱即用：开发者无需再按实验特性手动开启，版本升级后即可使用 Hermes V1。

对开发者， Hermes V1 正式从实验特性转为默认基础能力；对终端用户，页面响应速度、复杂交互流畅度和长时间运行稳定性获得底层性能支撑。

2. 持续清理旧架构代码：主路径更清晰，框架更加轻量

React Native 0.82 已将新架构设为唯一运行架构，Fabric 与 TurboModule 成为框架的核心渲染和原生通信机制。0.84 在此基础上，持续清理遗留的旧架构类和兼容代码，推动框架实现能力收敛。

带来的价值：

▪ 架构链路更清晰：去除 Bridge 时代遗留逻辑和冗余分支，新架构成为标准主路径。

▪ 降低维护成本：消除新旧架构长期并存产生的维护成本，减少开发者面对兼容分支时的理解负担。

▪ 构建与包体积优化：源社区在 iOS 默认编译配置中移除旧架构代码，有助于减少构建内容和应用体积（实际收益取决于工程自身依赖情况）。

这项升级并非替换全新架构，而是在 0.82“新架构唯一化”的基础上继续做减法，让 Fabric、TurboModule 与 JSI 构成的核心路径更加纯粹，为后续性能演进和平台优化释放空间。

3. 后台防空跑：页面不可见时，自动停止 JS 动画无效消耗

在多 RNInstance 场景中，不同业务页面可能由不同的 RNInstance 承载。当用户从 RNInstance1 对应的页面切换到 RNInstance2 对应的页面后，RNInstance1 已经进入后台、页面不再可见，但其中的 JS 动画仍可能继续执行。动画回调和状态更新在后台持续触发，不会产生用户可见的画面，却会形成无效的 CPU 与线程负载。

针对这一问题，RNOH 0.84 新增后台防空跑机制：跨 RNInstance 页面切换时，框架感知页面前后台状态，自动暂停后台页面 JS 动画，前台页面保持正常运行：

▪ 避免后台空跑：不可见页面不再持续执行无展示价值的 JS 动画。

▪ 降低无效负载：减少后台动画产生的 JS 回调、状态更新和相关线程开销。

▪ 保障前台体验：系统资源向当前可见页面倾斜，提升前台交互流畅度。

▪ 适配多实例架构：以 RNInstance 对应页面生命周期作为管控边界，隔离不同实例资源消耗。

从用户视角看，页面切换交互逻辑保持不变；后台页面及时释放无效算力，解决 “页面看不见，动画一直在跑” 的资源浪费问题。

4. 内存治理优化：应用退后台自动触发虚拟机 GC

应用在前台运行时，业务逻辑、页面状态和交互过程会不断创建 JavaScript 对象，不断推高 JS 堆内存。当应用切换到后台后，部分对象已经失去引用，但不会被及时回收，仍可能继续占用内存，推高后台内存压力。

RNOH 0.84 新增生命周期联动回收策略：RN 应用从前台切换至后台时，主动触发虚拟机 GC 垃圾回收，清理不再被引用的 JS 对象，降低 JS 堆内存占用。

▪ 感知生命周期：捕捉应用退后台时机执行回收逻辑。

▪ 主动触发 GC：通知 JavaScript 虚拟机执行垃圾回收，清理无效对象。

▪ 降低 JS 堆内存：利用后台空闲时机完成内存整理，不干扰前台交互。

▪ 减轻后台内存压力：降低应用后台内存占用，改善整机内存调度表现。

用户操作无感知，借助生命周期节点及时完成内存整理，避免无用对象长期驻留内存。

5. 多设备体验增强：RN 平行视界，纯 JS 路由快速适配单/双栏

手机通常采用单页面逐级跳转：用户从列表进入详情后，列表页会被详情页覆盖。在平板等大屏设备上，如果仍沿用相同的单栏导航方式，宽阔的横向空间无法被充分利用，用户也需要在列表和详情之间反复跳转。

RN 平行视界通过三方库提供能力，核心改造集中在 JavaScript 路由层。开发者无需重新实现一套原生路由，只需在现有 RN 页面和路由关系基础上进行纯  JS 改造，即可根据设备形态组织不同的页面布局：手机保持熟悉的单栏导航，平板横屏场景则将具有关联关系的主页面和从页面并行展示。

以常见的“列表页—详情页”为例：

▪ 手机单栏：点击列表项后进入详情页，沿用原有的页面跳转和返回体验。

▪ 平板双栏：列表页保留在左侧，详情页展示在右侧；用户切换列表项时，可以直接在同一屏幕查看对应内容。

▪ 路由关系复用：三方库在 JS 层组织主从页面关系，业务页面仍由 React Native 组件构建，减少平台侧重复开发。

▪ 按设备形态适配：同一套路由模型可以根据可用显示空间输出单栏或双栏布局，让手机和平板获得更合适的内容呈现方式。

对开发者而言，平行视界将多设备适配的主要工作收敛在熟悉的 JavaScript 技术栈中，通过三方库和路由改造降低接入成本；对用户而言，列表与详情、消息与会话、目录与正文等关联页面可以同屏浏览，减少页面往返，带来更连续、更高效的大屏体验。

三、DFX 能力提升：让问题发现与定位更高效

随着业务复杂度提升，开发者不仅需要关注应用是否能够正常运行，还需要快速回答“网络请求慢在哪里”“哪段 JavaScript 阻塞了交互”“JS 堆内存为什么持续增长”等问题。RNOH 0.84 从日常调试和内存异常现场保留两个方向增强 DFX 能力，帮助开发者更快发现问题、还原现场并定位根因。

1. DevTools 能力增强：网络与性能问题集中分析

RNOH 0.84 进一步对齐新版 React Native DevTools 能力。开发者可以在统一的调试界面中查看网络请求和性能时间线，减少在多个调试入口之间切换的成本。

▪ twork 面板：查看应用通过 fetch()、XMLHttpRequest 和图片加载等方式发起的网络请求，并分析请求时序、请求头、响应头和响应内容等信息。

▪ Performance 面板：录制应用运行过程中的性能数据，在同一条时间线上分析 JavaScript 执行、React 性能轨迹、网络事件和自定义 User Timing。

▪ Web Performance APIs：通过 performance.mark()、performance.measure() 和 PerformanceObserver 等接口为关键业务阶段打点，将应用自定义指标与 DevTools 性能时间线结合分析。

▪ 调试入口收敛：原 Element Inspector 中的旧版 Perf 和 Network 页签不再作为独立入口，相关能力统一由 React Native DevTools 提供。

通过这些能力，开发者可以从一次用户操作出发，串联观察网络请求、JavaScript 长任务和 React 渲染过程，更高效地分析页面加载慢、交互响应延迟和业务代码执行耗时等问题。

2. JSVM 内存快照：主动导出与水线自动触发

JS 堆内存问题往往具有现场性：开发环境中不一定能够稳定复现，等到内存持续增长或逼近风险区间时，再手动连接调试工具可能已经错过关键现场。针对这一痛点，RNOH 对接 JSVM 接口，为开发者提供可配置的内存快照能力。

主动导出内存快照

RNOH 支持通过配置主动调用 JSVM 接口，导出以下两种格式的内存快照：

▪ .heapsnapshot 格式：用于记录和分析 JS 堆中的对象、引用关系及内存占用情况。

▪ raw heap 格式：导出 JSVM 原始堆内存快照，为进一步分析和问题定位保留现场数据。

▪ 开发者可以在测试流程、特定业务阶段或发现内存异常时主动触发快照，将不同时间点的 JS 堆状态保存下来，为对象增长、异常持有和疑似泄漏分析提供依据。

JS 堆内存水线自动导出

除主动导出外，RNOH 还支持配置 JSVM 的内存水线。当 JS 堆内存达到预设水线时，框架自动触发内存快照导出，无需等待开发者手动操作。

这一机制将“发现内存异常”和“保留异常现场”连接起来：

▪ 提前设置水线：根据应用规模和测试目标配置 JS 堆内存水线。

▪ 运行时持续监测：在业务正常运行过程中关注 JS 堆内存变化。

▪ 到达水线自动导出：达到配置值时立即保存内存快照，降低关键现场丢失的概率

▪ 支持后续对比分析：结合主动快照和水线快照，对比不同阶段的堆对象与引用变化，辅助定位异常增长来源。

通过主动导出与水线自动触发两种方式，开发者既可以按测试计划采集 JS 堆内存数据，也可以在异常发生时自动保留现场，让偶发、渐进式的 JS 内存问题更容易被捕获和分析。

即刻体验

RNOH 0.84.1通过同步 React Native 0.84.1 与 React 19.2.3，将Hermes V1 默认引擎和进一步精简的新架构带到鸿蒙平台，并继续围绕性能、负载、内存、多设备与DFX能力演进。

开发者可通过以下入口获取框架、配套生态与升级资料：

▪ 框架源码：访问 RNOH 框架仓库，了解最新代码、版本发布与社区进展。

三方库配套：访问 RNOH 三方库适配与使用文档，查看常用三方库的鸿蒙适配情况和接入方式。

npm 包：通过 @react-native-oh/react-native-harmony 获取 RNOH npm 发布包。

版本升级：参考 从 0.82.x 升级到 0.84.x 指南，完成依赖、工程配置与兼容性调整。相关指南如下图：

欢迎开发者体验 RNOH 0.84.1，并参与社区共建，共同推动 React Native 在鸿蒙生态持续演进。