React Native

React Native 是由 Meta（原 Facebook）创建的开源框架，让开发者能够使用单一 JavaScript 和 React 代码库构建 iOS 和 Android 移动应用。与基于 Web 的混合框架不同，React Native 渲染真实的原生 UI 组件，因此应用在外观、体验和性能上都与使用 Swift 或 Kotlin 构建的应用相似。它于 2015 年在 MIT 许可证下发布，为 Facebook、Instagram、Microsoft Office、Shopify、Discord 和 Uber Eats 的部分功能提供支持，是全球应用最广泛的跨平台移动开发框架之一。

什么是 React Native？

React Native 是一个基于 JavaScript 的原生移动应用开发框架。”框架”一词意味着它提供了一个现成的平台，包含预构建组件、库和参考资料，因此开发者无需从零开始构建每个项目。”原生”一词意味着应用使用各操作系统实际的 UI 元素进行渲染，而不是在封装层内使用 Web 视图——这让 React Native 应用能够像直接使用 Swift、Objective-C、Kotlin 或 Java 编写的应用一样运行和交互。

该框架最初由 Facebook 工程团队于 2015 年发布，并采用宽松的 MIT 许可证分发。它将 React（流行的 Web 库）的基于组件架构扩展到移动端，让前端开发者能够复用现有的 JavaScript 和 JSX 技能，在手机、平板电脑、电视乃至桌面设备上发布应用。

这里的“原生”究竟是什么意思？

原生应用是为特定操作系统编写并直接在其上运行的应用。原生 iOS 游戏运行在 iOS 框架上；原生 Android 游戏运行在 Android 框架上。原生应用通常更快、响应更灵敏，因为它们使用的是操作系统自身的语言。React Native 通过不同路径实现相同结果：它不要求开发者学习 Swift 或 Kotlin，而是让他们编写 JavaScript，并在运行时将其映射到平台真实的原生 UI 组件。

React 与 React Native

React 更早出现。它由 Facebook 于 2013 年发布，很快成为在 Web 上构建交互式前端的主流方式——到 2024 年，约 41% 的专业开发者表示经常使用它。两年后的 2015 年，React Native 问世，旨在回答 Facebook 工程团队在内部不断遇到的一个简单问题：同样的基于组件架构能否驱动原生移动应用？在一次 Facebook 黑客马拉松上开始了两年的实验后，答案是肯定的。

从概念上说，两者更像兄弟姐妹而非双胞胎。它们共享 JSX、Hooks、组件生命周期、状态管理模式以及更广泛的 React 思维模型。构建过 React Web 应用的开发者从第一天起就能读懂 React Native 代码。变化的是渲染目标。React 通过虚拟表示渲染到浏览器 DOM，并自动进行差异比较和修补。React Native 则渲染到平台真实的原生 UI 树——iOS 上的 UIView、Android 上的 ViewGroup——完全绕过浏览器。

这一差异会对日常工作产生实际影响。React 开发者使用 CSS 进行样式设计；React Native 开发者使用基于 JavaScript 的 StyleSheet API，它支持部分 CSS 风格属性。React 使用 HTML 元素（div、ul、p）；React Native 使用平台无关的基础组件（View、FlatList、Text）。两者的行为足够一致，大多数 React 技能可以顺畅迁移；但差异也足够明显，团队通常会将 React Native 视为需要通过几个项目逐步培养的独立能力。

在实践中，这种关系在招聘或组建团队时最重要。熟悉 React 的前端开发者通常只需几周就能在 React Native 中高效产出，而不是数月。难点很少出在 React 层面——通常是底层原生部分：商店配置、平台特定构建流水线、原生模块集成、签名证书，以及 App Store 和 Google Play 的提交流程。

React Native 如何工作？

从高层来看，React Native 开发者编写 JavaScript 和 JSX（与 Web React 使用相同的语法），但代码不会生成 HTML，而是映射为各平台上的真实原生 UI 组件。一个 <Text> 元素会在 iOS 上变成 UILabel，在 Android 上变成 TextView。一个 <View> 会变成 UIView 或 Android 的 ViewGroup。同一份 JavaScript 在两个平台上运行，但用户看到的确实是原生界面。

多年来，JavaScript 端通过异步“桥接”与原生模块通信。从 2024 年末的 0.76 版本开始，React Native 将其新架构设为默认架构，以三个核心部分取代桥接：用于 JavaScript 与原生代码之间直接同步调用的 JSI（JavaScript Interface）、用于按需加载原生模块访问的 TurboModules，以及用于并发 UI 渲染的 Fabric。实际结果是，相比旧版桥接，冷启动更快、动画更流畅、内存占用更低。

基于组件的架构

React Native 继承了 React 将 UI 由小型可复用组件组合而成的理念。状态可通过熟悉的工具管理，例如 useState Hook、useEffect，或 Redux 等外部库。componentDidMount 和 componentWillUnmount 等生命周期方法的行为与 Web 端相同，这也是已经了解 React 的开发者能在数天而非数月内转向移动开发的原因。

跨平台代码共享

单一 JavaScript 代码库可以同时面向 iOS 和 Android，因为大多数 React Native 组件——View、Text、Image、ScrollView、FlatList——都是通用的。需要平台特定行为时，开发者会使用 Platform 模块，根据 Platform.OS 进行分支，或使用平台特定文件扩展名（Component.ios.js 和 Component.android.js）。当确实需要原生功能时，可以将使用 Swift、Objective-C、Kotlin 或 Java 编写的原生模块暴露给 JavaScript 层。

核心组件和功能

React Native 提供了一组跨平台基础组件，可映射到各操作系统的原生 UI。Web 使用 HTML 标签和 CSS，而 React Native 使用 JavaScript 组件和内联样式对象。这些基础组件中的每一个都会在运行时由框架渲染为对应的原生控件：一个 <Text> 元素会在 iOS 上变成 UILabel，在 Android 上变成 TextView；一个 <View> 会变成 UIView 或 Android 的 ViewGroup。这种映射并非叠加在 WebView 之上的技巧，而是框架的核心职责。

布局默认采用 Flexbox，但与 Web 有几个重要差异：没有 CSS Grid、没有基于 float 的布局、文本样式不会沿树向下继承，也没有媒体查询。大多数布局由带有 flex 属性的嵌套 <View> 容器构建，大部分样式位于 StyleSheet 对象中，而非独立的 CSS 文件。掌握以下十几个基础组件，基本就等同于掌握如何布局 React Native 页面。

除组件外，React Native 还提供了多项深刻影响日常开发的功能：

• 快速刷新。代码更改会在一秒内出现在正在运行的应用中，且不会丢失组件状态。与传统原生开发相比，这是最大的单项生产力提升，因为后者的构建和重新启动周期可能需要数分钟。
• 原生模块桥接。任何平台特定功能——相机、GPS、生物识别、推送通知、支付——都可以封装在原生模块中，并从 JavaScript 调用。大多数知名原生 SDK 已发布 React Native 包装器，因此编写自定义桥接代码是例外而非惯例。
• 第三方生态系统。npm 注册表为 React Native 项目提供数十万个 JavaScript 包，包括导航库（React Navigation）、动画库（Reanimated、Moti）、手势处理（Gesture Handler），以及用于分析、归因和变现的 SDK 包装器。
• 声明式 UI。与 Web 上的 React 一样，你描述给定状态下 UI 应呈现的样子，框架负责处理更新。这消除了与手动保持 UI 和数据同步相关的一大类错误。

支持的平台

React Native 主要以 iOS 和 Android 闻名，但其覆盖范围远不止移动端。Microsoft 早在 2016 年就开始在 Office 的部分功能中内部采用 React Native，并随后维护 Windows 和 macOS 的官方分支，这意味着桌面支持不是业余项目，而是 Microsoft 自身在 Office、Outlook 和 Xbox 中使用的生产级方案。社区维护的变体覆盖智能电视（tvOS、Android TV）和 Web，其中 React Native for Web 多年来一直为 Twitter 桌面网站的部分功能提供支持。

不过，这些平台上的“支持”并不一致。iOS 和 Android 是一等公民，核心一发布新版本和新 API，它们便会立即获得支持。Windows 和 macOS 通常比核心版本落后一到两个小版本，并且可能不包含全部新架构功能。TV 和 Web 通常还会再落后一两个版本，并且高度依赖第三方库兼容性。对于多平台策略，值得在前期确认项目依赖的库——尤其是包含原生模块的库——是否确实能在每个目标平台上运行。

对于需要跨多种终端发布产品的团队而言，这种广度非常重要。例如，订阅应用可以在 iOS、Android 以及（借助 React Native for Web）与营销保持一致的 Web 版本之间共享核心业务逻辑、付费墙代码和状态管理，仅复制最深层的平台特定行为。这是 Microsoft 和 Shopify 等公司持续投资 React Native，而非为每种终端维护独立原生团队的主要原因之一。

React Native 的优势

该框架持续流行归因于少数几个实际优势，这些优势对真实产品团队而言比基准测试更重要。被提及最多的优势是代码复用。Wix 是最大的生产环境 React Native 应用之一，下载量超过百万、平均评分高于 4.5。据其报告，iOS 和 Android 之间约共享了 95% 的逻辑代码库。Pinterest 将多项关键功能迁移到 React Native，正是因为其工程团队所说的：“代码共享不仅意味着可以节省实现时间，也能减少在需要多名平台特定工程师共同处理同一功能时共享上下文所带来的认知负担。”

其他优势会相互叠加。快速刷新让内部开发循环保持紧凑——JavaScript 更改大约一秒内就会出现在运行中的应用里，且不会丢失组件状态，这比原生 iOS 或 Android 开发的重新构建和启动周期快得多。npm 生态系统带来了数十万个可用包，几乎每种常见移动端需求都有成熟解决方案。2024 年和 2025 年逐步推出的新架构也缩小了与原生开发之间的大部分历史性能差距，早期采用者报告称，与旧版桥接相比，冷启动速度约提升 43%，渲染性能提升 39%，内存占用减少 20–30%。

对于早期团队，最具决定性的优势通常是上市速度。两名开发者组成的团队可以在数周而非数月内，可信地发布一款精致的 iOS 和 Android 应用，并且只需维护一套代码库。对大型组织而言，吸引力则转向招聘灵活性——JavaScript 人才库是软件行业中最大的，在大多数地区，招聘 React 开发者远比招聘资深 Swift 或 Kotlin 工程师容易。

局限与挑战

React Native 并不适合每个项目。其取舍真实存在，值得在投入之前认真权衡。最常被提及的痛点——JavaScript 与原生代码之间的通信开销——已通过新架构大幅降低，该架构以通过 JSI 进行的直接同步调用取代了异步桥接。将 React Native 描述为在复杂应用中天生缓慢的旧文章，大多描述的是 2024 年之前的情况。但其他限制依然真实存在。

GPU 密集型工作负载——3D 渲染、增强现实、实时视频效果、高级相机处理——仍然更适合原生开发。严重依赖前沿平台 API 的应用，如果这些 API 在新 iOS 或 Android 版本发布当周推出，可能需要等待数天或数周让社区库跟进；而完全原生团队可以立即集成。此外，跨大版本升级 React Native 本身确实比升级典型 npm 依赖更困难，因为项目中的每个原生模块都必须跟上核心版本。

坦率地说：对于绝大多数移动应用——生产力工具、社交产品、电商、内容、订阅应用和大多数实用工具——React Native 的能力绰绰有余，且与原生开发之间的成熟度差距已显著缩小。对于游戏、AR/VR 体验、专业创意工具，以及需要始终处于平台功能绝对前沿的应用，完全原生开发仍是更稳妥的选择。

使用 React Native 构建的应用示例

世界上一些最大的移动应用已在生产环境中使用 React Native。采用模式差异很大。Shopify 全面投入：经过多年的内部评估后，公司于 2020 年承诺所有新的移动项目都使用 React Native。其他公司，如 Facebook 和 Microsoft，则选择性使用它。Facebook 在主 Facebook 应用中为特定界面使用 React Native（Marketplace、Ads Manager、新闻动态的部分功能），同时保留其他原生界面。Microsoft 在 Office、Outlook 和 Xbox 的部分功能中使用它，同时继续在更合理的场景中发布原生代码。

以下列表并不完整——据估计，React Native 出现在 App Store 和 Google Play 合计前 500 款应用中的约 14–15%——但它展现了该框架已被证明可大规模应用的多样化类别。

值得注意的是，Airbnb 不在列表中。Airbnb 于 2016 年采用 React Native，在其应用的重要部分中投入生产使用两年，随后于 2018 年公开退出——这是一个被广泛讨论的大规模跨平台取舍案例。当时提到的原因包括原生模块开发缓慢、招聘挑战，以及同时维护原生和 React Native 技术栈基础设施的成本。此后框架已显著成熟，尤其是随着新架构的推出，Airbnb 所描述的大多数具体痛点都已在后续版本中得到解决。

React Native 与其他移动开发框架

在跨平台领域，React Native 最常与 Flutter 对比，后者是 Google 围绕 Dart 语言构建的 UI 工具包。到 2026 年，两者合计占据大多数新的跨平台移动项目：Flutter 约占 46% 的跨平台市场份额，React Native 约占 35–38%，其余份额由 .NET MAUI、Ionic、Cordova 和众多较小框架瓜分。当最大的平台特定精细度、前沿性能或最新 API 的访问权是决定因素时，使用 Swift 或 Kotlin 进行原生开发仍是第三种选择。

其他框架各自处于更细分的领域。.NET MAUI 很适合已经投入 C# 和 Microsoft 技术栈的团队，最常见于企业环境而非消费级应用。Ionic 和 Cordova 采用基于 WebView 的方案，可为内容密集型应用带来更快的初始开发速度，但在动画密集或交互式界面中，其表现通常不如 React Native 或 Flutter。要深入了解 2026 年两大领先跨平台框架在性能、生态系统、招聘和成本方面的对比，请参阅 Flutter 与 React Native。

选择很少是抽象地比较哪个框架“更好”。关键在于哪个框架匹配团队现有技能、应用的性能特征、特定集成所需库的可用性（分析、归因、支付），以及公司所在地区的长期招聘市场。Web 开发团队在 React Native 中达到高效产出的速度会远快于 Flutter。重视两个平台上像素级一致 UI、并希望完全控制每个渲染细节的团队，往往倾向于 Flutter。构建游戏或 AR 应用的团队通常会跳过两者，直接选择原生开发。

开始使用 React Native

常见的入门方式有两种：React Native CLI（有时称为“裸” React Native）和 Expo。Expo 是构建在 React Native 之上的托管工具包，可简化设置、自动处理大量原生底层工作，并内置相机、位置、通知和身份验证库。对于 2026 年的大多数新项目，推荐以搭配 EAS Build 的 Expo 作为起点。

最简配置如下：

1. 安装 Node.js 和包管理器（npm 或 Yarn）。
2. 安装 Expo CLI 或 React Native CLI。
3. 使用 npx create-expo-app MyApp 或 npx react-native init MyApp 创建新项目。
4. 使用 npx expo start（Expo）或 npx react-native run-ios / run-android（裸工作流）运行应用。

接下来，典型工具链包括用于页面路由的 React Navigation、一个或两个用于分析和归因的 SDK，以及针对 App Store 和 Google Play 的平台特定配置。

React Native 与应用内购买

React Native 没有内置解决方案的一个领域是变现。它没有用于应用内购买或订阅的原生 React Native API——这些仍需通过 Apple 的 StoreKit 和 Google Play Billing，这意味着 React Native 应用需要使用包装库或第三方 SDK 来处理它们。热门选择包括开源的 react-native-iap 和 expo-iap 包，以及 Adapty 的 react-native-adapty SDK 等托管服务；后者在原生商店 API 之上增加了服务端收据验证、付费墙配置、A/B 测试和订阅分析功能。完整教程请参阅 React Native 应用内购买教程。