跨平台方案的历史发展逻辑

跨平台开发的背景

如果使用原生方式开发APP，就要求我们必须针对iOS和Android这两个平台分别开发，这样的话，我们就需要用不同的语言去实现同样的功能，并承担因此带来的维护任务，这对于企业而言，付出的成本和时间会成倍增加。于是，跨平台的的概念走进了我们的视野。

本质上讲，跨平台开发是为了增加业务代码的复用率，减少因为要适配多个平台所带来的工作量，从而降低开发成本。一套代码多端使用，这样也能够保证一致的用户体验。

“一次代码，到处运行”。二十多年前Java正是以跨平台特性的口号登场，击败了众多竞争对手。这个口号，意味着Java可以在任何平台上进行开发，然后编译成一段标准的字节码后，就可以运行在任何装有Java虚拟机（JVM）的设备上。虽然现在跨平台已经不是Java最大的优势（而是它繁荣的生态），但不可否认，当年它打着跨平台的旗号横空出世确实是势不可挡。

而对于移动端开发而言，如果能实现“一套代码，多端运行”，这样的技术势必会引发新的生产力变革。在目前多终端时代的大环境下，可以为企业节省大量的人力资源，进而带来直接的经济效益。

跨平台开发方案的三个时代

<一>Web容器时代

web时代的方案，主要采用的是原生应用内嵌浏览器控件WebView（iOS为UIWebView或者WKWebView，Android为WebView）的方式进行HTML5页面渲染，并定义HTML5与原生代码交互协议，将部分原生系统能力暴露给HTML5，从而扩展HTML5的边界。这类交互协议，就是我们通常说的JS Bridge（桥接）。

这种开发模式既有原生代码，又有web应用代码，因此又被称为Hybrid开发模式。

由于HTML5代码只需要开发一次，就能在多个系统运行，因此大大降低了开发成本。并且Web开发技术的社区和资源都十分丰富，因此开发效率也比较高。但是，一个完整的HTML5页面的展示要经历浏览器控件的加载、解析和渲染三大过程，性能消耗要比原生开发增加N个数量级。

Hybrid开发方案，有其优势也有其缺点，总体而言，瑕不掩瑜。实际上，Hybrid开发方案是跨平台历史上最成功的例子！

最后，给一张Hybrid开发框架的流程图吧：

<二>泛Web容器时代

Web容器方案具有生态繁荣、开发效率高、跨平台兼容性强等优势，但是它最大的问题在于承载着大量Web标准的Web容器过于笨重，以至于性能和体验与原生有较大差距。

而在实际的产品功能研发中，我们通常只会用到Web标准中很小的一部分。面对这样的现实，我们很快就想到：能否对笨重的Web容器进行功能裁剪，在仅保留必要的Web标准和渲染能力的基础上，使得友好的开发体验与稳定的渲染性能保持一个平衡？

答案当然是可以的。

泛Web容器时代的解决方案优化了Web容器时代的加载、解析和渲染这三大过程，把影响他们独立运行的Web标准进行了裁剪，以相对简单的方式支持了构建移动端页面必要的Web标准；同时，这个时代的解决方案基本上完全放弃了浏览器控件渲染，而是由原生接管绘制。也就是说，将原生系统作为渲染的后端，为依托于JavaScript虚拟机的JavaScript代码提供所需的原生UI控件的实体，因此最终都是通过原生系统来进行渲染的。

泛Web时代的代表框架有React Native、Weex等，其框架如下：

<三>自绘引擎时代

泛Web容器时代使用原生控件承载界面渲染，固然解决了不少性能问题，但是当原生系统版本以及原生API变化的时候，我们需要处理不同平台的原生渲染能力的差异、修复各类奇奇怪怪的Bug。

而这一时期的Flutter则开辟了一种全新的思路，即从头到尾重写一套跨平台的UI框架，包括渲染逻辑，甚至是开发语言。

• 渲染引擎依靠跨平台的Skia图形库来实现，Skia引擎会将使用Dart构建的抽象的视图结构数据加工成GPU数据，交由OpenGL最终提供给GPU渲染，至此完成渲染闭环，因此可以在最大程度上保证一款应用在不同平台、不同设备上的体验一致性。
• 而开发语言选用的是同时支持JIT（JustInTime，即时编译）和AOT（AheadOfTime，预编译）的Dart，不仅保证了开发调试效率，也提升了执行性能。

因此，Flutter不仅可以减少不同平台间的差异，而且还可以保持和原生开发一样的高性能，正因如此，Flutter成为了目前最受关注的框架。

自绘引擎开发框架的原理图如下：

该选择哪一类跨平台开发方案

在不同角度上来看，三个时代的跨平台方案代表们在开发效率、渲染性能、维护成本以及社区生态上各有优劣，如下图所示：

我们在做技术选型时，可以参考以上维度，从开发效率、技术栈、性能表现、维护成本以及社区生态来进行综合考虑。比如，是否必须支持动态化（动态化指的是，代码逻辑放到云端，以下发的方式更新应用程序的原本功能）？是只解决Android、iOS的跨端问题，还是也要包括Web？对性能要求如何？对多端体验的绝对一致性和维护成本是否有强诉求？

从各个维度综合考量，Flutter和ReactNative无疑是最均衡的两种跨端方案，而其他的方案或多或少都“偏科”严重。

• React Native依托于Facebook，经过4年多的发展已经成长为跨平台开发领域实际的领导者，并拥有较为丰富的第三方库和开发社区。
• Flutter以挑战者姿态出现在我们面前，可以提供更彻底的跨平台解决方案，再加上Google的强大号召力，Flutter的未来可期。

那么我究竟是选择ReactNative还是Flutter呢？

对于知识学习而言，这两个应用层面的框架最好都学。Flutter作为后来者，其实它从RN社区借鉴了不少的优秀设计，很多概念两边都有对应，比如RN的component和Flutter的widget、Flex布局思想、状态管理和函数式编程等等，这类的知识都是两个框架通用的技术。未来也许还会出现新的解决方案，老框架也会不断更新，只有掌握核心原理才能真正立于不败之地。

对于实际项目而言，这两个框架都已经达到了大面积商用的标准。综合成熟度和生态，目前而言RN略胜于Flutter。所以如果是中短期的小项目的话，目前选择RN可能会更好。但是作为技术选型，我们看的要更远一些。Flutter在设计理念、渲染能力的一致性以及性能表现上，与RN相比都优势明显。

此外，Flutter的野心不止移动端。前段时间，Google团队已经完成了Hummingbird，即Flutter的Web官方Demo，在桌面操作系统的探索上也取得了一定进展，未来大前端技术栈是否会由Flutter完成统一，值得期待。

小结

在不同的平台上开发和维护同一个产品，所付出的成本一直以来都令各企业头疼，于是各类跨端开发方案应运而生。从Hybrid开发的Web容器时代，到以RN、Weex为代表的泛Web容器时代，再到以flutter为代表的自绘引擎时代，这些优秀的跨平台开发框架们慢慢抹平了各平台的差异，使得操作系统的边界越来越模糊。

另外需要补充的一点是，Flutter在实际上本身是不支持热更新的，但是我们可以另辟蹊径的。比如，我们可以将一些常见的活动封装成模板，让后端配置不同的模板就可以实现动态化了。另外，业界已经有一些通过JSCore实现的Flutter动态布局的实践了，预计不久就会有一些成熟的方案出现。