目录
# 背景
最近一段时间 Flutter 的技术热度非常高，各个大厂和很多开发者都在积极的学习并尝试。关于 Flutter 的科普文章已经非常多了，Flutter 的优点也不再骜述。本文会结合 Flutter 和 React Native 的实际项目中的遇到的问题，进行相对客观的对比，也指出一些现阶段 Flutter 的不足之处，避免大家踩坑。
# JS VS Dart
Facebook 最明智的一点就是让 RN 采用 JS 作为开发语言。因为 JS 拥有非常好的群众基础和较低的学习门槛，所以 RN 不仅可以吸引大量的前端开发者加入，而且可以和 React 社区形成正向互补，进一步巩固 Facebook 在前端领域的统治力。基本上所有合格的前端开发者都可以低成本的学习并使用 RN 进行跨端开发。Google 让 Flutter 采用 Dart 进行开发，可能是基于对未来的判断，希望 Dart 可以逐步取代 JS 成为前端的开发标准。实际上 Dart 的语法更接近原生开发语言，用 Java 或者 Swift 的开发者会更加喜欢。可以想象下，团队在进行技术选型的时候，必须要考虑招 JS 的开发者容易还是招 Dart 的开发者容易呢？
综上所述，这点上 RN 暂时胜出。
# 开发调试环境
我们团队同时做过 RN 和 Flutter 的开发项目，从工具链来说，两者都非常成熟、调试都非常方便。但是从开发环境的搭建来看，尤其是集成到已有 APP 项目中，RN 相对来说就容易太多了。我们为了让 Flutter 集成到已有 APP 中，做了大量工程化改造，甚至分别准备了 debug 和 release 两种开发模式。业务模块的集成打包方面，RN 也更加方便和灵活，可以按不同 GIT 库进行业务管理，打成不同的 jsbundle 分别集成。而 Flutter 开发需要集中式管理，在同一个 GIT 中进行维护。
综上所述，这点上 RN 暂时胜出。
# 原生混合开发支持
原生混合开发方面其实是 RN 的强项。由于 RN 的组件原本就是通过原生 UI 系统进行渲染，所以可以非常容易的实现在原生页面中嵌入 RN 的 RootView 或者在 RN 页面中嵌入原生 UI 组件，对已有 APP 上进行混合开发支持非常友好。而 Flutter 因为无论是在原生页面中嵌入 FlutterView 或者在 Flutter 页面中嵌入原生 UI 组件，都会有内存或者性能等不少问题。目前国内实践比较多的是闲鱼团队，也开源了 FlutterBoost 项目尝试解决这个问题，但是官方始终还没有非常完美的解决方案。所以 Flutter 更适合在全新 APP 上使用。
综上所述，这点上 RN 暂时胜出。
# 热更新支持
热更新一直以来都是 RN 框架的卖点之一，无论是微软提供的 CodePush 服务还是各个大厂自己搭建的热更新平台，例如国内京东、携程都有非常成熟 RN 更新平台。而 Google 则完全没有计划支持 Flutter 热更新功能，从目前了解的信息来看，京东 JDFlutter 在 Android 平台已经实现了热更新，但是实际效果和灵活程度还是远远不及 RN。而受限于苹果的限制，iOS 平台上没有一家公司真正意义上实现了 Flutter 热更新。开源项目 MXFlutter 通过 JS 开发的方式，曲线救国间接的实现了 Flutter 动态化。虽然是很有价值的尝试，但是抛弃 Dart 改为 JS 开发也会带来其他更多的问题。
综上所述，这点上 RN 暂时胜出。
# 全平台支持
其实无论 RN 还是 Flutter 都有相当大的野心实现全平台制霸。除了 Android、iOS 平台之外，RN 已经可以通过第三方工具支持 Windows UMP、Web、Desktop、macOS，甚至近期京东开源的 Alita 项目 已经实现 RN 到微信小程序的打通。而 Flutter 目前还不完善，虽然以已经官方支持了 Android、iOS、Desktop、Web，但是实际测试下来成熟度还不够，特别是 Hummingbird 还处于早期阶段，转换后 Web 的性能还达不到生产环境的要求。
综上所述，这点上 RN 暂时胜出。
# 开发者生态支持
RN 的 Github Star 已经达到了 80K，而且借助于 React 生态，有大量的第三方插件可以使用。微软、airbnb 等公司也贡献了大量高质量的插件，整个开发者生态非常完善和活跃。相比之下，Flutter 的生态刚刚处于早期阶段，虽然 Github Star 也已经有 72K，但是整体可用的第三方库的数量不如 RN。当然，我们也看到 Flutter 生态最近发展很快，Dart Pubs 上的公开库数量也日趋上升，基本可以满足一般业务的开发。
综上所述，这点上 RN 暂时胜出。
# 框架稳定性
从团队实际使用 RN 和 Flutter 框架情况来看，RN 经过 4 年的发展和不断迭代，目前的稳定性和兼容性已经有了很大的改善。Github 上 open issue 只有 500 多，而且国内不少大厂例如京东、携程等也在大规模使用中，整体上稳定性已经到达生产环境的要求。但是由于 RN 整体架构设计的限制，还比较依赖原生组件，所以随着 Android、iOS 的系统迭代，未来还是需要持续的完善稳定性和兼容性。所以我们也建议大厂在应用 RN 框架的时候，能有专门的原生团队维护和优化 RN 引擎，可以带来最大的收益。Flutter 的版本号已经快速迭代到了 1.7，不过实际使用中遇到的问题还是比较多的，性能和稳定性方面还有很长的路要走，更让人担忧的是 Github 上有 7000 多的 open issue。而且 Flutter 引擎部分大量 C 代码，比较晦涩难懂，一般团队很难去优化进行稳定性加固。
综上所述，这点上 RN 暂时胜出。
# Flutter 真的不如 RN 吗？
文章最后必须强调下，技术层面其实 RN 和 Flutter 没有孰优孰劣的对立关系，都是非常出色的跨端框架。虽然上面列了不少 Flutter 的问题，但是这些都不是不能解决的问题，而是处于早期阶段任何框架都可能遇到的问题。相反从整体架构设计和整体规划上来说，我认为 Flutter 比 RN 更加出色，属于下一代的跨端框架。我们可以预见到在几年后 Google Fuchsia 系统正式发布的时候，这才是 Flutter 可以大显身手的时刻。
但是目前阶段，RN 才是业内最成熟的跨端框架。