React Native、Flutter等，这些跨端方案怎么选？

前言：本文是对戴铭iOS课程的学习笔记，非本人原创。

为了一份代码能够运行在多个平台，从而节省开发和沟通成本，各公司都开始关注和使用跨端方案。目前，主流的跨端方案主要分为两种：

1. 一种是将JavaScriptCore当做虚拟机的方案，代表框架是React Native；
2. 另一种是，使用非JavaScriptCore虚拟机的方案，代表框架是Flutter。

使用跨端方案进行开发，必然会代替原有平台的开发技术，所以我们在选择跨端方案时，不能只依赖于某几项指标，比如编程语言的难易（学习成本）、性能、技术架构等，来判断是否适合自己团队和产品，更多地还要考虑开发效率、社区支持、构建发布、DevOps（开发和运维协同合作来自动化构建、发布和测试软件的流程）、CI（持续集成，即在源代码发生变更后自动检测、构建、拉取和进行单元测试的过程）支持等工程化方面的指标。

所以说，我们在做出选择时，既要考虑团队现状以及所选方案的生态，还要考虑技术未来的发展走向。

ReactNative方案的优势

跨端方案的初衷是要解决多平台重复开发的问题。也就是说，使用跨端方案的话，多个平台的开发者可以使用相同的开发语言来开发适合不同系统的APP。

React Native使用JavaScript语言来开发，Flutter使用Dart语言。这两种语言，对iOS开发者而言，都有一定的学习成本，而选择哪一种编程语言，其实决定了团队未来的技术栈。

JavaScript的历史和流行程度都远超Dart，生态也更加完善，开发者也远多于Dart程序员。所以从编程语言的角度而言，虽然Dart入门简单，但是长远考虑，选择RN可能会更好一点。

同时，从页面框架和自动化工具的角度来看，React Native也要领先于Flutter。这主要得益于Web技术这么多年的积累，其工具链非常完善。前端开发者能够很轻松地掌握React Native，并进行移动端APP的开发。

当然，方案选择如同擂台赛，第一回合的输赢无法决定最后的结果。

Flutter 框架的优势

除了编程语言、页面框架和自动化工具以外，React Native的表现就处处不如Flutter了。总体而言，相比于RN，flutter的优势最主要体现在性能、开发效率和体验这两大方面。

flutter的优势，首先在于其性能。

我们先从最核心的虚拟机说起吧。

React Native所使用的JavaScriptCore，原本用在浏览器中，用于解释执行网页中的JavaScript代码。为了兼容Web标准留下的历史包袱，无法专门针对移动端进行性能优化。

flutter就不一样，他一开始就抛弃了历史包袱，使用全新的Dart语言来编写，同时只是AOT和JIT两种编译方式。而没有采用HTML/CSS/JavaScript组合方式进行开发，在执行效率上明显高于JavaScriptCore。

除了编程语言的虚拟机，Flutter的优势还体现在UI框架的实现上。Flutter重写了UI框架，从UI控件到渲染，全部重新实现了，依赖Skia图形库和系统图形绘制相关的接口，保证了在不同平台上能够有相同的体验。

Flutter因为重新实现了UI框架，可以不依赖iOS和Android平台的原生控件，所以无需专门去处理平台差异，在开发体验上实现了真正的统一。

除了上面提到的在性能和开发体验上的优势，Flutter在开发效率上也有很大的建树。

凭借热重载（Hot Reload）这种极速调试技术，极大地提升了开发效率，因此Flutter吸引了大量开发者的眼球。

此外，Flutter 的学习资料也十分丰富，官方文档分门别类、井井有条，各种社区也是十分火热。

或许，你还会说，flutter包大小是个问题。Flutter的渲染引擎是自研的，并没有用到系统的渲染，所以APP包必然会大一些。但是，从长远来看，AppStore必然会对包大小的限制越来越小所以说这个问题一定不会成为卡点。

接下来说说Flutter对动态化能力的支持。

Flutter目前是没有动态化能力的，但是它计划会推出动态化能力。

实际上，我觉得动态化就是一个伪命题。软件架构如果足够健壮和灵活，发现问题、解决问题和验证问题的速度一定会非常快，再次发布上线也能够快速推进。而如果软件架构本就一团糟，解决问题的速度是怎么也快不起来的，即使具有了动态化能力，而从发现问题到灰度发布再到全量上线的过程也一定会很曲折。

其实，动态化这项技术产生的根本原因就是，能够及时修改APP中的页面或者功能。但是这项技术衍生出来以后，也带来了一些其他的好处，比如可以用来绕开Apple的上线审核。

如果你想通过动态化技术来解决发布周期不够快的问题的话，那你首先应该解决的是架构本身的问题。长远来看，在架构上的治理和优化所带来的收益，一定会高于使用动态化能力的框架。

当然，如果你选择具有动态化能力的框架，是抱着绕过AppStore审核的目的，那就不在本文的讨论范围之内了。

如何选择适合自己的跨端方案？

看到这，你一定在想，跨端方案可不只有RN和Flutter，还有小程序、Weex等框架。没错，跨端方案确实有很多。

但我今天所说的ReactNative，代表了以JavaScriptCore引擎为虚拟机的所有方案，对于这一类方案的选择来说，道理都大同小异。只要你打算转向前端开发，选择他们中的哪一个都差不多，而且方案间的切换也很容易。

着眼未来，决定跨端方案最终赢家的关键因素，不是编程语言，也不是开发的生态，更不是开发者，而是用户。

如果谷歌的新系统Fuchsia能够如谷歌所计划的五年之内应用到移动端的话，那么五年后即使使用Fuchsia的用户只有10%，你的APP也要去支持Fuchsia。Fuchsia系统的最上层就是Flutter，这时使用Flutter来开发APP就成了必选。而Flutter本身就是一种跨端方案，一旦使用Flutter开发成为团队的必选项，那么其他的技术栈就没有存在的价值了。

我们人还是蛮看好Fuchsia系统的。它的内核是Zircon，Fuchsia是整个系统的统称，在Fuchsia技术的选择上，谷歌选择了微内核、优于OpenGL高内核低开销的图像接口Vulkan、3D桌面渲染Scenic、Flutter开发框架。谷歌的打算是，三年内在一些非主流设备上对Fuchsia内核进行完善，待成熟后推向移动端。

Fuchsia架构分为四层，包括微内核的第一层Zircon，提供系统服务的第二层Garnet，用户体验基础设施的第三层Peridot，Flutter所在基础应用的第四层Topaz。结合Android系统的经验，在设计架构之初，谷歌就考虑了厂商对深度定制的诉求，使得每层都可以进行替换，模块化做得比Android更加彻底。

Fuchsia架构，如下图所示：

当然，不管操作系统多么牛，最后都还是由用户来选。

跨端技术方案的赢家是谁，最后还是要看使用移动设备的用户选择了谁。虽然我们不能决定未来，但是我们可以去预测，然后选择一款大概率会赢的跨端框架，以此来奠定自己的竞争力。

如果你们公司目前还是纯原生开发，正在考虑采用一种跨端方案，那么从长远来看，你可以选择flutter作为跨平台开发方案。但是Flutter最终能否成功，还是要看谷歌的新系统Fuchsia的成败。

如果最终Fuchsia失败了，而iOS继续突飞猛进，SwiftUI也支持跨端了，那你就不用换技术栈了，继续使用Swift开发就好。这其实是完全有可能的不是吗？

未来技术走向如何，我们拭目以待吧~