前言（纯属个人学习记录，如有问题欢迎指正）
随着移动互联网的普及和快速发展，“得移动端者得天下”，移动端取代PC端，成为了互联网行业最大的流量分发入口，因此不少公司制定了“移动优先”的发展策略。随着5G的快速发展，未来越来越多的“端”也会如雨后春笋般快速兴起。而“快”作为互联网的生存之道，为了占领市场，企业也会积极跟进，快速布局。同一个应用，各个“端”独立开发，不仅开发周期长，而且人员成本高。同时，作为技术人员，也不应该满足于这种重复、低效的工作状态。在这样的形势下，跨平台的技术方案也受到越来越多人和企业的关注。接下来，将从基本概念、优缺点等方面为大家分享《跨平台技术演进》。
跨平台方案
对于跨平台开发，业界一直都在努力寻找好的解决方案。时至今日，已经有很多成熟的解决方案，根据其原理，我们主要分为三类：
[if !supportLists]· [endif]1.H5+原生（Cordova、Ionic）
[if !supportLists]· [endif]2.JavaScript开发+原生渲染 （React Native、Weex）
[if !supportLists]· [endif]3.自绘UI+原生(Flutter)
接下来我们逐个来看看这三种类型的原理及优缺点。
（一）H5+原生
H5
说到跨平台，没人不知道H5。不管是在Mac、Windows、Linux、iOS、Android还是其他平台，只要给一个浏览器，连“月球”上它都能跑。
将APP的某些页面，通过WebView (Android)或WKWebView（IOS）加载网页地址实现功能。
优点对于开发者特别友好。
缺点性能表现一般，在复杂的UI样式下，不流畅。如果没做离线缓存，耗费流量，页面载入速度比原生慢。
小程序
2018年是微信小程序飞速发展的一年，19年，各大厂商快速跟进，已经有了很大的影响力。下面，我们以微信小程序为例，分析小程序的技术架构。
小程序跟H5一样，也是基于Webview实现。但它包含View视图层、App Service逻辑层两部分，分别独立运行在各自的WebView线程中。
(二)JavaScript开发+原生渲染
此类框架将UI节点映射成原生控件，并通过JS控制，其最终产品是一个接近“原生”的移动应用。比如React Native，他的控件ScrollView、Image，映射到IOS是 UIScrollView、UIImageView；安卓则是 ScrollView、ImageView。因此，从使用感受上和用Objective-C或Java编写的原生应用相近。
1.Weex（阿里）
作为一套前端跨平台技术框架，Weex建立了一套源码转换以及Native与Js通信的机制。Weex表面上是一个客户端框架，但实际上它串联起了从本地开发、云端部署到分发的整个链路。具体来说，在开发阶段编写一个.we文件，然后使用Weex提供的weex-toolkit转换工具将.we文件转换为JS bundle，并将生成的JS bundle上传部署到云端，最后通过网络请求或预下发的方式加载至用户的移动应用客户端。当集成了Weex SDK的客户端接收到JS bundle文件后，调用本地的JavaScript引擎执行环境执行相应的JS bundle，并将执行过程中产生的各种命令发送到native端进行界面渲染、数据存储、网络通信以及用户交互响应。
由上图可知，Weex框架中最核心的部分就是JavaScript Runtime。具体来说，当需要执行渲染操作时，在iOS环境下选择基于JavaScriptCore内核的iOS系统提供的JSContext，在Android环境下使用基于JavaScriptCore内核的JavaScript引擎。
当JS bundle从服务器下载完成之后，Weex的Android、iOS和H5会运行一个JavaScript引擎来执行JS bundle，同时向各终端的渲染层发送渲染指令，并调度客户端的渲染引擎实现视图渲染、事件绑定和处理用户交互等操作。由于Android、iOS和H5等终端最终使用的是native渲染引擎，也就是说使用同一套代码在不同终端上展示的样式是相同的，并且Weex使用native引擎渲染的是native组件，所以在性能上比传统的WebView方案要好很多。
当然，尽管Weex已经提供了开发者所需要的最常用的组件和模块，但面对丰富多样的移动应用研发需求，这些常用基础组件还是远远不能满足开发的需要，因此Weex提供了灵活自由的扩展能力，开发者可以根据自身的情况定制属于自己客户端的组件和模块，从而丰富Weex生态。
2.React Native
React Native (简称RN)是Facebook于2015年4月开源的跨平台移动应用开发框架，是Facebook早先开源的React框架在原生移动应用平台的衍生产物，目前主要支持iOS和安卓两大平台。
RN使用Javascript语言来开发移动应用，但UI渲染、网络请求等均由原生端实现。具体来说，开发者编写的Javascript代码，通过中间层转化为原生控件后再执行，因此熟悉Web前端开发的技术人员只需很少的学习就可以进入移动应用开发领域，并可以在不牺牲用户体验的前提下提高开发效率。
RN的理念是在不同平台上编写基于React的代码，实现Learn once, write anywhere。
React Native 工作原理
在React 框架中，JSX 源码通过 React 框架最终渲染到了浏览器的真实 DOM 中，而在 React Native 框架中，JSX 源码通过 React Native 框架编译后，与Native原生的UI组件进行映射，用原生代替DOM元素来渲染，在UI渲染上非常接近Native App。
React Native 与Native平台通信
React Native用JavaScriptCore作为JS的解析引擎，在Android上，需要应用自己附带JavaScriptCore，iOS上JavaScriptCore属于系统的一部分，不需要应用附带。
用Bridge将JS和原生Native Code连接起来。Native和 JavaScript 两端都保存了一份配置表，里面标记了所有Native暴露给 JavaScript 的模块和方法。交互通过传递 ModuleId、MethodId 和 Arguments 进行。
作为一个跨平台技术框架，RN从上到下可以分为Javascript层、C++层和Native层。其中，C++层主要用于实现动态连结库(.so)，作为中间适配层桥接，实现js端与原生端的双向通信交互，如下图所示是RN在Android平台上的通信原理图。
在RN的三层架构中，最核心的就是中间的C++层，C++层最核心的功能就是封装JavaScriptCore，用于执行对js的解析。同时，原生端提供的各种Native Module（如网络请求，ViewGroup控件模块）和JS端提供的各种JS Module（如JS EventEmiter模块）都会在C++实现的so文件中保存起来，最终通过C++层中的保存的映射实现两端的交互。
在RN开发过程中，大多数情况下开发人员并不需要需要了解RN框架的具体细节，只需要专注JS端的逻辑代码实现即可。但是需要注意的是，由于js代码是运行在独立的JS线程中，所以在js中不能处理耗时的操作，如fetch、图片加载和数据持久化等操作。
最终，JS代码会被打包成一个bundle文件并自动添加到应用程序的资源目录下，而应用程序最终加载的也是打包后的bundle文件。RN的打包脚本位于“/node_modules/react-native/local-cli”目录下，打包后通过metro模块压缩成bundle文件，而bundle文件只包含打包js的代码，并不包含图片、多媒体等静态资源，而打包后的静态资源会是被拷贝到对应的平台资源文件夹中。
总的来说，RN使用Javascript来编写应用程序，然后调用原生组件执行页面渲染操作，在提高了开发效率的同时又保留了Native的用户体验。并且，伴随着Facebook重构RN工作的完成，RN也将变得更快、更轻量、性能更好。
优缺点分析
优点
[if !supportLists]· [endif]垮平台开发：相比原生的ios 和 android app各自维护一套业务逻辑大同小异的代码，React Native 只需要同一套javascript 代码就可以运行于ios 和 android 两个平台，在开发、测试和维护的成本上要低很多。
[if !supportLists]· [endif]快速编译：相比Xcode中原生代码需要较长时间的编译，React Native 采用热加载的即时编译方式，使得App UI的开发体验得到改善，几乎做到了和网页开发一样随时更改，随时可见的效果。
[if !supportLists]· [endif]快速发布：React Native 可以通过 JSBundle 即时更新 App。相比原来冗长的审核和上传过程，发布和测试新功能的效率大幅提高。
[if !supportLists]· [endif]渲染和布局更高效：React Native摆脱了WebView的交互和性能问题，同时可以直接套用网页开发中的css布局机制。脱了 autolayout 和 frame 布局中繁琐的数学计算，更加直接简便。
[if !supportLists]· [endif]采用Web开发技术栈，社区庞大、上手快、开发成本相对较低。
[if !supportLists]· [endif]原生渲染，性能相比H5提高很多。
缺点
[if !supportLists]· [endif]动画性能差：React Native 在动画效率和性能的支持还存在一些问题，性能上不如原生Api。
[if !supportLists]· [endif]不能完全屏蔽原生平台：就目前的React Native 官方文档中可以发现仍有部分组件和API都区分了Android 和 IOS 版本,即便是共享组件,也会有平台独享的函数。也就是说仍不能真正实现严格意义上的“一套代码，多平台使用”。另外，因为仍对ios 和android的原生细节有所依赖，所以需要开发者若不了解原生平台，可能会遇到一些坑。
[if !supportLists]· [endif]生态不完善：缺乏很多基本控件，第三方开源质量良莠不齐
[if !supportLists]· [endif]渲染时需要JavaScript和原生之间通信，在有些场景如拖动可能会因为通信频繁导致卡顿。
[if !supportLists]· [endif]由于渲染依赖原生控件，不同平台的控件需要单独维护，并且当系统更新时，社区控件可能会滞后；除此之外，其控件系统也会受到原生UI系统限制。
展望未来
虽然RN还存在不足，但RN新版本已经做了如下改进，并且RN团队也在积极准备大版本重构，能否成为开发者们所信赖的跨平台方案，让我们拭目以待。
[if !supportLists]1. [endif]改变线程模式。UI 更新不再同时需要在三个不同的线程上触发执行，而是可以在任意线程上同步调用 JavaScript 进行优先更新，同时将低优先级工作推出主线程，以便保持对 UI 的响应。
[if !supportLists]2. [endif]引入异步渲染能力。允许多个渲染并简化异步数据处理。
[if !supportLists]3. [endif]简化JSBridge，让它更快、更轻量。
既然React Native在渲染方面还摆脱不了原生，那有没有一种方案是直接操控GPU，自制引擎渲染呢，我们终于迎来了Flutter！
(三)自绘UI+原生
我们看看最后一种跨平台技术：自绘UI+原生。这种技术的思路是，通过在不同平台实现一个统一接口的渲染引擎来绘制UI，而不依赖系统原生控件，所以可以做到不同平台UI的一致性。因为技术难度比较大，目前成熟且流行的代表作就是Google出品的Flutter，也是我们今天所要介绍的。
Flutter
Flutter是Google开发的一套全新的跨平台、开源UI框架，支持iOS、Android系统开发，并且是未来新操作系统Fuchsia的默认开发套件。渲染引擎依靠跨平台的Skia图形库来实现，依赖系统的只有图形绘制相关的接口，可以在最大程度上保证不同平台、不同设备的体验一致性，逻辑处理使用支持AOT的Dart语言，执行效率也比JavaScript高得多。
Flutter正逐步被众多厂家采用。像，阿里，腾讯，Google等等。
如上图所示，Flutter框架主要由Framework和Engine层组成，而我们基于Framework开发App最终会运行在Engine上。其中，Engine是Flutter提供的独立虚拟机，正是由于它的存在Flutter程序才能运行在不同的平台上，实现跨平台运行的能力。
Flutter架构原理
Framework：由Dart实现，包括Material Design风格的Widget,(针对iOS)风格的Widgets，文本/图片/按钮等基础Widgets，渲染，动画，手势等。此部分的核心代码是:flutter仓库下的flutter package，以及sky_engine仓库下的io,async,ui(dart:ui库提供了Flutter框架和引擎之间的接口)等package
Engine：由C++实现，主要包括:Skia,Dart和Text。
[if !supportLists]o [endif]Skia是开源的二维图形库，提供了适用于多种软硬件平台的通用API。其已作为Google Chrome，Chrome OS，Android, Mozilla Firefox, Firefox OS等其他众多产品的图形引擎，支持平台还包括Windows7+,macOS 10.10.5+,iOS8+,Android4.1+,Ubuntu14.04+等。Skia作为渲染/GPU后端，在Android和Fuchsia上使用FreeType渲染，在iOS上使用CoreGraphics来渲染字体。
[if !supportLists]o [endif]Dart部分主要包括:Dart Runtime，Garbage Collection(GC)，如果是Debug模式的话，还包括JIT(Just In Time)支持。Release和Profile模式下，是AOT(Ahead Of Time)编译成了原生的arm代码，并不存在JIT部分。
[if !supportLists]o [endif]Text即文本渲染，其渲染层次如下:衍生自minikin的libtxt库(用于字体选择，分隔行)。HartBuzz用于字形选择和成型。
Embedder：是一个嵌入层，即把Flutter嵌入到各个平台上去，这里做的主要工作包括渲染Surface设置,线程设置，以及插件等。从这里可以看出，Flutter的平台相关层很低，平台(如iOS)只是提供一个画布，剩余的所有渲染相关的逻辑都在Flutter内部，这就使得它具有了很好的跨端一致性。与RN和Weex使用原生控件渲染界面不同，Flutter并不需要使用原生控件来渲染界面，而是使用Engine来绘制Widget（Flutter显示单元），并且Dart代码会通过AOT编译为平台的原生代码，实现与平台的直接通信，不需要JS引擎的桥接，也不需要原生平台的Dalvik虚拟机。如下图。
同时，Flutter的Widget采用现代响应式框架来构建，而Widget是不可变的，仅支持一帧，并且每一帧上的内容不能直接更新，需要通过Widget的状态来间接更新。在Flutter中，无状态和有状态Widget的核心特性是相同的，视图的每一帧Flutter都会重新构建，通过State对象Flutter就可以跨帧存储状态数据并恢复它。
总的来说，Flutter是目前跨平台开发中最好的方案，它以一套代码即可生成Android和iOS平台两种应用，很大程度上减少了App开发和维护的成本，同时Dart语言强大的性能表现和丰富的特性，也使得跨平台开发变得更加便利。而不足的是，Flutter还处于Alpha阶段，许多功能还不是特别完善，而全新的Dart语言也带来了学习上的成本，如果想要完全替代Android和iOS开发还有比较长的路要走。
Dart优势
很多人会好奇，为什么Flutter要用Dart，而不是用JavaScript开发，这里列下Dart的优势。
这是一个很有意思，但也很有争议的问题，在了解Flutter为什么选择了 Dart而不是 JavaScript之前我们先来介绍两个概念：JIT和AOT。
目前，程序主要有两种运行方式：静态编译与动态解释。静态编译的程序在执行前全部被翻译为机器码，通常将这种类型称为AOT（Ahead of time）即 “提前编译”；而解释执行的则是一句一句边翻译边运行，通常将这种类型称为JIT（Just-in-time）即“即时编译”。
AOT程序的典型代表是用C/C++开发的应用，它们必须在执行前编译成机器码，而JIT的代表则非常多，如JavaScript、python等，事实上，所有脚本语言都支持JIT模式。但需要注意的是JIT和AOT指的是程序运行方式，和编程语言并非强关联的，有些语言既可以以JIT方式运行也可以以AOT方式运行，如Java、Python，它们可以在第一次执行时编译成中间字节码、然后在之后执行时可以直接执行字节码。
[if !supportLists]· [endif]Dart 的性能更好。Dart在 JIT模式下，速度与 JavaScript基本持平。但是 Dart支持 AOT，当以 AOT模式运行时，JavaScript便远远追不上了。速度的提升对高帧率下的视图数据计算很有帮助。
[if !supportLists]· [endif]Native Binding。在 Android上，v8的 Native Binding可以很好地实现，但是 iOS上的 JavaScriptCore不可以，所以如果使用 JavaScript，Flutter 基础框架的代码模式就很难统一了。而 Dart的 Native Binding可以很好地通过 Dart Lib实现。
[if !supportLists]· [endif]Fuchsia OS。Fuchsia OS内置的应用浏览器就是使用 Dart语言作为 App的开发语言。
优缺点分析
优点
[if !supportLists]· [endif]性能强大：在两个平台上重写了各自的UIKit，对接到平台底层，减少UI层的多层转换，UI性能可以比肩原生
[if !supportLists]· [endif]路由设计优秀：Flutter的路由传值非常方便，push一个路由，会返回一个Future对象（也就是Promise对象），使用await或者.then就可以在目标路由pop，回到当前页面时收到返回值。
[if !supportLists]· [endif]灵活、组件库易维护、UI外观保真度和一致性高；由于UI渲染不依赖原生控件，也就不需要根据不同平台的控件单独维护一套组件库，所以代码容易维护。由于组件库是同一套代码、同一个渲染引擎，所以在不同平台，组件显示外观可以做到高保真和高一致性；另外，由于不依赖原生控件，也就不会受原生布局系统的限制，这样布局系统会非常灵活。
缺点
[if !supportLists]· [endif]Dart 语言的生态小，精通成本比较高
[if !supportLists]· [endif]UI控件API设计不佳。涉及到硬件层功能（定位、缓存文件位置等）的访问，仍然需要用原生代码实现接入，期待第三方库发展成熟。
[if !supportLists]· [endif]与原生融合障碍很多，不利于渐进式升级。热更新能力，相比H5、React有所欠缺 ，《闲鱼动态下发解决方案》
[if !supportLists]· [endif]涉及到硬件层功能（定位、缓存文件位置等）的访问，仍然需要用原生代码实现接入，期待第三方库发展成熟。
总结
移动互联网的普及和快速发展，跨平台技术风起云涌，这也是技术发展过程中的必经之路，等浪潮退去，才知道谁在裸泳。个人更看好H5或类H5方案，给它一个浏览器，连“月球”都能跑，这才是真正的跨平台，其他都是浮云。（后半部分不是我说的哦，请各位技术大佬手下留情）。
使用Flutter 与原生技术混合开发示例
目前主流的混合开发方案有
源码集成产物集成
优点1. 简单快捷、Google 原生支持 (beta 版)
2. 和原生交互较多或需要依赖原生的数据环境使用源码集成开发调试更方便
1. 不影响原生项目
2. 不参与 Flutter 开发的人员处于无感状态
3. 无需对现有的持续集成环境和编译发布流程进行修改
缺点1. 团队所有人都需要安装 Flutter 环境
2. 需要对现有编译发布体系做修改
1. 复杂度相对较高，如果是小团队成本较高
2. 需要和原生交互的时候调试不方便
两种集成方式：
源码集成：也就是谷歌官方提供的方案
[https://github.com/flutter/flutter/wiki/Add-Flutter-to-existing-apps]
产物集成：Flutter 项目单独开发，开发完成后发布成 aar 包或者 iOS 的 framework 形式，原生项目依赖 Flutter 输出的制品即可。
两种方式对比：
两种方式各有优劣，其实产物集成更好一些，不过即使是进行产物集成，也需要弄懂源码集成的方式，因为当有很多和原生交互的功能进行开发的时候，源码集成的方式可以直接调试会方便很多。整个的集成方案是参考谷歌方法：[https://github.com/flutter/flutter/wiki/Add-Flutter-to-existing-apps]，另一个是创建了一个flutter 项目后，在原生的项目中使用 git submodule 的形式进行管理的。
git submodules：
git submodules提供了一种类似于npm package的依赖管理机制，包括添加、删除、更新依赖项等功能，区别在于前者所管理的依赖是子模块的源码，后者管理的是子模块的构建产物。（只关心子模块的源码）
这样主项目需要与子模块频繁联调时的麻烦就不复存在了，因为主项目拉取到的submodules都是完整repo，可以直接修改-构建-提交
在当前诸多的跨平台方案中，RN、Weex和Flutter无疑是最优秀的。而从不同的细节来看，三大跨平台框架又有各自的优点和缺点，可以通过表来查看。
对比类型React NativeWeexFlutter
支持平台Android/IOSAndroid/IOS/WebAndroid/IOS
实现技术JavaScriptJavaScript原生编码/渲染
引擎JS V8JSCoreFlutter Engine
编程语言ReactVueDart
框架程度较重较轻重
社区活跃、FB维护不活跃活跃
如上表所示，RN、Weex采用的技术方案大体相同，它们都使用JavaScript作为编程语言，然后通过中间层转换为原生的组件后再利用Native渲染引擎执行渲染操作。而Flutter直接使用skia来渲染视图，而Flutter Widget则使用现代响应式框架来构建，和平台没有直接的关系。就目前跨平台技术来看，JavaScript在跨平台开发中可谓占据半壁江山，大有“一统天下”的趋势。
从性能方面来说，Flutter的性能理论上是最好的，RN和Weex次之，并且都好于传统的WebView方案。但从目前的实际应用来看却并没有太大的差距，特别是和0.5.0版本以上的RN对比性能体验上差异并不明显。
而从社群和社区的活跃来看，RN和Flutter无疑是最活跃的，RN经过4年多的发展已经成长为跨平台开发的实际领导者，并拥有各类丰富的第三方库和开发群体。Flutter作为近几年才火起来的跨平台技术方案，不过目前还处在beta阶段，商用的实例也很少，不过应该看到google的号召力一直是很强，未来究竟如何发展让我们拭目以待。
网友对Flutter的评价：
Flutter是Google的亲儿子，目前最火爆的跨平台框架，也是跨平台框架中最接近原生的一种框架，也是效率最高的。目前应用在移动端(安卓端，iOS端)，Web也发布了预览版，但是还无法真正放在小程序或者Web项目中实战。目前来看，Web上面还是无法真正的替代ionic框架。虽然脱离了JS强大的社区,但是这一年多以来Dart语言社区也在逐渐长大，pub.dev上面各种Flutter和Dart的开源库和工具都有，开发项目起来还是不错的，只是Flutter Web发展还不够完善，很多Web的一些包一级浏览器的功能还不完善。
网友对Flutter的评价：
我是做前端的，我朋友是移动端的，他走的Flutter路线，他是做安卓开发的，用的java，他说Flutter接近原生体验，非常好。而我们公司需要快速上线，还是走的是WebView的路线，我和他同时做一个小Demo出来对比了一下，发现App的性能体验真的很大，排序如下：原生 >= Flutter > WebView。
Flutter相关资料
https://book.flutterchina.club/
https://rtcdeveloper.com/t/topic/13584
https://www.jianshu.com/u/cf5c0e4b1111
https://javiercbk.github.io/json_to_dart/
https://flutterchina.club/get-started/install/
https://flutter.dev/docs/development/tools/sdk/releases?tab=macos#macos
本文纯属个人学习收集，如有雷同，纯属巧合。
如下附图：
