到底什么是移动跨平台技术方案？

由于大数据的发展、互联网的水平技术的不断上升，越来越多的人会更对网络技术产生兴趣。原本各大产品只能线下投放的，现在也都默契的搬到了线上，满足消费者需求与需要。并且在互联网这个”卷心饼“的风暴中，降低开发成本，提升效率，利用最短的时间做出高质量高评价高服务的产品的做法，自然会顺应的导出许多的移动跨平台技术方案。

让我们回忆最具有历史感的移动跨平台解决方案还是在PhoneGap的时代，同时这也是Hybird时代，其标志性作品为Cordova。紧接着在同一阶段时间内，基础于AngularJS和Cordova的增强版Ionic也相应地产生了，值得注意的是，这些方案都隶属于混合开发方案。

在这之后，我们也接触到了借助原生渲染的方案，依次出现了ReactNative、Weex、uni-app等。随后也出现了放弃原生渲染、自建渲染方案的自渲染技术Flutter。

一、移动跨平台的实质与特点

眼下在移动端的跨平台开发过程中，基本存在下列几种现象：

Kotlin作为android的一级语言，已经开始支持ios和web的开发，有着想要”一统天下“的趋势。

而Google的跨平台移动UI框架是fluttter，谷歌的亲儿子是Dart，比较明显的是Dart成了flutter的编程语言。查看flutter的官网，我们也能够感觉得到它”心怀天下“

react native、weex都在用JavaScript作为编程语言，而且到现在为止在跨平台开发中JavaScript，也可以说是占据着天平一侧的分量，未来可期。

二、移动跨平台的三个阶段

1、Web 容器时代

在Web 时代的方案中，主要采用的是原生应用内嵌浏览器控件 WebView的方式进行HTML5 页面渲染，并且这也定义了 HTML5 与原生代码交互产生协议，会将部分原生系统能力透露给 HTML5，继而增拓 HTML5 的范围边界。

这种交互协议，一般是指我们常提到的的 JS Bridge。基于应用了 Web 开发技术的原因，社区和资源十分丰富可观，相应的其开发效率也很高

然而，一个完整 HTML5 页面的出现会经历浏览器控件的加载、解析还有渲染三大过程，这种消耗的性能会要比原生开发增加达 N 个数量级。

2、泛 Web 容器时代

泛Web容器时代的解决方案极大的优化了了Web容器时代的加载、解析和渲染这三个阶段，裁剪了影响自身独立运行的Web标准，利用了比较简单的方式支持了构建移动端页面不可缺少的的Web标准；

Web容器方案有着生态繁荣、开发效率高、跨平台兼容性强等好处，但是同样它自身的最明显的问题实际上是装载着大量Web标准的Web容器过于沉笨，以至于导致性能和体验与原生产生较大的差别。

并且，这一阶段的解决方案可以说全部抛弃了浏览器的控件渲染，转而由原生接管绘制。只需要存留必须的基本控件渲染能力，进而更加简化渲染的过程，使得良好的渲染性能得到保障。

3、自绘引擎时代

自带渲染引擎，客户端仅提供一块画布即可获得从业务逻辑到功能呈现的多端高度一致的渲染体验。Flutter，是为数不多的代表。Flutter 开辟了一种全新的思路，即从头到尾重写一套跨平台的 UI 框架，包括渲染逻辑，甚至是开发语言。

三、移动跨平台技术方案差异

现在的跨平台技术和解决方案基本上有三种，包括Web跨端、容器跨端以及小程序跨端。

1、Web 跨端

Web 跨端容易明白，这是因为 Web 天生就有跨端的技能，只要有浏览器或 WebView，现在绝大多数端上（甚至包括封闭的小程序生态）都可以进行 Webview，所以只要开发创建网页然后投放到多种端口就能轻松的做到跨平台

例如 Web App、PWA（Progressive Web Apps）、Hybrid App、PHA（Progress Hybrid App）。

2、容器跨端

另一种统一多端的思路，这主要是将 Native 特制成标准容器，让同一份代码运行在每一个标准容器里。

其中比较特别经典的代表是React Native 、Flutter、Weex，这一类方案尽可能的取长补短，结合了 Web 生态和 Native 组件，让 JS 执行代码后用 Native 的组件进行渲染，以此来解决抛弃Webi里的历史包袱的问题。

3、小程序跨端

所谓的小程序跨端就是让相同代码的小程序运行在多种App中，举个例子来讲，开发完一个小程序除了运营在微信中之外，还能运行在像是支付宝、百度等超级App，甚至是自身拥有的 App中。

有人会提问如果小程序还是依靠Web技术，那我们为什么还要单独的去采用小程序呢？正如前文所讲，Web 终究是不可以调用例如相机、蓝牙等诸如此类的权限的，相应的也会给用户的使用体验感带来影响。

小程序不同的地方就在于它拥有强悍的 Web 渲染引擎、提供丰富组件、支持本地缓存、避免 DOM 外露等，并且其最初目的是开放，可以使得像是微信、支付宝等多种APP也能够开放小程序上架的能力，逐渐的小程序也成为了跨App的正统方式。

为了能够让个人或者企业拥有的App产生运行小程序的能力、让别的APP具备相同的超级APP的小程序跨端能力，之后也产生了像是Ficlip（www.finclip.com）这种小程序容器。

并且，在FinClip中，Flutter、Taro、 kbone等已经开发出来的小程序也可以进行运行。

优点：

1.能够获得用户的相册、蓝牙、多媒体等基础权限。

2.拥有像 Native App 的体验感觉，使用感拉满，如德芙般丝滑。

3.能够利用简单的上下架方式推动有关页面和业务的热更新

缺点：

1.些许的插件会涉及到相关的原生技术

2.虽然在大平台内的框架都差别不大，但是也会产生细微的影响，像是W3C也在做小程序的标准化工作。