Airbnb死磕React Native惨败，微软却玩出花！Office、Outlook全线接入，Copilot成最大赢家

尽管微软拥有自家的跨平台框架，但它成为了 React Native 的最大用户之一。

在 QCon London 上，微软高级软件工程师 Lorenzo Sciandra，同时也是 React Native 的维护者，向我们解释了微软为何选择这种跨平台开发方法，尽管微软已有.NET MAUI 和 C++ 跨平台方案。

微软将 React Native 应用于一系列产品，包括 Microsoft Office、Outlook、Teams、Xbox、Skype 和 Xbox 上的 Microsoft Store。并不是所有这些应用程序都完全使用 React Native 进行开发，因为他们广泛采用了一种被 Sciandra 称为“棕地开发”的技术，即使用 React Native 在现有的代码库中添加新功能。这也是微软能够快速将 Copilot 集成到所有原生应用程序中的原因之一。

以下是 Sciandra 的演讲原文：

挑选一项技术就像打开一盒巧克力，你永远不知道会遇到什么。

无论是启动一个项目、打造一款产品、开发一款应用程序，还是设计一种全新体验，我们都需要做出技术选择。有时候，这些决策是基于当时掌握的信息。然而，可能过了六个月，这个决策就被推翻，甚至带来意想不到的麻烦。

今天，我想分享的是，在过去六年多里，微软如何成功地使用 React Native。为此，我将从两个角度切入：既会探讨一些技术上的原因，也会涉及非技术层面的考量。希望这些内容能为你提供一些启发，成为你下一次决策会议的有力参考。

让我们先来谈谈适应性。先谈下“为什么 React Native 在某些情况下是有意义的”的技术原因。

上图几乎就是我们需要了解的关于 React Native 的所有内容。它基本上是一种在原生平台上制作应用程序的方法，通过通信层，使用 JavaScript 来完成繁重的工作，基本上包括了所有那些你需要让应用程序对用户有用的工作。

快速强调一下这一点，当我们刚开始讨论 React Native 时，React Native 的一个关键优势是，屏幕上渲染的所有内容，即使你编写的代码是 JavaScript，最终也会是完全原生的代码。

在上面的场景下，我们有一个非常简单的 React Native 应用程序，但 VS Code 调试器中的节点向我们展示了它的 UINavigationController 和 UIViewController 的。它最终都是原生的，当然，这是 React native 的一个关键特性。

上图可能更能直观地展示 React Native 应用的内部结构。看起来有点复杂，但稍后你会明白为什么需要这么多的模块。基本上，我们确实有原生 UI 和原生模块，同时也有 JavaScript React Native UI 代码、JavaScript 模块和业务逻辑。当你想到 React Native 应用程序时，你通常要处理的就是这些。

在一个普通的、标准的、原始的 React Native 项目中，这就是所谓的 greenfield（绿地）程序。这意味着你已经使用 React Native 从头开始构建你的应用程序了。我们的开发人员只需运行或使用 JavaScript，然后编写代码，终端用户就可以与他们眼中的正常原生应用程序进行交互了。

React Native 开箱即用，适用于 iOS 和 Android，因此只需一个代码库，你的用户群就能翻一番。

如果你以前从未使用过 React Native，并且只对移动世界感兴趣，那么我需要向你解释它的工作原理。它以前的工作方式是，通信层有一个 JavaScript 端，还有一个苹果、安卓端，用于与 iOS 和安卓 UI 以及原生模块通信。这些东西最终会出现在用户的应用程序中。

如果你曾在移动领域工作过，那么现在你可能已经知道可以带来显著的优势了。事实上，React Native 在加快产品上市时间方面做得非常好，不仅仅是在这个基本场景中，我们稍后会谈到。

事实上，这就是事情开始变得有趣的地方。没有什么能阻止我们将 JavaScript 扩展到更多的原生平台，而这恰恰就是我们所做的。

在微软，我们为 macOS 和 Windows 开发了 React Native，因为当然，我们是一家以桌面为主的公司。我们看到了使用基于 JavaScript 的解决方案来开发应用程序的潜力，我们决定对其进行扩展并自己使用它。我们并不是唯一一个押注 React Native 来实现这种适应性的人。事实上，React Native 可以支持的平台非常多。目前有两大推动力，一个是围绕 visionOS 的，另一个是由亚马逊和英国咨询公司 Theodo 支持的电视平台。这已经为 React Native 引入了一定程度的适应性，使其不仅局限于单一平台，这一点非常有趣。

现在，让我们为这种适应性再增加一个维度。我想强调的是，最终，用户仍然会在他们的原生操作系统上与原生应用程序进行交互。

当用户使用一个普通的应用程序，比如 Swift 或 Kotlin 应用程序时，他们所做的只是与使用 100% 原生 UI 和原生模块构建的 100% 原生应用程序进行交互。

这两个方块与我之前展示的非常相似。这实际上就是 React Native 领域中所谓的 brownfield（棕地）应用程序。这意味着，当你有一个预先存在的原生应用程序并注入 React Native 时，你可以添加通信层，并开始在 React Native 中编写一些功能和体验。这意味着你可以在原生应用程序中添加 React native 中的某些部分。我们甚至可以更进一步。这个图现在太复杂了，所以让我们把它简化一点。

现在，让我们进入一个更接近微软的场景，我们有多个应用程序。假设我们有一个应用程序，我们称之为 Outlook。我们再拿一个应用，我们称之为 Office。如果这两个场景都已经存在桥接层，并且我们想用 JavaScript 编写一些代码在我们的原生应用程序中重用，那么我们只需编写一次，然后将其部署在不同的主机应用程序上即可。

事实上，这正是我们在微软经常做的事情。

基本上，我们有许多庞大的单体存储库，即使只是移动代码并让一个主机应用（比如 Outlook、Office）来使用在另一个单体存储库中构建的体验，也需要付出一定的努力。因此，在 React Native 领域，我们为自己开发了一些工具，这些工具已经开源。

进一步来说，正如我之前展示的那样，brownfield 的场景与终端用户使用普通应用程序的情况非常相似，但对我们而言，我们添加了一个通信层。我们添加了一些 JavaScript 代码，而这些代码并不是免费的。当然，我们引入了一些开销。例如，我们可能会增加打包的大小。这可能会导致启动变慢，或者某些交互可能会变慢。React Native 实际上适应性很强，你可以做的事情之一就是用自定义的东西替换通信层。实际上，在我们的一个开源仓库中，我们确实有一个名为 react-native-host 的实现。在某些情况下，这种方式可能看起来有点奇怪，但它能有效解决问题。

我为什么需要它呢？让我给你展示一个稍微复杂一些的例子。假设你有一个非常大的应用程序，里面有很多页面，你已经用 React Native 构建了其中的两三个页面。

也许其中一个有五个页面那么深。另一个需要两个页面那么深。还有一个则需要十个页面。这是一个几乎没人会看到的页面。如果你不知道用户什么时候会使用它，或者不了解每个体验，那么你基本上只有一个通信层。你需要在一开始时就建立它，然后希望在某个时候它会变得有用。如果你有一个自定义的通信层，你可以根据特定需求来调整这个通信层的行为，例如，只在你到达特定体验之前的倒数第 n 个页面上才建立它。你可以根据每种特定需求进行来进行增减。

这甚至不是我的最终形态。当我前面向你展示业务逻辑是分解的时候，那是有意为之。因为当你编写一些与服务器交互的代码时，例如当你有一个大型企业应用程序，你需要为不同的服务与许多后端交互时，这一点更为重要，然后一个新功能就出现了。

基本上，该业务逻辑几乎是标准的 JavaScript、TypeScript 代码。如果我们想快速为 Web 构建一些东西，我们有为 Web 应用程序构建的 JavaScript 代码，并且我们想快速将其引入我们的原生平台中，但我们只构建了业务逻辑，如果我们这样做会怎么样？实际上，我们在微软发现，有一种使用 React Native 的特殊模式，基本上可以称之为 headless。这允许你的应用程序团队完全原生地构建 UI。他们可以直接与后端团队为 Web 应用程序提供的 JavaScript 代码进行交互，而无需为你的应用程序从头开始重写。

在微软，看起来更像是这样。我们有一个 brownfield 场景。我们有自定义通信层。Headless 是 React Native 更有趣的用例之一，它可以加快上市时间，尤其是当你拥有一系列跨不同平台的应用程序时。

此外，我还展示了很多使用 React Native 的不同方法。此时你可能会想，它看起来到底是什么样的？微软的 React Native 应用程序是什么样子的？当然，答案取决于场景。我们确实有很多应用程序使用 React Native。我们有 Office、Outlook 团队，我们都以 brownfield 的方式使用 React Native。我们还有有 Xbox 和 Skype，它们以 greenfield 方式使用。

不仅如此，我们确实积累了很多经验。例如，上图被称为联系人卡或实时角色卡，它是一段可以在所有这些平台上运行的代码。

在某种程度上，我们在微软都有类似的 React Native 应用程序，是标准的 greenfield 程序。

这两种场景要复杂得多，相互通信，共享代码，有些场景比其他场景需要更多的定制。有些比另一些需要更多地使用 React Native。

React Native 的伟大之处在于，这两种场景都是有效的 React Native 案例，这确实开辟了一个充满可能性的世界。我们都知道，技术本身并不是赢得领导层青睐的关键因素。比如，我已经让它快了 10 毫秒，快了 100 毫秒。关键在于战略原因和经济效益。他们更关心的是如何通过技术创新来创造商业价值，如何节省时间和资源。

谈到战略，我想从 2022 年发生的事情开始讲起。当时，不同团队的开发人员走进我们办公室，问我们为什么选择使用 React Native 而非其他技术？令人惊讶的是，谈话非常文明。没有人互相指责。这对我来说是一个很好的方法，可以找到一堆 很好的战略理由（GSR）。

第一个实际上是可雇佣性。 也许你们中那些些更熟悉 JavaScript 领域的人可能已经看到了这一点。麦肯锡《2023 年技术趋势展望》中有一句非常有趣的引用，他们非常清楚地指出，缺乏人才是制约增长的首要问题，当然，这里的人才是能真正为你工作的人。

当谈到 React Native 时，它是基于 JavaScript 的，并它在任何你能找到的服务器上都是不变的，JavaScript 位居榜首，是最大的开发人员库。它确实为最大的开发者群体打开了大门。因为它是 JavaScript，所以这也意味着它实际上可以更快地从不同的项目中吸纳人才。

第二个很好的战略原因是灵活性。 我已经提到过，brownfield 是使用 React Native 的一种非常有趣的方式。它真正伟大的地方在于它不局限于单一的规模。与其他一些移动解决方案相比，你可以让它尽可能多或尽可能少地成为你的应用程序的一部分，尤其是跨平台解决方案。这实际上要求你抛弃一切，从头开始，建立一个新的堆栈。React Native 确实允许你试水，只需引入一点点，看看它是否有效，并且在如何将其引入代码库以及它能做多少方面真的很灵活。

第三个是它的活跃性，当然，我指的是它作为一个开源项目非常活跃。我不想过多讨论技术细节或 React Native 的工作原理，因为如果到了这个地步，我基本上会说，“忘掉这些，因为下个月可能会有变化”。

这是因为有一个名为“新架构”（New Architecture）的项目，它实际上是 React Native 的重新设计。多年来，Meta 的团队与我们以及其他公司合作，发现 React Native 的现有架构存在一些非常严重的瓶颈。Meta 花了大量时间和精力，为 React Native 开发了一个新的架构，旨在解决所有这些瓶颈问题。

这是一个新流程，基本上，我们正在从一个单一的瓶颈转向一个完整的接口，从而允许 JavaScript 和原生之间有更多的渗透性。我不知道你是怎么想的，但 React Native 是在 2015 年推出的，所以差不多有 9 年了。九年过去了，有多少开源项目仍然非常活跃呢？他们正在做重要的工作，旨在帮助每个人，而不会像 Angular 2 那样具有破坏性。

此外，还有一些更有趣的战略原因，比如跨行业的协同效应，这对微软的规模来说可能更加重要。

在我展示的应用案例中，还有一些大型科技公司也在进行类似的探索，比如 Meta 和亚马逊。当我们需要为项目争取资源时，我们可以强调与这些公司的合作，表明我们正在跟随行业趋势。这种“借力打力”的策略，往往能更容易获得高层管理层的认可。记住，与行业巨头合作，不仅能扩大影响力，还能促进技术交流，实现互利共赢。

当然还有第五点，也是最重要的一个。也可能是微不足道的原因。对于很多不同的项目，我们都是这么说的，“它是开源的。默认情况下它更好”。

让我详细谈谈为什么，出于战略原因，开源实际上能够带来更大的好处。

第一个原因可能是领导层最感兴趣的。今年 1 月，哈佛商学院发表了一篇有趣的论文，试图估算开源的价值。他们得出的一个关键发现是，如果我们所有的公司都停止使用开源，不得不在内部从头开始重写，那么成本将增加 3.5 倍。首先，使用开源是件好事，因为它可以为你节省资金。

第二个原因是因为它是我们能掌控所用技术。Fork 按钮就是最好的证明。有了它，我们不仅可以维护项目，还能自由地根据需求进行定制，就像开发 React Native macOS 一样。开源让我们拥有代码的控制权。如果项目遇到问题，或者我们想另起炉灶，都可以随时修改代码，而不受制于原作者。这避免了被他人牵着走的被动局面。

第三个原因实际上是 React Native 拥有一个庞大的社区。它是 JavaScript 生态系统的一部分，我们已经提到过了，JavaScript 生态系统是最大的开发人员库。

看到我们拥有如此庞大的数字并不奇怪。例如，我试图找出一个更好的数字来显示这个社区的规模，现在它在 npm 上每周下载量约 200 万次，这是一个相当大的数字。

React Native 目录网站是一个专门为 React Native 制作的所有库的人工列表。想象一下，由于你使用的是 React Native，你可以访问近 1400 个库。除此之外，你还可以添加所有纯 JavaScript 库。它们不需要特定于 React Native，只要它们的 JavaScript 能正常工作即可。成为这个大社区的一员真的意味着有大量的工具和资源。你不应该低估这件事。

当然，具体到 React Native，由于它基于 React，因此带来了非常有趣的跨公司协同效应。我的意思是，如果我的团队和组织投资于 React Native，而我们的姐妹团队和组织则在 Web 上工作，他们也在投资于 React，那么我们就拥有了一个共同点。这使得我们公司能够围绕这项技术进行更广泛的投资，并集中精力在该技术上。

例如，在微软，我们有 Fluent UI 库。基本上，Fluent UI 是我们的设计系统。流畅的 UI GitHub 仓库是用 Web 实现的，它使用的是 React。事实上，不同的团队可以在某种程度上走到一起，React 是我们喜欢的技术，我们投资它，这确实有助于与领导层进行对话，从战略意义上讲，这是非常有力的。

然后从技术上讲，我还想补充一点。它可以使用 Web 代码。

我前面提到的一件事是，我们需要 JavaScript React Native UI 代码和 JavaScript 模块来实现控制原生平台的 React Native 应用程序。特别是特定于 JavaScript React 的原生 UI，这有时会有点小问题，很多团队都不想处理这个问题。比如，我已经有了自己的 Web React 代码，为什么它不能正常工作？这实际上是我们微软和 Meta 一直在思考的问题。我们已经讨论了一段时间了。

我们的想法是，基本上，我们想让 React Native 能够使用直接的 React 代码，而且，我们可以使用 WebAPI 来控制原生模块。当然，这仍处于实验阶段。Meta 提供了严格的 react-strict-dom 存储库。我们有 WebAPI 工作。我们正在积极开展这项工作。我们真的认为这将是 React Native 领域的下一个大事件。

当然，也有权衡。如果我只是来这里，在演讲结束时说的最后一句话是“一切都很完美。再见。”你可能不会相信我。作为工程师，我们深知没有银弹。React Native 虽然优秀，但仍然存在一些技术上的取舍。让我们来谈谈 React Native 带来的几个重大权衡。

第一个，它非常活跃。这意味着它仍在持续存在和被投资开发。因为它在发展中，我们需要不断跟上。当你需要从一个版本升级到另一个版本时，经常会遇到巨大的差异，需要做大量的修改。这是我们多年来与 Meta 积极合作的重点。我一直是发布团队的一员。

此外我们还制作了一些工具。前面我提到了那个名为 React Native Test App 的工具，这对升级过程有很大帮助。

另一个权衡是，我确实提到过你可以将它与现有项目集成，这非常酷，而且它非常强大。很多适应性都来自于此。这也是 Meta 在 Facebook 主应用程序“市场”选项卡中使用它的主要方式，确切地说是与 brownfield 模式中的现有流程集成。

涉及到现有项目时，你会增加开销。增加开销的主要方式基本上有两种。一个是引入这个通信层。你正在为你的应用程序添加厚重感。你在给启动过程增加了一些时间。

当然，由于你正在添加 JavaScript，我们都知道 JavaScript 包可能非常庞大，所以这是你需要考虑的另一个方面。你会想，我要把它加进去吗？我能接受这个权衡吗？为了帮助你解决这个问题，我们已经提到了自定义层。这是一种方式。当然，这可能需要一些内部调整和工程。还有新的架构。这部分问题正在得到解决。对于 JavaScript 包，在我前面提到的单体存储库中，我们确实有一个工具，它实际上是一个摇树机，它对此有很大帮助。事情需要权衡，但解决办法正在进行中。

涉及到与现有项目的集成时，实际上存在一个更大的问题，特别是当你需要考虑一个非常大的场景时。或者你在一家大公司，你试图说服很多人将 React Native 集成到你的项目中，因为归根结底，你所做的就是打破平衡。如果你在 React Native 领域，如果你听说过 React Native，我能给你举的最大的例子可能来自 Airbnb 臭名昭著的 Sunsetting React Native 博客文章系列（Airbnb 宣布放弃使用 React Native：https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30a）。基本上，Airbnb 在 React Native 上投入了大量的资金。在 2018 年的某个时候，它们没有成功，死掉了。

问题在于，对很多人来说，React Native 已经死了。那是 2018 年，2024 年我还在这里，所以我是活生生的证据，证明那不是真的。如果你真的去了读这篇博客文章，我认为其中一个主要的收获就是打破了平衡。你不能只是去找 iOS 工程师、Kotlin 工程师，然后把 JavaScript 强加给他们，然后就心满意足了。在将 React Native 之类的东西集成到现有的解决方案时，你要考虑达成了多大的一致，需要领导层给予多大的支持，你真的需要小心如何处理它们。

React Native 的灵活性令人印象深刻。它的架构可高度定制，适应各种平台和配置。你可以根据项目需求，灵活增减功能。基于 JavaScript 的特性，使得代码和工具共享变得十分便捷，例如 ESLint 和 Prettier。这对于熟悉 JavaScript 的开发者来说无疑是个福音。

从战略角度看，JavaScript 生态的庞大为 React Native 提供了丰富的人才储备。其灵活的设计允许我们逐步引入，无需一蹴而就。你可以从一个小模块开始，逐步扩大应用范围。

React Native 作为开源项目，拥有活跃的社区和持续的维护。这为开发者提供了强有力的支持，尤其在大型团队或跨公司协作时。

当然，任何技术都有其两面性。React Native 也需要我们付出额外的学习成本，并注意保持技术栈的平衡。如果引入不当，可能会导致项目复杂度增加。

总结来说： React Native 的灵活性是其一大优势，但同时也要谨慎权衡。在做出决策时，应结合项目实际情况，综合考虑技术、团队和业务等多方面因素。

与会者 1：你说 React Native 的优势之一是它很活跃。它与父级 React 项目有什么关系？因为这似乎是一个自我反省的任务，我认为它已经近两年没有发布任何版本了。React Native 与有些陷入困境的 React 项目之间又有什么关系？

Sciandra：我认为有一件事需要澄清，在 Meta，就组织结构而言，React 和 React Native 由同一个组织维护。整个组织被称为 React Org。从这个意义上说，React Native 是该项目的重要组成部分。你可能知道，在 Meta 内部，有一个庞大的单体代码库，其中所有内容都是共存的。当然，我来自微软，我可以谈谈 Meta 是如何工作的，但我不能太深入。

从技术上讲，React 还活着。我很确定 React 19 很快就会发布（编者注：已于 2024 年 12 月发布）。

React 在某种程度上是一个小得多的项目。在某种程度上，它只是一个 Web 库。相比之下，React Native 需要更多地关注其周围发生的事情，包括 Android 和 iOS 的。从这个意义上说，我不会把不同的发布节奏视为一个重要的信号。这正是这两个项目的本质。它们是紧密相连的。在一个项目上工作的人们与在另一个项目下工作的人们非常接近。这是来自 Oculus 体验团队的一位成员发表的演讲里提到的，这也是 React、React Native 大量结合使用的另一个平台。在某种程度上，只要两个项目中的一个有火花，你就可以假设两者都有火花，因为基本上都是同一群人在做这两个项目。

与会者 1：两年前，当我研究 React Native 对桌面的支持时，有一个 React Native 的分支仓库，如果你想构建一个也能在桌面上运行的移动应用程序，你必须实际构建两个不同的应用程序。因为有官方的移动版 React，还有微软的桌面版 React，这和你们的竞争对手不同。你现在是否仍然需要实际构建两个不同的应用程序呢？

Sciandra：不是的。存储库仍然是分开的。有 React Native Facebook/React Native 代码库，即 iOS 和 Android。有微软的 React Native macOS 和 React Native Windows。这是三个独立的代码库。我想也许你指的是开发人员在构建应用程序时的体验，或者实际的代码库。我认为，在这个时间点上，流程是生成一个 React Native 应用程序，然后运行一个额外的命令来添加额外的文件夹。你生成 React Native 项目，然后你进入文件夹，在其中运行 React Native Windows，或者类似的东西，这就添加了 Windows 实现，所以你需要的所有原生代码都在 Windows 文件夹中。据我所知，差不多就是这样。我不使用 Flutter，但基本上，我的理解是，在那里你会有一个代码库，里面只有并排存在的单独文件夹。

与会者 1：与使用 React native 相比，使用原生代码、使用 Android 和 Java 或 Kotlin 等对性能有何影响？你根本没有谈到性能。

Sciandra：如果我有一个完全基于 Kotlin 的 Android 应用程序，与 React Native 相比，它的性能如何？我们在微软的所有场景中看到的是，性能没有显著的差异。即使有一些小的开销，最终，当涉及到最终的用户体验时，交互性的差异也是最小的。当然，我们不会尝试在非常复杂、计算量很大的情况下使用 React Native。我们不会尝试在 visionOS 或其他设备中渲染 3D 对象。合适的用例更像我前面展示的活动角色卡。对于这些场景，性能几乎是相同的，特别是当涉及到用户时。一些小的基准测试可能会有所不同，但是对于终端用户来说，响应的毫秒数都是几百毫秒，比如 200、220 毫秒之类的。

与会者 3：例如，你展示了你的一些项目，其中 10% 是 React Native，90% 是原生。这是因为其中只有 10% 可以用 React Native 制作，而其余的计算量太大了吗？

Sciandra：只是因为它是一个已有的代码库。如果我们已经构建了 Outlook，我们只是想添加进来，当你点击头像时，会出现一个新的东西，它会向你显示一些细节。我们不会丢弃之前构建的所有内容。它就在那里，我们只是把这个新部分加进去。我们不是原生构建它，而是从我们已经为其他平台构建的代码库中提取它，然后把它放进去。

这取决于功能和团队。同样，我提到的一些事情就像这些非技术原因。就我们的规模而言，大多数决策都不是技术性的，更多的是谈论哪个团队有权做某些事情。它几乎总是归结为这些类型，即哪个领导层同意在哪个团队中做什么，并在此基础上反映在代码库中最终包含哪些代码。没有一个总体计划来让每个应用程序都使用 React Native 构建。

在微软，我们并没有把它用于我们做过的所有应用程序。我们在不同的层面上使用了它，但这在很大程度上取决于我们是否已经有了这些代码。如果我们使用 React Native，这是否意味着我们可以更快地将该功能推向市场？

例如，Copilot 就是一个很好的例子。我们能够如此迅速地在所有原生应用程序中使用 Copilot 的原因之一是，我们有 Web 实现，并且通过我前面提到的一些事情，可以使这个过程变得更快，因为我们有 Web 代码，就可以尽快将其连接起来，并将其提供给我们的用户。

与会者 2：既然你来自微软，你如何在.NET MAUI（一个新的多平台，可以使用它构建多个应用程序）和 React Native 之间做出选择？

Sciandra：例如，React Native 和.NET MAUI 之间的一个关键区别是，.NET MAUI 更适合 C++ 开发人员。

这在很大程度上取决于这项工作需要在什么代码库上完成，团队拥有哪些专业知识？例如，如果我们已经用 JavaScript 为 Web 构建了实时角色卡，那就太完美了。如果我们想快速完成，我们需要一些 JavaScript，因此 React Native 更有意义。

我举一个理论上的例子，假设 Office Word 在 C++ 中创建了一个特殊功能，我们想把它放到 Excel、PowerPoint 甚至 Outlook 中，那么在这些情况下，也许像.NET MAUI 这样的东西会更有意义，或者直接使用 C++ 共享代码。

这要看情况。这在很大程度上是功能优先。我们正试图以尽可能快的方式为客户提供价值。我们认为，原生应用的体验需要与原生平台兼容。这就是为什么我们尝试使用 React Native 而不是 WebView 的原因。

与会者 4：我们在移动应用程序中使用了很多 WebView，我们使用 React Web 来填充这些 WebView。看到 React Native 的广泛使用真的很有趣。我们之前已经用 React Native 进行了一些实验，我们实际上已经从代码库中提取了一些。我只是想知道，值得我们再试一次吗？你认为在 WebView 中使用 React Web 与尝试使用 React Native 进行更多实验之间的权衡是什么？

Sciandra：这要视情况而定。例如，你想优化什么？我在最开始说过的一件事是，通过使用 React Native，原生操作系统可以准确地知道应用程序中发生了什么。它知道每一个组件。如果你有一个类似 WebView 的东西，那么原生操作系统知道的是，现在我抛出了一个 WebView，我不知道里面发生了什么。这是一个例子。例如，这可能会导致操作系统以不同的方式优化你的应用程序。因为它不知道你在显示哪个页面。你是在展示三个页面，还是在展示一个页面？在 WebView 中，你真的不知道。这真的取决于你想优化什么。如果你只是想，我有我的 Web 应用程序，我真的不想再花任何工程时间了，只是想让我的用户在手机上安装一些东西，当然，WebView 是有意义的。

与会者 4：根据用例，可能有一种策略可以同时做到这两点。

Sciandra：还有 React Native WebView。也许你正在使用一个直接的 WebView。有不同的选择。同样，WebView 在某些情况下是有意义的。这完全取决于你想要优化什么。

与会者 5：为什么选择 React Native，为什么不选择像 NativeScript 之类的东西呢，它可能不会把你特别绑定在 React 上？

Sciandra：首先，正如我前面所说，如果我们都在 React 领域工作，我们可以创造跨公司的协同效应。这其中有一些战略原因。NativeScript 的情况其实很特殊。项目中的一些人与我们的团队密切互动，因为我们围绕 React Native 用户使用的 JavaScript 引擎开发的一些解决方案，现在正被 NativeScript 用来做一些非常有趣的事情。我经常和 Jamie Birch、Nathan Walker 以及团队一起工作，我们经常聊天。看着两个被一些人视为竞争对手的项目，实际上是在互相帮助，这很有趣。

为了满足我们的需求，我认为当我们开始研究 React Native 时，NativeScript 并没有像今天这样强大或完善。我认为现在它是一个比其他一些选择更强大的竞争对手，尤其是当你想采用基于 JavaScript 的解决方案时。我认为，就我们的需求、投资和目标平台而言，React Native 仍然更有意义。这也可能是一种动态惯性。我们已经投入了这么多，以至于我们可能不会一下子把所有事情都掉转方向。这两个项目正在密切合作。

与会者 6：有没有一种情况是你想反过来做呢。我看到你不得不放弃 brownfield 应用，也许你想让 5% 的那一部分代码原生化，而不是支持和使用 React Native。

Sciandra：如果我用 React Native 做了一些事情，我想用原生的方式重建它？到目前为止，我还没有听说过我们有需要这样做的任何场景，但我可以看到这样的情况，例如，假设组织发生了重组，你有了一个新的领导层，而新的领导团队已经裁减了 Web 团队，因为他们更相信原生应用程序，而不是 Web 团队或 Web 应用程序。在这种情况下，我完全可以想象一个原生团队必须接管一个预先存在的 brownfield 场景。在这种情况中，如果你的原生团队只使用 Swift，那么从 React Native 过渡到完全原生是有意义的，这基本上就是 Airbnb 一直在做的事情。一旦最支持这种方法的人离开了，专业知识也离开了，公司里剩下的就是原生工程师，所以，当然，你想要重建，这样你就可以尽可能地使用你所拥有的最好的工程了。

Lorenzo Sciandra 是微软的高级软件工程师，他帮助领导 React Native 项目以及与亚马逊和 Meta 等合作伙伴的合作。自 2018 年以来，他一直是 React Native 的活跃维护者，他将自己的技术专长与对开源和心理健康倡导的坚定承诺相结合。

原文链接：

https://www.infoq.com/presentations/react-native-microsoft/