阿里P7Android高级工程师：全网最全 Flutter 与 React Native 深入对比分析

前言

临冬之际，移动端跨平台在经历数年沉浮之后，如今还能在舞台聚光灯下雀跃的， 也只剩下 React Native 和 Flutter 了，作为沉淀了数年的 “豪门” 与 19 年当红的 “新贵” ，它们之间的 “针锋相对” 也成了开发者们关心的事情。

过去曾有人问我：“他即写 Java 又会 Object-C ，在 Android 和 IOS 平台上可以同时开发，为什么还要学跨平台呢？”

而我的回答是：跨平台的市场优势不在于性能或学习成本，甚至平台适配会更耗费时间，但是它最终能让代码逻辑（特别是业务逻辑），无缝的复用在各个平台上，降低了重复代码的维护成本，保证了各平台间的统一性， 如果这时候还能保证一定的性能，那就更完美了。

一、环境搭建

无论是 React Native 还是 Flutter ，都需要 Android 和 IOS 的开发环境，也就是 JDK 、Android SDK、Xcode 等环境配置，而不同点在于 ：

• React Native 需要 npm 、node 、react-native-cli 等配置 。
• Flutter 需要 flutter sdk 和 Android Studio / VSCode 上的 Dart 与 Flutter 插件。

从配置环境上看， Flutter 的环境搭配相对简单，而 React Native 的环境配置相对复杂，而且由于 node_module 的“黑洞”属性和依赖复杂度等原因，目前在个人接触的例子中，首次配置运行成功率 Flutter 是高于 React Native 的，且 Flutter 失败的原因则大多归咎于网络。

同时跨平台开发首选 Mac ，没有为什么。

二、实现原理

在 Android 和 IOS 上，默认情况下 Flutter 和 React Native 都需要一个原生平台的 Activity / ViewController 支持，且在原生层面属于一个“单页面应用”， 而它们之间最大的不同点其实在于 UI 构建 ：

• React Native ：

React Native 是一套 UI 框架，默认情况下 React Native 会在 Activity 下加载 JS 文件，然后运行在 JavaScriptCore 中解析 Bundle 文件布局，最终堆叠出一系列的原生控件进行渲染。

简单来说就是 通过写 JS 代码配置页面布局，然后 React Native 最终会解析渲染成原生控件，如 标签对应 ViewGroup/UIView ， 标签对应 ScrollView/UIScrollView ， 标签对应 ImageView/UIImageView 等。

所以相较于如 Ionic 等框架而言， React Native 让页面的性能能得到进一步的提升。

• Flutter ：

如果说 React Native 是为开发者做了平台兼容，那 Flutter 则更像是为开发者屏蔽平台的概念。

Flutter 中只需平台提供一个 Surface 和一个 Canvas ，剩下的 Flutter说：“你可以躺下了，我们来自己动”。

Flutter 中绝大部分的 Widget 都与平台无关， 开发者基于 Framework 开发 App ，而 Framework 运行在 Engine 之上，由 Engine 进行适配和跨平台支持。这个跨平台的支持过程，其实就是将 Flutter UI 中的 Widget “数据化” ，然后通过 Engine 上的 Skia 直接绘制到屏幕上 。

所以从以上可以看出：React Native 的 Learn once, write anywhere 的思路，就是只要你会 React ，那么你可以用写 React 的方式，再去开发一个性能不错的App；而 Flutter 则是让你忘掉平台，专注于 Flutter UI 就好了。

• DOM：

额外补充一点，React 的虚拟 DOM 的概念相信大家都知道，这是 React 的性能保证之一，而 Flutter 其实也存在类似的虚拟 DOM 概念。

看过我 Flutter 系列文章可能知道，Flutter 中我们写的 Widget ， 其实并非真正的渲染控件，这一点和 React Native 中的标签类似，Widget 更像配置文件， 由它组成的 Widget 树并非真正的渲染树。

Widget 在渲染时会经过 Element 变化， 最后转化为 RenderObject 再进行绘制， 而最终组成的 RenderObject 树才是 “真正的渲染 Dom” ， 每次 Widget 树触发的改变，并不一定会导致Ren