阿里的大佬们曾总结，「一般来说，跨端技术有 4 类场景，别离是跨设施平台（跨Web端和手机端）、跨操作系统（如跨Android和iOS）、跨App以及跨渲染容器。」

而其中挪动端的跨平台技术始终以来都是很炽热的话题，在当初都不看好客户端技术天花板的背景下，客户端的将来仿佛在逐步朝着跨平台方向歪斜。

跨平台计划的劣势非常显著，对于开发者而言，能够做到一次开发，多端复用，一套代码就可能运行在不同设施上。这在很大水平上可能升高研发老本，同时可能在产品效力上做到疾速验证和疾速上线。

然而，挪动端的跨平台技术并不是仅仅思考一套代码可能运行在不同场景即可，还须要解决性能、动态性、研发效率以及一致性的问题。

性能： 如何通过前端和客户端的联合，实现更优的渲染性能以及交互性能;

动态性： 客户端怎么可能实现更低成本的发版、甚至不发版间接动静更新代码；
研发效率：如何晋升不同客户端的动静调试之类的研发效率；

一致性： 如何实现一份代码的多端部署，并保障代码在多个客户端内展现状态的一致性以及兼容性问题。

现在，也曾经呈现了如WebView、React Native、Weex、Flutter、小程序等泛滥的挪动端跨平台框架。然而行业内统一呈现出群雄争霸的局势，并没有哪一种框架能够真正上说能给完满解决以上的问题，同时博众人之所长，一超多强。

1 WebView

WebView简略来说就是用来展现HTML的容器，用官网的话讲，叫做：

A View that displays web pages. This class is the basis upon which you can roll your own web browser or simply display some online content within your Activity. It uses the WebKit rendering engine to display web pages and includes methods to navigate forward and backward through a history, zoom in and out, perform text searches and more.

来给大家翻译一下：

用来显示网页的视图。 这是用来运行你本人的Web浏览器或只再在利用中显示一些线上内容的根底。 它应用WebKit渲染引擎显示网页，并包含在浏览历史中导航，放大和放大以及执行文本搜寻等办法。

所以简略来说，WebView就像是一个浏览器，可能在外面加载和渲染各种HTML的页面。而同时，WebView个别继承于原生客户端的UI基类。所以，对于原生利用来说，WebView自身通过加载h5页面、通过Chromium/WebKit内核解析并进行UI合成，生成客户端原生的UI类，而后上屏展现。

而html页面与native的沟通交互则是通过所谓的JSB (JavaScript Bridge)来实现的。客户端将原生零碎级的接口进行封装，而后通过JSB裸露给WebView中前端页面进行调用。实质上这就是原生零碎API与前端页面Javascript的通信。
这样一来，前端开发者也能够很快地实现页面跨端，通过JSB与原生零碎进行沟通，保障跨端利用在整体上的能力买通和互相调用。

只不过，这样的机制劣势也很显著，就是前端页面与原生零碎的通信齐全取决于JSB的结构，如果JSB中短少调用原生能力的接口，那跨段能力也会间接受限。这种状况下仍旧须要别离裁减原生利用中的JSB接口，反而升高了开发效率。

此外，WebView对UI的渲染依赖于浏览器内核，而浏览器内核又独立于零碎组件，所以无奈保障跨端UI的原生体验。原生体验永远是跨端技术谋求的终极目标。

2 React Native

为了谋求下面说过的原生体验的问题，Facebook在2015年则推出了非常炽热的React Native，简称RN。

RN相较于WebView，最大的区别就是不再应用浏览器内核进行UI渲染，而是应用一个叫做Virtual DOM的货色来进行跨端UI渲染的治理。

Virtual DOM和DOM实际上差不多，都是一个树形构造，在不同节点上记录了UI的不同元素。只不过Virtual DOM将渲染工作是交给了原生渲染引擎，比方web浏览器、iOS、Android，去解决。之后，不同平台仍旧是通过对应的Bridge来创立不同的Native视图。

这样以来，体验有肯定的晋升。只不过React Native和原生交互依赖的只有一个Bridge，而且JS和Native交互是异步的，所以对须要和Native大量实时交互的性能可能会有性能上的有余，比方动画效率，性能仍旧是不如原生的。

3 Flutter

Flutter是谷歌外部孵化的挪动端跨平台UI框架，它是在RN被饱受质疑的时候提出，算是目前最靠近原生体验的框架。

从底层原理上来说，它既没有采纳WebView与H5混编的模式，也没有采纳JavaScript通过Bridge进行桥接的模式，而是本人实现了一套UI框架，间接在更底层进行UI渲染。不仅如此，它也不再采纳JavaScript作为开发语言，而是抉择了Dart。称Dart语言能够编译成原生代码，间接跟原生通信。

之所以抉择Dart，其实Flutter团队在晚期就评估了十多种语言，并抉择了Dart，因为感觉它合乎他们构建用户界面的形式，并且还具备以下劣势：

1 Dart是AOT (Ahead Of Time)编译的，编译成疾速、可预测的本地代码，使Flutter简直都能够应用Dart编写。\
2 Dart也能够JIT(Just In Time)编译，开发周期异样快，工作流颠覆惯例（包含Flutter风行的亚秒级有状态热重载）；\
3 Dart能够更轻松地创立以60fps运行的晦涩动画和转场。Dart能够在没有锁的状况下进行对象调配和垃圾回收。\
4 Dart使Flutter不须要独自的申明式布局语言，如JSX或XML，或独自的可视化界面构建器，因为Dart的申明式编程布局易于浏览和可视化。

Flutter与上述Recat Native、WebView容器实质上都是不同的，它没有应用WebView、JavaScript解释器或者零碎平台自带的原生控件，而是有一套本人专属的Widget，所有组件基于Skia引擎自绘。

Flutter因为是通过本人的引擎进行UI渲染，因而在iOS和Android的成果基本一致。 相比之下，RN是将UI控件转换为对应平台的原生控件，所以不可避免的会存在肯定差别。

从技术角度来看，RN实际上就是在Native容器中提供了JavaScript的运行环境，然而其布局引擎，渲染层都采纳的是Native的控件，因而UI交互上依然存在零碎差别。而Flutter计划更彻底一些，连渲染层也换成了基于图形引擎自绘UI控件，从而保障UI交互的跨端一致性。