沈阳制作公司网站,php网站开发答案,品牌网站建设哪里有,室内设计联盟官网入口网页关于 React Native 的 New Architecture 概念#xff0c;最早应该是从 2018 年 RN 团队决定重写大量底层实现开始#xff0c;因为那时候 React Native 面临各种结构问题和性能瓶颈#xff0c;最终迫使 RN 团队开始进行重构。
而从 React Native 0.68 开始#xff0c;New A…关于 React Native 的 New Architecture 概念最早应该是从 2018 年 RN 团队决定重写大量底层实现开始因为那时候 React Native 面临各种结构问题和性能瓶颈最终迫使 RN 团队开始进行重构。
而从 React Native 0.68 开始New Architecture 被作为实验性选择加入项目之后 2022 年 RN 团队正式发布了 JSI、Fabric、 Turbo Modules、Codegen 的 New Architecture同时发布的还有 Hermes JS 引擎在同年 React Native 0.70 版本发布的时候Hermes 成为了 RN 的默认 Engine 。
但是由于新架构的重构导致了大量的 break change 所以在此之后 RN 团队开始努力推进和解决各种社区新框架问题而直到 2024 年新框架模式在 React Native 已经过大规模验证并为 Meta 的生产应用提供了大量支持所以从 0.76 开始整套 New Architecture 实现将成为 React Native 的默认配置。 虽然这么多年过去 RN 还是没有发布 1.0 这个梗依旧但是 RN 确确实实已经“脱胎换骨”可以说 0.7x 和 0.6x 几乎都快不是一个项目。 正如 RN 团队所说2024 年是向所有 React Native 用户推出新架构的一年事实上这也证明了一个项目只要发展时间够长用户基数够大最终都会通过重新自研某些能力来解决问题RN 是这样Flutter 也是这样。
前情提要
在 RN 上最早 New Architecture 主要围绕四个核心和一个引擎来展开JSIJavaScript Interface、Fabric 、Turbo Modules、CodeGen 和 Hermes Engine这里我们简单回顾一下他们的作用。
JSI
JSI 属于 JavaScript 接口它是一个统一的轻量级通用 API理论上适用于任何 JavaScript 虚拟机并且它采用 C 实现让 JS 可以使用它直接执行或者调用 Native 代码所以它的作用就是让 JavaScript 接口与 Engine 分离。 所以 JSI 的出现让 RN 可以切换 JS 引擎比如 Chakra、v8、Hermes 同时允许 JS 和 Native 线程之间的同步相互执行 JSI 作为接口它允许 JS 保存对 C 对象的引用反之亦然例如使用内存引用时可以直接调用方法而无需序列化成本例如在实时处理帧数据时JSI 可以轻松处理更大的帧速率数据所以 JSI 将最大限度地减少 JS 和原生内存之间的开销。
Fabric
简单理解它就是 RN 在 UI 层的重新实现类似取代了原本的 UI Manager主要是为了以充分利用 React 的并发渲染能力特别是现在的新架构支持 React 18 及更高版本中提供的并发渲染功能。
而得益于前面的 JSI JS 可以直接调用 Native 方法其实就包括了 UI 方法所以 JS 和 UI 线程可以同步执行从而提高列表、跳转、手势处理等的性能。 在此之前JS 和 UI 线程不同步因此在某些情况下 App 可能会因为丢帧而显得卡顿 Turbo Modules
在之前的架构中 JS 使用的所有 Native Modules例如蓝牙、地理位置、文件存储等都必须在应用打开之前进行初始化这意味着即使用户不需要某些模块但是它仍然必须在启动时进行初始化。
Turbo Modules 基本上是对这些旧的 Native 模块的增强现在 JS 将能够持有这些模块的引用所以 JS 代码可以仅在需要时才加载对应模块这样可以将显着缩短 RN 应用的启动时间。
Codegen
Codegen 主要是用于保证 JS 代码和 C 的 JSI 可以正常通信的静态类型检查器通过使用类型化的 JS 作为参考来源CodeGen 将定义可以被 Turbo 模块和 Fabric 使用的接口另外 Codegen 会在构建时生成 Native 代码减少运行时的开支。
Hermes
Hermes 是 RN 研发的全新 JS 引擎而之所以有 Hermes 是因为它是专为资源受限的设备而设计的存在并针对启动、应用大小和内存消耗进行了相应优化Hermes 和其他 JS 引擎之间的一个关键区别是它能够提前将 JavaScript 源代码编译为字节码。
Hermes 支持提前执行编译的能力意味着启用了 Hermes 的 React Native 应用会带有预编译的优化字节码而不是纯 JavaScript 源代码。
Hermes 的存在大大减少了为用户启动的时间官方曾表示启用 Hermes 通常会将产品的 TTI 指标缩短近一半。
此外 Hermes 还优化了 GC 实现 采用了 Hades 的全新并发 GC在 64 位设备上Hades 在 p99.9 处仅暂停 48 毫秒比默认的 GenGC 快 34 倍这也为 React Fiber 启用并发渲染通过将渲染工作拆分为块来避免调度长 JavaScript 任务提供了良好基础支持。
Interop Layers
所以可以看到基于 Hermes 引擎的加持配合 JSI、Fabric 、Turbo Modules、CodeGen 的实现 React Native 像是换了「五脏六腑」但是这也给它的老旧适配带来了挑战。
随着新架构的推出社区适配成了它推进的最大阻力这也是为什么 New Architecture 在 2022 发布之后“落地放缓”的原因而对于 RN 团队给出的答案是Interop Layers 。 我的项目也基本停滞在 New Architecture 之前。 在互操作层( Interop Layers )出现之前当你尝试在新架构上使用 Legacy Component 时你会看到如下内容 而 React Native 在 0.72 添加了互操作层(Interop Layers)它的作用是让老旧项目「无需调整」即可运行到 New Architecture而 React Native 0.74 默认启用 Interop layer 在 New Architecture 里会重用旧版的原生组件它属于一个平台层允许开发者将旧组件注册到 New RendererFabric里并将旧函数调用例如特定属性的 setter映射到 New Renderer 中的等效 updateProps 函数。 对于新架构兼容升级最大的成本就是将原生组件迁移到 New Renderer 因为需要大量时间并且通常无法自动化因为范式完全不同所以现在 Interop layer 实际上是作为一个 wrapper 存在从而允许旧组件与 New Renderer 一起使用例如 在后台每当 prop 更新或发送命令时它都会转发到 New Renderer 的 UIManager UIManager 会将消息发送到 wrapper wrapper 会“小心地”将其转换为传统架构可以理解的格式并让传统组件处理它然后它将消息反向传递到 JS从而更新 UI。 现在互操作层这个 wrapper 会帮助大家解决大部分问题虽然它并不是完全兼容而对于 RN 团队的目标来说它也不是为了 100% 兼容而存在它更多是为了过渡适配而存在可以看到现在在官方统计里1465 个 package 里已经有 851 支持新架构所以 0.76 default 也可以说归功于 Interop Layers 。 Bridgeless Mode
Bridgeless Mode 是在 0.73 被引入然后 React Native 0.74 默认启用这也新架构的一个关键功能在新架构之前React Native 需要桥(bridge)用于 JS 和原生之间进行通信。 桥相当于是一个消息队列会被用于渲染视图、调用本机可调用对象或注册事件处理程序等指令而桥的存在限制了 React Native 的异步设计、消息批处理和序列化成本。 New Architecture 的很大一部分工作是消除 React Native 对 bridge 的依赖例如
TurboModules 将本地调用移出了桥接Fabric 将组件渲染从 Bridge 移除
而 Bridgeless Mode 下会将剩下的 React Native 运行时内容如错误处理、全局事件发射器、计时器等从桥接中移出并且不再初始化桥接也就是 React Native 0.74 将不在有桥接调用的存在。 而由于完全移除了 bridge所以这个 break change 同样需要 Interop Layers 这个 Wrapper 来充当旧版的兼容实现。 通过 Interop Layers 大多数注册到 React Native 的遗留模块将受到新的原生模块系统 TurboModules 的支持。
此外Bridgeless Mode 使用 Static ViewConfig 优化了组件渲染ViewConfig 会告诉 React 原生组件支持哪些 props 和事件。 以前 ViewConfig 是在运行时通过分析原生组件的 ViewManager 生成的而现在使用 Static ViewConfigsRN 可以通过分析原生组件的 Flow 或 TypeScript spec 文件将这项工作转移到构建时完成如果原生组件没有 spec 文件那么 Bridgeless 将回退到运行时 ViewConfig 生成。 Suspense Transitions
一直以来React Native 会执行与 React for web 相同的 React 框架代码但是 React Native 需要渲染为通用平台视图Native 视图而不是 DOM 节点这在新架构之前让 RN 很难发挥出 React 的“全力”。
而随着 Fabric 的实现RN 渲染到 Native 视图是通过 Fabric Renderer 实现Fabric 允许 React 与每个平台通信并管理其 Native 视图实例核心原则是在 C 中统一更多的渲染逻辑提高与 Native 平台的可互操作能力。
所以新框架下“同步调用”的能力让渲染器能够同步测量和渲染 React 这也让 React 本身的一些概念可以被运用到 RN 上例如
与 React Suspense 集成可以在 React 应用中更直观地设计数据获取在 React Native 上启用 React 并发功能如 Transitions 这也是新框架的优势新架构支持 React 18 及更高版本中提供的并发渲染和功能现在开发者可以在 React Native 代码中使用 Suspense 等功能来获取数据从而进一步让 Web 和原生 React 开发之间的代码库和概念保持一致。 也就是使用 New Architecture开发者即可获得 React 18 渲染器的自动批处理同时并发渲染器还带来了开箱即用的改进这减少了 React 中的重新渲染。
例如在官方示例中通过滑块指定要渲染的图块数将滑块从 0 拖动到 1000 将触发一系列快速的状态更新和重新渲染 在使用相同代码时可以直观地注意到新架构的渲染器提供了更流畅的 UI中间 UI 更新较少来自 Native 事件处理程序的状态更新如顶部 Slider 现在是批处理的模式。 同时使用新的并发功能如 Transitions可以定义 UI 更新的优先级例如将更新标记为较低优先级告诉 React 它可以 “中断” 渲染更新以处理更高优先级的更新以确保在重要的地方提供响应式用户体验。
例如使用 startTransition 配置可以中断红色方块的渲染同时 startTransition 还提供了一个 isPending 标志来告诉过渡何时完成。 你会注意到随着 transition 中的频繁更新React 渲染的中间状态更少因为它会在 state 过时后立即退出渲染相比之下如果没 transition 则会渲染更多的中间状态。 DevTools
同时随着 0.76 宣布的还有 React Native DevTools这是为了下一代重写的 React Native 调试器堆栈它其实从 0.73 就开始存在相应支持。 例如 React Native 0.73 附带的一键调试流程 只需在终端中按 J 即可完成调试而在 0.76 中它默认可用 未来
可以看到 React Native 的内在已经变得“面目全非”可以说的是虽然 RN 当时那一步踩的很大甚至扯着但是两年过去终于是开始缓过来了正如开头官方所说2024 年是向所有 React Native 用户推出新架构的一年 。
同时 New Architecture 还在解锁其他新功能例如 Web 对齐是也是 Meta 的一个积极探索领域这也是 RN 开发多年的官方期盼需要解决的例如
事件循环模型的更新 APIs 节点和布局 API样式和布局一致性
虽然已经许久没跟进 React Native 但是还是很开心 RN 能够持续迭代推进新的能力这样代表着项目具备旺盛的生命力同时 RN 在鸿蒙 Next 适配上类似 Flutter 也有 Software Mansion 和华为的同步社区支持所以至少现在看来RN 的未来依然可观。 更多资料可查阅 https://github.com/reactwg/react-native-new-architecture
