从 React Native 到 Flutter，移动跨平台方案的真相

做者：LeanCloud 郑鹏

2018 年 12 月，Google 发布了 Flutter 1.0 正式版，彷佛再次点燃了人们对移动跨平台开发的热情。上一次出现相似的状况，是在 15 年年初，Facebook 发布 React Native 的时候。四年不到的时间里，有两家大公司相继推出了本身的移动跨平台方案（固然还有 16 年的时候，微软收购了 Xamarin，不过没有前两个那么引人注目罢了），同时这些方案也受到了市场的追逐。这些现象，彷佛预示着，跨平台开发才是移动开发的将来，或者说，跨平台开发才是一种更好的开发方式。

既然它是热点，那确定有能够讨论的地方。不过，在说 React Native 和 Flutter 以前，我以为要先谈一谈「跨平台开发」。

移动跨平台方案

那什么是「跨平台开发」呢？

一般意义上来讲，若是你想在 iOS 以及 Android 系统里，提供有相同内容的 App，那么使用 Apple 提供的构建工具，开发一个 App，而后上架到 AppStore，同时使用 Google 提供的构建工具，开发一个 App，而后上架到 Google Play。这两个 App 的实现，除了使用的工具不一样以外，大部分业务逻辑是相同的。你能够发现，在这个过程当中，产生了「重复」。

在重构时，若是项目里有大量的重复代码，或者重复逻辑，咱们通常会将这些代码或逻辑以函数，模块或库的形式作封装，这个过程最大化的消除了重复的代码，最终达到简化项目的代码这一目的。

因此在我看来，「跨平台开发」也是基于这个思想而产生的，人们想要一套减小甚至不用写重复逻辑的解决方案，而后市场给予了人们指望的方案。跨平台方案的最大特色，能够用 Sun 当年在推广 Java 时，所使用的一句口号：”Write once, run anywhere” 做为总结。这一句话，也被现在的 React Native 以及 Flutter 引用或继承。

React Native

React Native 是由 Facebook 所主导的跨平台方案，得益于 Javascript 以及 ReactJS 的流行，React Native 在推出时，便受到了大量的追捧。除了跨平台的特性，React Native 最大的特色就是，可使用 Javascript 来构建移动应用，而且最终应用的表现形式，能够作到和使用原生开发套件开发的应用相差无几。

React Native

React Native 能作到这些的核心原理就是 JavaScriptCore，一个 JavaScript 虚拟机。经过 JavaScriptCore，Javascript 能和其它语言互相转义，同时 JavaScriptCore 能运行在 iOS，Android 以及其它平台上，这些可能性放在一块儿，就成为了 React Native 的基底。有了这个基底以后，Facebook 便在这个基础之上，封装了各平台的应用层接口，定义了 Javascript 和封装后的接口之间的通讯协议，最终，实现了使用 JavaScript 在不一样平台开发具备原生体验的应用。

从实现原理以及架构上来看，React Native 彷佛是一个不错的跨平台方案，只要封装好各平台的 API，那么咱们有理由去相信，人们可以使用 React Native 开发出品质优秀的应用。可是事实上，理想和现实，仍是有差距的。在 18 年，Airbnb 以及 Udacity 相继发表了博文，声明全面放弃 React Native，转向原生应用的开发。他们在文章中，提到的最多的就是，React Native 是一个不成熟的方案，虽然它有许许多多的优势，可是这些并不足以去弥补它的缺点带来的损失。AirBnB 以及 Udacity 多是由于各类预期的理由而放弃了 React Native，不过在我看到 Discord 团队发表的 Why Discord is Sticking with React Native 博文后，算是完全打消了我在生产环境使用 React Native 的念头。整篇文章看下来，让 Discord 团队仍然继续使用 React Native 的最大缘由，彷佛就是项目已经使用了它，骑虎难下了。

JavaScriptCore 的局限性，Facebook 在项目管理上的不成熟，以及不断出现的放弃声明，最终让人们发现，React Native 是一个有趣的方案，但并非一个成熟稳定的方案。

Flutter

就在 React Native 的人气不断下跌的时候，Google 在一个恰到好处的时机，推出了一套跨平台方案：Flutter，将人们的目光再次汇集到跨平台开发上面。

Flutter 使用 Dart 这门较为冷门的语言来作开发，底基引擎主要由 Skia 和 Dart runtime 构成。Flutter 经过 Skia 和各平台的底层图形库对接，同时提供丰富的基于 Skia 的控件，来实现跨平台的开发。React Native 采用的方式是封装各个平台的应用层接口，而 Flutter 则直接打造了一套跨平台的应用层的开发套件。对这两种不一样的方式，咱们能够有一个直觉上的判断，Flutter 在性能上是要优于 React Native 的。由于 Flutter 的这种实现方式，其实早已被大量并普遍的使用了，最明显的例子就是游戏引擎。

种种对比和迹象代表，彷佛 Flutter 是一个比 React Native 更好的跨平台方案。目前 Flutter 仍旧处于一个上升的势头，也有如阿里巴巴这种大厂给 Flutter 背书，颇具野心的底基框架让开发者有理由相信，只要投入足够的人力，Flutter 能够作到和原生开发同样好。

然而，Flutter 的缺点，也是源于它自行打造了框架，在不少平台特性上，诸如密码管理，选择光标等，Flutter 目前并不能支持，将来可否支持也要打上大大的问号，平台的特性可能和原生组件深度绑定，且目前没有其它接口，因此 Flutter 在如今这种状态下，只能是放弃这些特性的支持。须要提一点的是，React Native 在这方面没有太大的问题。

尽管有一些问题，不过 Flutter 表现出的潜力，仍是让人们以为，这是一个值得一试的方案，只要 Google 给予足够的支持。因此 Google 会吗？

结语

那么，我该选择哪一种方案呢？答案：It depends on you.

事实上就是，没有一个完美的方案，任何方案都有利弊和取舍。想使用 Javascript 开发应用，那么就使用 React Native；想构建高性能的跨平台应用，Flutter 是个不错的选择；想最大化平台特性，那天然是原生的开发方式。

除了跨平台方案之间的比较以外，跨平台方案也在和原生开发方式竞争，并且这种竞争每每是不平等的，跨平台方案在新特性的支持上，始终要慢于原生开发方式，因此在市场占有率方面，原生开发方式就有自然的先发优点，这种差距很难被抹平。最终，你可能会发现，也许原生开发方式才是最合适的，由于除了「重复」外，原生开发方式相比跨平台方案，没有其它缺点了。

附记：以前我在 2019 年 3 月的 RTC Dev Meetup 北京站交流过上面的想法，感兴趣的读者能够查看演讲视频和 slide。

题图：Chris Sabor