未来是属于Flutter的（基于2018年12月29日，我实在是怕杠精）。

为什么不推荐RN？简单来说，RN的实现原理制约了上限。

不想展开讲，可以搜一下RN和Flutter的对比，无论如何，JS的+底层交互的效率也是不会比图像引擎自己渲染好的。JS引擎的效率也不会比编译型代码引擎好。

但是工具是满足需求来定的。如果你需要热更新，你还真的需要RN，毕竟Flutter目前官方是不支持热更新的，听说有奇淫技巧满足了热更新需求，没仔细看。

技术是不断进步的，未来的事谁知道呢

ps:听说RN在重构，不知道会怎样，个人认为，JS始终是限制上限。虽说对前端友好，但是各位不觉得前端的任务太重了么？感觉以后世界上只有前端了

私以为，跨平台的未来是 Flutter，React 那套开发 web 还可以，套到原生里面问题多多，也可能是我没有完全深入使用，因为我的项目开始的时候（16年）调研过 RN，并且写了点 demo，最终还是选择了原生

不过 Flutter 的对跨平台的实现思路和我期待的比较一致，所以个人认为这一定是未来，当然未来肯定 Flutter，RN 都会共存很长时间，谁也说不准

但是跨平台绕不开的一个问题就是，和硬件接近的部分（相机，蓝牙，外设等）必须要使用原生开发，所以在跨平台的时候，楼主还需要对原生开发有了解

笔者一年多之前使用 React Native 开发过一款应用，虽然其性能确实接近于原生，但开发体验不太好。第三方库质量参差不齐，很容易掉进坑里，特别是有关原生功能调用的。生态系统发展缓慢，发布快四年之久，仍为 0.x 版本，还不能满足 1.0 版本的稳定性，近期 Facebook 又准备对 RN 进行大规模重构。另外，性能上在遇到手势、动画这些场景时，还是差强人意。

最近接触了 Flutter，并用它实际开发了一款应用，无论从架构、开发体验，还是性能上 Flutter 可以说完胜 React Native。Flutter 实现了自己的组件渲染层，不需要转换为原生组件，大大减少了跟原生系统的通信次数，并且使用 Platform Channels 来跟原生系统通信，性能比 JavaScript Bridge 快了几个数量级。Flutter 自带各种布局组件，支持行、列、网格、长条（Silver）等多种布局方式。Flutter 没有采用类似传统 CSS 那样基于规则的布局，因此避免了不同规则之间的相互影响甚至冲突，简化了布局，性能也更好。

与 Flutter 使用的 Dart 语言相比，除了生态环境，JavaScript 在语言设计上可以说全面落后。Dart 语言既支持 JIT 即时编译，又支持 AOT 预编译，兼顾了开发时效率（支持热加载）和运行时性能（编译为二进制代码）。Dart 语言是类型安全的语言，适合编写大型项目，重构代码时非常爽，同时在需要的时候也支持动态类型。当然 JavaSCript 可以通过 TypeScript 这样的外部编译器来支持强类型，但在使用体验上跟语言原生支持还是有很大差距的。

Flutter 的设计架构是革命性的，在 Flutter 出现之后，React Native 这类采用 Hybrid 架构的技术已经完全没有优势了。

如想了解更多，可阅读以下文章。

知乎有一个不好，啥东西最新出来就吹哪个，哪个小众就吹哪个。选型原则不是先考虑团队实力和项目规模？用flutter不先看看GitHub上那一堆堆issues？用rn有没有老手镇场子？还未来呢，以前吹出来的方案一堆堆，哪个是未来了

哦，对了，顺便一说，按照ant design圣蛋事件某些人的说法，你们先应该做的是把整个项目review一遍，233

小马过河

你自己试试

我觉得flutter真的好简单

当然有可能因为我是只大象

所以最好的方式还是你自己试试

我们项目在重构4.0版本的时候，有80%左右的代码都是RN代码，而且在线上稳定使用了一年多。最近我们也在考虑加入flutter，而且有一个实验的项目可以使用。

如果团队里面有大牛的话，我推荐都试试。如果没有，就纯原生就行了。

个人感觉，现在flutter的编程方式，代码很不直观，没有好的布局模板，全是靠dart手写布局。估计不到2.0，就会出现模板语言，不然的话。代码可读性、重用性、健壮性无从谈起。性能上，中高仿机型上看不出优势，中低端机型可以说非常流畅。至于插件，不是主要障碍。rn的插件不需要太大改动，就能用。长远看好，就是先把布局dsl搞出来。要是达到wpf的xaml就牛逼了。说到这里，倒不如直接用xamarin好了。。。

Flutter，太好上手了。

不论是 React Native 还是 Flutter 都可以用于开发跨平台应用，选哪个看你自身需求，但首先得了解清楚两者都是什么。

React Native 能够跨平台是因为它允许你使用 React/JavaScript/JSX 的写法写原生应用，而在底层他会替你调用相应的 iOS 原生组件或者 Android 原生组件，又或者直接生成适用于 Web 的 DOM 树。所以他做的事情是，用 JavaScript 调用对应系统渲染器进行渲染展示。

那么，Flutter 又是怎么跨平台的呢——Skia。当你使用 Flutter 框架（Dart）开发应用时，其底层渲染由 Skia 接管，没有什么 Android runtime、Chromium 或者其他中间层了，是的，Skia 的下层便是 CPU/GPU 了，一个受控的画布，基本上意味着你想画什么就画什么了，不再需要调用原生 Widgets，而这便是 Flutter 能够跨平台的原因。

除此外，还可以提供一些有用信息供你参考。

1. 谁更快：React Native 这种从使用 JavaScript 到解析调用 Native 的过程中间显然要经过多个环节，而 Flutter 里将 Dart 代码 AOT 编译为本地代码，所以 Flutter 应用是直接使用本机指令集运行，这就不涉及解释器这一层。关于 Flutter 为什么这么快 Google 的工程师在 Google I/O、GDD 以及刚结束的 D2 上都有介绍，这里贴一张图可以简要说明「Flutter 相比 Android 与 其他跨平台框架相比为何那么快」的原因，见[注1]。
2. 支持平台：React Native 支持 iOS/Android/Web 是毋庸置疑的，但 Flutter 现在还只能「成熟」的支撑 iOS/Android，即便上个月 Flutter Live 1.0 说到 Flutter for Desktop 以及 HummingBird，但这些都还处于初期，至少在明年 Google I/O 前还不能报有希望。
3. 渲染控制：React Native 做的时候是利用 JavaScript「调用」原生 Widgets，那么不同平台 Widgets 的差异势必使得 React Native 只能取两者的公共子集，「Write once, run everywhere」不假，但「Control every pixel on the screen」是做不到的；Flutter 不调用原生组件，相反，有一组自己的Widgets，而他们都由 Flutter 的 Framework 和 Engine 管理和渲染，按 Google 的话来说就是Control every pixel on the screen」，你不再需要因为不同端的差异而在实现上进行妥协[注2]。
4. 成熟/生态：Dart 生态相比移动端/前端生态远小的多，看看 Flutter Live 上那些截图就知道 Flutter (+Dart) 的开发人员也远不及 Android / iOS / Chromium 等平台的开发人员，是的，是远远不及，即便加上 Dart 相关开发人员。往外扩再想想社区，React Native 经过多年发展，其现在的社区规模或者是生态完善性都是 Flutter 近期根本无法追赶上的，虽然 React Native 依旧有不少「坑」。
5. 开发上手：是个前端开发就一定知道 HTML / CSS / JavaScript，但是用 Flutter 你需要学习一门新语言 Dart，而如果你的编程习惯不好或者不善于抽象，你的 Flutter 代码很容易一层套一层，like callback hell，所以你说哪个更容易上手呢？

Flutter 风光很足，且官方回应非常迅速（GitHub Issues），但生态远远没到成熟的地步，这对于资源有限的应用开发团队来说是很致命的，且现在在开发调试上还是有些痛苦的，比如无法准确定位错误堆栈等；但 React Native 为了达到跨平台而对 UI 上的一妥协与牺牲也是被人们所熟知的。

但如果说两边现在最让人期待的事情，Flutter 无疑是 Flutter for desktop 与 HummingBird，而 React Native 则无疑是 Facebook 正在进行的重构工作。现在说谁将最终获胜还为时尚早。

React Native 大家熟悉多一些，所以最后多安利一下 Flutter。Flutter 整体架构主要分三层[注3]：Framework，Engine 与 Embedder，前两层结构见下图。

1. Framework 是框架使用者需要直接面对的，包含文本/图片/按钮等基础 Widgets、渲染、动画、手势等。如果你写 Flutter 应用，那么大致可以理解为调用这些 package 然后再用 Dart 「拼装」些自己的代码。
2. Engine 使用 C++ 实现，这一层包含 Skia，Dart 和 Text。后两个不太熟，说说 Skia。这是一个二维图形库，提供了适用于多种软/硬件平台的通用 API，既是 Chrome，Chrome OS，Android，Firefox，Firefox OS 等产品的图形引擎，也支持 Windows 7+，macOS 10.10.5+，iOS8+，Android4.1+，Ubuntu14.04+ 等平台；Dart 包含 Dart Runtime 等（JIT/AOT），Text 则负责文字渲染部分。
3. Embedder 是一个嵌入层，做的事情是 Flutter to Platforms。比如渲染 Surface，线程设置，插件等。Flutter 的平台层很低，比如 iOS 只是提供一个画布，剩余的所有渲染相关的逻辑都在 Flutter 内部，而这就是 Flutter 所宣传的可以精准控制每一个像素的原因；但不可否认，对于插件部分，还是需要特定操作系统底层的建设（比如支付、地图等），而在 React Native 上（开发应用）则不需要相关背景。

关于 Flutter 更加详尽的介绍可见分享 让我们在2019年重新认识 Flutter

以上，供参考。

注1 (from What makes Flutter fast, Yuqian Li on D2)

注2：Google 的原话是「Flutter lets you control every pixel on the screen, and its powerful compositing capabilities let you overlay and animate graphics, video, text and controls without limitation.」

注3：Flutter 系统架构详情可见 https://docs.google.com/presentation/d/1cw7A4HbvM_Abv320rVgPVGiUP2msVs7tfGbkgdrTy0I/edit#slide=id.gbb3c3233b_0_162

在公司开发React Native项目已经两年了，期间遇到了无数的坑，最后产品成型上线，里面包括聊天+日程管理+报表+地图定位+通知+...几乎所有的功能都塞了进来，这也是国产APP的特点。。

期间遇到的问题，到现在唯一还成为问题的，就是FlatList的大列表性能问题，最近上了一个用户，一个列表80000+的联系人，由于右侧有个ABCD...XYZ的滑动条可以快速定位，Cell里面还有头像，导致这个页面卡的不要不要的。。只有这一个还在攻克中。。其他都搞定了。

看了不少人说UI一致性的问题，RN官网提供的组件我们基本都没用，我自己写了一套导航条+ActionSheet+拍照/从相册选择/录视频+Picker选择+...，这些都是用Javascript写的，不涉及原生，双端UI也都一致。在RN中，界面想要做到一致性，就看你下不下功夫了，什么都用官网的还考虑啥一致。。(已在Github开源)

而且在开发过程中，用的地图组件、WebView、Echart、环信IM的SDK，都有不同的问题，比如地图经常这个设备崩了、那个设备定位飘了，WebView+Echart两个就出问题，环信IM根本没RN的SDK，都可以解决，还对开源社区做了微不足道的一些贡献。

总之，开发过程中的任何坑，都是能解决的，前提是你得有时间。

再说说Flutter，发布1.0我就开始关注了，然而Dart语言实在是不友好，很奇怪为什么不直接用Javascript，或者Typescript也可以啊。。Dart写出来的程序总觉得怪怪的。。

另外有头条好友在项目中开始使用Flutter，说不支持热更新，这个我觉得大部分大公司可能无法接受吧，当然个人开发者无所谓了。。还有调试断点经常断不到，崩了完全靠人品猜。。当然Flutter的优点很多人都说了，一致性+速度快，这个我觉得对RN来说不是绝对的优势，一致性RN也能做，速度快大家都是60，RN的Debug略卡，Release很正常，也没慢到哪去。

最重要的问题是，公司选型Flutter怎么招人。。选RN可以招前端的，可以招iOS的，可以招Android，实在没人Node.js也能来。。这个问题我觉得很重要，经常面试的都知道招个靠谱的有多难。。RN适合大公司大项目，招人省心很多，Flutter适合小项目，自己开发就可以搞定的。。

另外，其实这两个要是开发到复杂的功能，都是要走到原生的，iOS和Android，你至少也要懂一个吧，一个都不懂肯定觉得坑多。。

所以，选什么完全是看你的需求，我想说的是，做RN将来中年危机了还能混个前端或者Node.js后台的活。。做Flutter可以35岁以后尝试面试Google去。。

补充：大列表的问题已经解决了，不是RN自己的问题，是我们列表每一项都要通过imId查询用户信息，然后我们管理用户信息的地方之前只用了code字段做索引，查imId字段需要find，每个cell分成几个小部分，每个部分都查一次，然后就这么华丽丽的卡了。。当然还有别的地方卡，通过修改数据结构，增加索引，干掉JSON.parse(JSON.stringify(obj))之类的导出函数，干掉Object.values()，减少filter/forEach/map等遍历全部数据的操作，也做到大页面2秒以内出来了，再加个加载视图，就OK了~

Flutter跟好友又聊了一下，除了热更新，目前也只适合写UI，适用于功能不复杂的小型项目，大公司目前也只是尝试。头条某一款产品的视频播放页改用flutter了，我问他你们做了哪些部分，他说上面的播放器原生的，浮动点赞评论的视图原生的，也就横向滚动用了用flutter，好无语。。

再补充：这个项目是toB项目，80000+联系人的问题，是一个大公司要求的定制化项目，人家公司人就这么多，还是很有名的公司，要是能分页我早就分页了。。最后优化的加载速度可以了，但是内存爆了，正常启动运行是50-150MB内存吧，选择人员页面进了两层就400-800MB了，简直恐怖。iPhone 6S及以下会崩溃，X没问题。。Android还没测，估计内存小于2G的是肯定崩了。。

我：现在就这个情况，能看到全公司数据的就有管理层吧，其他人都是看到权限内的小部门人员，不会崩的。

产品经理：这样不行，演示就在人家高管手机上，万一买的不是高仿旗舰呢。。

我：能不能出钱帮他们买一个手机用于测试。。

最后，由于改内存问题要改整个通用选择页面的架构，两周后要演示，还有沟通IM大模块没做完呢。。于是决定让另外一个同事用react-native-sqlite-storage写了。。然后原来在内存里的同步查询和其他操作都要改成Promise异步调用，也想吐血。

大中午休息，过来写点废话。。考虑了一下如何选择框架的问题，感觉应该有如下的因素(面向搬砖的同学)：

• 公司的招聘：包括市场上候选人多不多，价位多少，公司能不能招到水平正常点的人，等等HR因素，这个其实我觉得是第一个要考虑的。
• 框架的生态：包括很多常用的第三方库都存不存在，有没有人维护，Bug多不多。框架自己倒是都差不多，要是快死了的框架我估计你也不傻。。比如下面的库有没有：
• 微信SDK
• 扫一扫
• 拍照、从相册选择、录像
• 百度/高德地图SDK
• 统计分析：比如友盟、GrowingIO等类似的，我就用过这俩。。
• Echarts报表
• 沟通聊天SDK：比如网易云信、环信等。。
• 权限管理
• 模态对话框
• 音视频播放
• 简易动画效果
• 网络库，包括下载、上传、断点续传、Session等等功能。。
• 文件系统库，包括读写、拷贝、删除、获取文件信息等等功能。。
• 。。。
• 设备适配：这个也很重要，很多人跑了个Demo就觉得适配很好，一点不卡，没Bug，实际上了生产环境多半要跪的。先考虑下面适配因素吧，不光是框架的适配，还包括上面的第三方库，否则估计开发过程中全给第三方库改bug了，比如我这样的苦逼搬砖：
• iPhone 4S iOS 8.1：能跑不。。
• iPhone X：全面屏支持不。
• iPad：大屏展示啥样子，没有iPad需求可以忽略。
• 有没有iOS横屏要求，这个也很重要。
• Android：华为、小米、Oppo、Vivo
• 上面四个几乎必须支持吧，从6.0到9.0，包括荣耀红米等机器，都测过没，还有一堆安卓全面屏，Bug比你想象的会多很多很多很多，就这四家Android就能疯了。。还有一大堆其他厂商的，比如一加、三星、魅族、联想、360、锤子。。说到360等测过就知道了，bug无比的多，还有虽然有已经凉了的，但是还有存量，说不定你客户就用呢。。
• 开发速度：应用开发速度快不快，维护起来方便不，这一点原生是比不上跨平台的。模块化Flutter我不清楚，但是RN已经有React证实了，npm一个一个模块封装的很方便。

继续搬砖了。。

看历史知未来——GTK+，wxWidget，Qt，这三那个最酷炫，哪个最好用，哪个生命力最强？

显然是完全direct ui + 魔改C++的Qt。

flutter就是移动端的Qt（skia渲染 + Dart），RN和weex大约就是移动端的wxWidget（原生组件 + js）。

所以长远看，我选flutter。

ps：比较一下Qt移动端和桌面端的表现，移动版Qt quick是不配称作“移动端Qt”的，这个称号还是让flutter来继承吧。

要是flutter能用typescript开发，那生态就会好很多了，生态真的的太重要了，很多库都没有，目前谁敢折腾。别看闲鱼天天吹flutter，那是因为有Google的人直接面对面提供技术支持。

为啥没人基于 Skia 写一套 JS 的实现呢？

flutter太年轻了，热更新都不支持.

flutter 安卓运行非常完美，但是苹果运行非常非常烂.

谷歌新系统优化非常厉害，苹果系统优势会丢失，特别许多flutter应用 谷歌系统优于苹果的，苹果没有价格战基因.

当然苹果不会让这些事情发生一定也会出一个类似的.

react再次成为两个跨平台的壳，当然有最大可能性彻底丢弃js，ts和dart假丢弃.

会有一个类似react的壳吧，我们需要一个xamarin，但不是xamarin.

RN就是一坨屎！

第一个月: 写UI爽翻天！

第二个月:

iOS工程师: Android 为啥这么蠢？

Android工程师: RN为啥这么蠢？

第三个月:

iOS工程师: 我写的code这么屌，为啥你们Android还老是出问题？

Android工程师: 这错误日志是个啥？

第四个月:

iOS工程师: ……

Android工程师: 改个bug还尼玛得cherry pick一个RN的commit重新build？

第五个月:

Android工程师: 我们要升级RN！不然Accessibility没法搞！

iOS工程师: 天天就你事儿多，升级了我们咋用？

嗯。。。这个问题十分不好回答啊(捋下鱼须)。闲鱼作为flutter领域的先驱者，以及fish_redux、flutter_boost等当红flutter库的作者，当然是欢迎广大的开发者多多使用flutter相关技术栈 逃~:)。咳咳，不过呢，我们还是正经得聊一下React Native(下面简称RN)和flutter之前的异同：

0x00 简单介绍一下

React Native

React Native是Facebook开源的一款基于react思想、使用JS、能够给移动平台带来native般体验的框架，官网最新的版本是0.5.9。

flutter

flutter来自Google，上层使用dart语言构建跨平台应用，通过平台相关的embedded层接入到使用c++编写的engine层，再通过skia库直接与GPU进行交互。通过对dart代码的AOT编译，拥有优异的计算(CPU)、渲染(GPU)性能。官网最新的版本为1.2。

0x01 跨平台性

开发者们使用跨平台技术栈，首要的目的是为了能够省事儿，所以跨平台能力是首先要被衡量的指标。

Build native mobile apps using JavaScript and React

这意味着开发者可以复用庞大的JavaScript生态和优雅的react思想来书写RN的代码，给开发提供很多的便利性。

从实现原理上来说，RN进行完排版之后会把最终的渲染交给native view，这种方式带来的是如native般的UI性能，但同时也给给平台一致性带来了一些问题。除开渲染层的不一致，在iOS和Android没有使用同一个JavaScript虚拟机也会带来一些暗坑。

手势的处理上两个平台不好统一，RN官方也没有提供一个抹平差异的库，虽然开源社区有react-native-gesture-handler。

Beautiful native apps in record time

flutter官方的口气很大，说自己是”空前“的。是不是”空前“，我们得来评估一下。

编程语言层面，flutter使用dart语言构建应用，这门语言对大多数人来说应该是比较陌生，好在dart的语法并不复杂，与Java等强类型oop语言非常相似，还加入了函数式的特性，使用起来还是挺方便的。

flutter提供类似React思想的响应性UI编程模型，让UI开发变得更加fancy。

原理上来说，flutter在各个平台上使用统一的vm(dart vm)，自带GDI(skia)。skia是一个已经发展多年成熟度相当高的2D图形库，也是Android系统和Chrome一直在使用的图形库。

flutter从逻辑计算到渲染绘图，都是自己的，使得它在跨平台一致性上有良好的表现。dart提供的AOT特性也可以保证应用在线上有一个好的性能表现。

多平台支持

RN目前支持iOS和Android两个平台，另外有个非官方的ReactNativeX的项目旨在让RN运行到其他平台。

flutter早期支持iOS和Android，desktop的支持目前尚不完善。近期flutter团队发布了Hummingbird，旨在让flutter编写的应用可以运行在浏览器端。

从多平台支持的角度看，两边差距不大。相比RN，flutter在desktop的支持上有些优势，但目前都是不怎么可用状态。

0x02 开发便利性

工具链

RN在打包发布方面有被前端广泛使用的webpack支持，官方自己提供了基于浏览器的debug工具，与前端同学管用的调试方式并无二致。

flutter基于iOS和Android已有的打包工具添加了flutter产物打包功能，同样debug工具也由官方自己提供，除了刚发布的基于浏览器的调试工具外，flutter团队提供的调试工具可以直接在Android Studio或者VScode这类IDE上直接使用。

调试便利性

JS的调试方式已经很成熟了，这里不多做展开。 flutter在debug阶段可以使用集成于IDE插件中的hot reload功能做到亚秒级的新代码加载速度，十分适合与设计师坐在一起结(ya)对(li)编(tiao)程(shi) ：）。

第三方库

在RN上你可以使用JS的大部分库，平台相关的plugin也相对丰富。

flutter在这方面稍显欠缺，库的数量上无法与JS生态相比较。flutter/plugins项目提供了大量的平台相关插件供开发者使用，倒也是满足了日常开发的需求，另外dart pubs上的公开库数量也日趋上升。

在混合开发和大型app业务框架上，闲鱼技术开源的flutter_boost提供了与native混合开发的可能，而fish_redux使得大型app中的复杂页面的开发在flutter中变得更加容易。

0x03 未来的发展

开发者选择一个技术，都是压了”身家性命“在上面，谁也不想刚入门就发现这门技术即将被淘汰。

RN是个很好的项目，在发布之初给移动开发带来了一阵旋风。但不得不说，Airbnb宣布放弃使用RN技术栈对于整个社区有不小的打击，而文章中对原因的阐述也相当有说服力。

flutter在1.0发布之后趋于成熟，被钦定为Google Fuchsia系统的应用层框架。从团队2019 roadmap中可以看到，flutter当前重点在于完善一些现有功能上的细节与bugfix，另外对于广受期待的动态化特性，flutter团队也在开发code push功能。从flutter团队目前的方向和笔者在闲鱼开发中实际使用的flutter的感受来看，整体上flutter在框架层面目前已经基本上稳定。

从桌面端跨平台框架发展的历程来看，Java GUI从最初使用peer(对等设计模式)的AWT，到基于Java图形绘制接口性能巨慢无比的Swing，再到公认性能最好目前应用最广泛的基于目标平台绘制接口的SWT，我们可以从中窥见一些历史规律。

peer(对等设计模式)，即AWT中的一个控件，对应目标平台(如Windows)上的一个控件(是不是看起来跟RN有一些相似)，最终AWT被放弃是因为peer模式传输层级过多造成效率低下，GUI部分为了保证可移植性只能保留各个平台公共的接口。

SWT与QT(另一个被广泛使用的桌面端跨平台GUI框架)，牺牲了一部分可移植性(主要是因为直接调用了目标平台的图形绘制接口)，带来了GUI的高性能。flutter也采用了类似技术栈，skia来抹平各个平台的绘制接口差异，并向上提供统一的图形接口。

从这个角度来说，无疑flutter可能会是一个更有未来的跨平台框架。

0x04 写在最后

当然Facebook官方对于RN正在进行重构，包括把大部分逻辑移动到c++层来减少线程切换的开销提升性能等。

选择一个框架需要考虑的实际情况比框架的优劣比较更加重要，比如你的项目大小、开发人员构成等， RN和flutter作为目前移动平台上炙手可热的框架，两者并不是孰优孰劣的对立关系。

纸上得来终觉浅，如果你是个对新技术感兴趣，抑或是希望在移动平台上有所突破的开发者，何不尝试一下Google最新的成果咧？

*对flutter内容感兴趣，欢迎关注“闲鱼技术”微信公众号，数十篇精品文章等着你哦～

小项目用react native的expo框架，写的还是很爽的，自带热更新，每周甚至每天都可以迭代…

其实看个人开发习惯，如果你是前端的话，React Native 对你可能更友好一些。

如果你是 App 端开发，Flutter 可以更舒服一些。

当然都作为响应式开发，无论 React Native 还是 Flutter 都是存在一定相似之处的，坑的话也都多多少少会有，但是性能上而已 Flutter 无可质疑会更好。

更多可以查看我写过的一些文章：

或者通过我github项目体验一下，目前均有apk提供下载测试。

个人认为，抛开两个技术的生态不说，直接看技术，Flutter在流畅度，执行效率上更有优势，同时也更吸引人

首先，React Native使用了React，通过虚拟DOM的方式，先生成dom树，再传递给原生，原生再对虚拟dom树进行解析，通过原生UI来组织真正的UI并渲染出来，这种方式始终是经过了好多层级的，虽然RN的方式比之前的跨平台技术性能更好，但终究是绕不过一层层封装带来的效率问题。

Flutter最大的改进是直接用自带的绘图引擎来渲染，在UI上达到了更高的流畅度，可以AOT编译，也完全避免了JavaScript在很多人映象中的效率低下。

我们对比一下最开始内嵌WebView的跨平台方式和RN，其实RN在技术上是比WebView的方式改进了一大步，RN使用了原生的UI来渲染，页面的流畅度大大提高，而Flutter在RN的基础上（虚拟DOM到原生UI，原生再通过图新引擎渲染），直接实现了从Dart代码就通过图形引擎渲染。在此基础上，再加上AOT，可以看出，Flutter执行效率肯定优于RN。

再说到React Native重构的事情。由于RN的实现方式就是通过虚拟DOM再桥接到原生UI，即使重构，也不会改变RN技术本质的实现方式，所以重构在技术方面来说，可以达到框架更优化的效果，但是和Flutter任然是有本质的差距的。

两个技术对比下来，更推荐使用Flutter，因为它是运行效率更高，更有技术优势的技术

不过目前RN社区发展以及比较成熟，比如Expo，以及有了很多可用的原生功能封装，甚至包括WebGL的实现，AR的扩展，在这方面，Flutter还需要时间。如果是只想快速的开发普通App，那么目前的情况下，RN是更好的选择。

RN大厂纷纷弃坑

flutter和swiftui 这两个解决方案有点殊途同归，代表了google和apple对未来趋势态度

选flutter