Facebook 创建 React Native 来构建其移动应用。这样做的动机来自 React for The Web 如此成功的事实。如果 React 是一个很好的 UI 开发工具，并且您需要一个本机应用，那么为什么要反对它呢？只需使用本机移动操作系统 UI 元素即可！
在本章中，将介绍 React Native 以及使用它构建本机移动 web 应用的动机。
在本书的前面，我介绍了渲染目标的概念，即组件渲染的对象。就 React 程序员而言，渲染目标是抽象的。例如，在 React 中，渲染目标可以是字符串，也可以是 DOM。这就是为什么您的组件从不直接与渲染目标交互，因为您永远不能假设它是您所认为的。
移动平台具有 UI 小部件库，开发人员可以利用这些库为该平台构建应用。在 Android 上，开发人员实现 Java 应用，而在 iOS 上，开发人员实现 Swift 应用。如果你想要一个功能强大的移动应用，你必须选择一个。但是，您需要学习两种语言，因为仅支持两种主要平台中的一种并不现实。
对于 React 开发人员来说，这不是问题。您构建的相同组件可以在任何地方工作，甚至在移动浏览器上！必须再学习两种编程语言才能构建和发布一个移动应用，这在成本和时间上都令人望而却步。简单的解决方案是引入一个新的 React，它支持一个新的呈现目标本地移动 UI 小部件。
React Native 使用一种对底层移动操作系统进行异步调用的技术，该操作系统调用本机小部件 API。有一个 JavaScript 引擎，React API 与 React for the Web 基本相同。差异主要与目标有关；这里没有 DOM，而是异步 API 调用。该概念在此处可视化：
这显然过于简单化了封面下发生的一切，但基本思想如下：
- React Native 使用 Web 上使用的 React 库，并在 JavaScriptCore 中运行
- 发送到本机平台 API 的消息是异步的，并且出于性能目的进行了批处理
- React Native 附带为移动平台实现的组件，而不是 HTML 元素的组件
有关 React Native 的历史和机理的更多信息，请参见https://code.facebook.com/posts/1014532261909640 。
为 React 实现新的渲染目标并不简单。这与发明一种在 iOS 和 Android 上运行的新 DOM 本质上是一样的。那么为什么要经历所有的麻烦呢？
首先，一般来说，移动应用的需求量很大。原因是移动网络浏览器的用户体验不太好。我将在下一节对此进行详细阐述。第二，JSX 在构建用户界面方面非常棒。比起学习新技术，使用你所知道的要容易得多。
这是后一点，这是最相关的你，读者。如果您正在阅读本书，您可能会对在 web 应用和本机移动应用中使用 React 感兴趣。从开发资源的角度来看，我简直无法用语言表达 React 的价值。没有 web UI 团队、iOS 团队、Android 团队等等，只有理解 React 的 UI 团队。轻松点！
移动浏览器缺乏移动应用的许多功能。这是因为浏览器无法复制与 HTML 元素相同的本机平台小部件。我们可以尝试这样做，但通常最好只使用本机小部件，而不是尝试复制它。部分原因是我们需要更少的维护工作，部分原因是使用平台固有的小部件意味着它们与平台的其余部分保持一致。例如，如果应用中的日期采集器与用户在手机上与之交互的所有日期采集器看起来都不同，那么这不是一件好事。熟悉是关键，使用本机平台小部件使熟悉成为可能。
移动设备上的用户交互从根本上不同于我们通常在 Web 上设计的交互。例如，Web 应用假定存在鼠标，并且按钮上的单击事件只是一个阶段。但是，当用户用手指与屏幕交互时，事情变得更加复杂。移动平台有所谓的手势系统来处理这些问题。React-Native 比 React-for-web 更适合处理手势，因为它可以处理这些您在 web 应用中不需要考虑太多的事情。
随着移动平台的更新，您希望应用的组件也保持更新。这不是 React Native 的问题，因为他们使用的是来自平台的实际组件。同样，一致性和熟悉性对于良好的用户体验非常重要。因此，当你的应用中的按钮的外观和行为与设备上其他应用中的按钮完全相同时，你的应用感觉就像是设备的一部分。
当我第一次听说 React-Native 时，我自然而然地认为这将是一个跨平台的解决方案，它允许您编写一个 React 应用，在任何设备上以本机方式运行。在开始与 React Native 合作之前，帮自己一个忙，摆脱这种心态。iOS 和 Android 在许多基本层面上都不同。甚至他们的用户体验理念也不同，因此试图编写一个在两个平台上运行的应用显然是错误的。
此外，这不是 React Native 的目标。目标是随时随地 React 组件，而不是在任何地方一次写一次就运行。在某些情况下，您会希望您的应用利用 iOS 特定的小部件或 Android 特定的小部件。这为特定平台提供了更好的用户体验，并且应该胜过组件库的可移植性。
在后面的章节中，我们将研究组织平台特定模块的不同策略。
话虽如此，iOS 和 Android 之间有几个重叠的领域，它们之间的差异微不足道。换句话说，这两个小部件的目标是以大致相同的方式为用户完成相同的事情。在这些情况下，React Native 将为您处理差异，并提供统一的组件。
在撰写本文时，有传闻称 Windows 支持将做出本地响应。如果这发生在现在和出版之间，我可以接受，因为 iOS 和 Android 仍然主导着移动市场。
我们在上一章中实现了 mobile first React 组件。既然你已经了解 React Native，你是否应该忘记这一切？不是。不是每个用户都愿意安装应用，尤其是当你还没有很高的下载数量和评级时。web 应用的进入门槛要低得多，用户只需要一个浏览器。
尽管无法复制本机平台 UI 必须提供的所有功能，但您仍然可以在移动 web UI 中实现令人惊叹的功能。也许拥有一个好的网络用户界面是提高你的移动应用下载数量和评分的第一步。
理想情况下，您应该实现以下目标：
- 标准 web（笔记本电脑/桌面浏览器）
- 移动网络（手机/平板电脑浏览器）
- 移动应用（手机/平板电脑本机平台）
在这三个空间中投入同等的精力可能没有多大意义，因为您的用户可能更喜欢一个区域而不是另一个区域。例如，一旦你知道，与网络版本相比，你的移动应用的需求真的很高，那就是你在那里投入更多精力的时候了。
在本章中，您了解到 React Native 是 Facebook 重用 React 创建本机移动应用的一种努力。React 和 JSX 非常擅长声明 UI 组件，而且由于现在对移动应用的需求巨大，因此使用您已经知道的 Web 组件是有意义的。
移动浏览器对移动应用的需求如此之大的原因是它们感觉更好。Web 应用缺乏像应用一样处理移动手势的能力，而且从外观和感觉的角度来看，它们通常感觉不到移动体验的一部分。
React Native 并没有试图实现一个组件库，该库允许您构建一个在任何移动平台上运行的 React 应用。iOS 和 Android 在许多重要方面有着根本的不同。如果存在重叠，React Native 会尝试实现公共组件。现在我们可以使用 React 以本机方式构建移动 web 应用，我们会放弃吗？这可能永远不会发生，因为用户只能安装这么多应用。
现在，您已经了解了 React-Native 是什么，以及它为什么很棒，接下来的章节将学习如何开始新的 React-Native 项目。