Flutter 还是 React Native：如何选择跨平台技术栈

如果你要做一款移动应用，又不想维护两套独立的原生代码，那么如今实际可选的就是两个框架：Flutter 和 React Native。我们用 Flutter 开发，但对于“该用哪个”这个问题，回答是：两者都很好，正确的选择更多取决于你的团队和产品，而不是任何基准测试。

下面是两者真正的区别，以及我们会如何帮你做决定。

核心的架构差异

这两个框架以根本不同的方式解决同一个问题，其他几乎所有差异都由此而来。

• Flutter 自己渲染界面。它自带渲染引擎，每个像素都由自己绘制，因此同一个组件在所有平台和系统版本上的外观和行为都完全一致。开发语言是 Dart，一门专为此设计的类型化语言。
• React Native 桥接到原生组件。它把你用 JavaScript 或 TypeScript 编写的组件映射到平台真正的原生控件上，所以界面是地道的原生界面，同时也继承了这些控件在各平台上的优点和怪癖。

两种方式都没有错。Flutter 用一点平台原生感换来了彻底的一致性和控制力；React Native 用一些一致性换来了原生组件和庞大的 JavaScript 生态。

我们为什么用 Flutter

对于我们所开发的应用，Flutter 的一致性和类型系统更胜一筹。因为它自己渲染界面，行为不会在不同平台之间出现偏差，也不会在旧版系统上给你意外。你测试的就是用户得到的。Dart 的强类型，加上不可变模型和可预测的状态管理，让大型应用在超出最初几个页面后依然易于维护。而单一的渲染路径意味着整个界面只需一种思维模型，而不是两种。

在实践中，这些选择从第一个页面起就在塑造代码：类型化、不可变的状态，一套 Dart 代码同时服务 Android 和 iOS，以及一个同时负责两个平台的团队。功能只需编写一次，也没有需要同步维护的原生分支。

什么时候 React Native 更合适

对于有些团队，我们会建议选择 React Native：

• 你的团队本来就深耕 JavaScript 或 TypeScript 和 React。共享的语言和技能能带来真实而即时的效率提升。
• 你希望与现有的 React Web 应用共享逻辑。
• 你的应用高度依赖原生界面组件，并且希望它们与平台自身的完全一致。
• 你所在的招聘市场里，React Native 人才比 Dart 人才好找得多。

框架本身不如契合度重要。一个用熟悉的技术栈自信交付的团队，会胜过一个与陌生技术栈苦苦搏斗的团队，无论盒子上印的是哪个标志。

两者都做对了什么

无论选哪一个，你都能拿到最大的奖励：一套代码、一个团队，功能同时登陆两个平台，彻底免去分别开发原生应用时“一切做两遍”的代价。两者都很成熟、支持完善，也都被许多严肃的应用用于生产环境。这是一个令人愉快的难题：这里没有坏选项，只有更合适的选项。

什么时候干脆不用跨平台

一个提醒：如果你的应用的全部价值都建立在最前沿的平台专属 API 之上，或者你需要平台性能的绝对极限来做诸如高负载实时图形之类的事情，那么尽管成本翻倍，完全原生的 iOS 和 Android 应用可能仍然是正确选择。这类应用只占少数，但确实存在；如果你的应用属于此类，我们会直说。

如果你正在为一个真实的产品权衡这个选择，我们很乐意结合你的团队和目标来一起分析，而不是套用一份通用的清单。