移动跨平台开发框架解析与选型

简介

在当前移动端跨平台框架漫天飞的状况下，不少开发者不知道该选择哪一种框架来进行开发，哪一种框架适合后期维护、稳定性等问题。本文会带你们了解目前市场上比较流行的一些框架的对比

移动跨平台开发介绍

传统移动端开发

现阶段，当前市面上的手机无非苹果和安卓，两大操做系统能够说各分天下，传统的app的开发就是指原生开发，须要ios工程师和安卓工程师各自进行，ios开发一份，安卓开发一份，安卓使用的是JAVA或者是Kotlin，ios使用的是Objective-C或者是SWIFT，这种开发模式也是最多见的开发模式，从智能手机诞生到今天，一直是最主流的开发模式。

Android	Ios
JAVA / Kotlin	Objective-C / SWIFT

传统移动端开发优缺点

优势	缺点
速度快、性能高、稳定性强、用户体验好	前期开发费用高
能够访问手机全部功能	开发效率偏低
支持大量图形和动画	后期维护繁琐
可离线使用	上线时间没法固定

跨平台技术的诞生

早在2010年，当时从事 Android 和 iOS 开发的人不多，也不火，全部人都在 “摸着河底过河”，项目更没有第三方框架一说，大都是本身写的，不像如今各类的框架满天飞。随着移动开发的发展，互联网公司也是层出不穷，有些公司迫于竞争，想要更快速的更省成本的进行开发，就再也不知足 Android 端一套代码，iOS 端一套代码。同时，其余技术领域和各大公司也都各自推出相关的技术，这样跨平台技术随之诞生，而且开始在公司中生根发芽。
由于Android 和 iOS 生态很大，咱们能够把它们比做第一级生态，也有厂商想要颠覆这两个系统，但都失败了，所以创建次级生态才是最稳妥的策略，Android 平台更加开放，所以创建次级生态的中心就是 Android，次生态的形式多种多样，好比在 Android 系统的基础上魔改创建本身的生态，再或者推出各类跨平台技术创建生态。跨平台技术产生的框架实在太多了，不少还没等咱们去学去了解，它们就没落了，也就成为了跨平台技术发展的一个过分产物。

移动跨平台开发演进

为何要跨平台开发？

做为开发不一样应用而使用不一样的开发语言，对开发者而言并非一个好事。本质上，跨平台开发是为了增长代码复用，减小开发者对多个平台差别适配的工做量，下降开发成本，提升业务专一的同时，提供比web更好的体验，跨平台开发正是解决了这一问题。

跨平台开发的优缺点

因为跨平台技术须要依赖各类框架，各框架品质也参差不齐，老框架就不说了，新框架教程少、开发时遇到的坑多，有的能填上，有的填不上。这就须要框架背后的大厂和社区的支持了。

优势	缺点
节省人力、开发成本	性能低于原生
节省开发时间	用户体验低于原生
多端的一致性	包体积变大
易上手	跨平台框架自身bug、缺陷

移动跨平台开发框架解析

跨平台技术演进

WebApp

Web App 是指基于 Web 的应用，运行于网络和标准浏览器上，至关于一个网页而后加一个 App 的壳。2014 年 HTML5 的标准规范制定完成，记得当时在网络上 Web App 大有取代 Native App 的气势，但 Web App 有如下缺点，使得它始终是 “主角的心，配角的命”

• 性能低，操做体验很差
• 没法调用原生 API，不少功能没法实现，
• 依赖于网络，网速慢时体验不好，而且没有离线功能，优化很差的话会消耗流量
• 只能作为一个临时的入口，用户留存率低

在 Web App 的基础上，又出现了几个进化者，好比PWA。

WebApp——PWA（Progressive Web App，渐进式加强 Web 应用）

PWA（Progressive Web App）意为渐进式加强 Web 应用，它不是一门技术，而是一个概念，他的意思就是使用多种技术来加强 Web App 的功能

总结起来，PWA 的主要的能力就是离线、推送、桌面访问，能够说 PWA 赋予 Web App 原生的体验，可是 PWA 一直不温不火的缘由主要有如下几点：

• 用 Service Worker + HTTPS +Cache Api + indexedDB 等一系列 web 技术实现离线加载和缓存
• 实现了推送和通知
• 能够直接添加到手机的桌面上
• 使用 Service Worker 能够进行后台同步
• 游览器对 PWA 技术支持还不够全面， 不是每一款游览器都能 100% 的支持 PWA
• 国内一些手机厂商对 Android 系统各类魔改，对 PWA 的兼容性很差，甚至不支持 PWA
• 平台的竞争，iOS 对 PWA 的支持力度远远低于 Android，因此 PWA 在 iOS 上的体验打了折扣。PWA 面对相似的微信小程序和快应用的竞争中，并无优点。

Hybrid App

• 原生 App 的架构图

• Hybrid App 的架构图

除了采用原生和 Web 开发 App，还能够采用 HTML5 + 原生来进行混合开发，这就是 Hybrid。

混合开发也比较好理解，就是H5与原生开发的结合，主要是用js和原生技术相互调用，能够初步实现跨平台使用的效果，如今咱们平常使用当中有不少App都是经过这种方式实现的。

关于 Hybrid 的诞生有一个小故事，某个二线互联网公司的 App 是以原生为主，HTML5 开发打酱油，随着应用愈来愈复杂，终于有一天发现原生有一个方法最大数限制，一些页面须要内嵌 HTML5 的页面，因而原生和 HTML5 团队一块儿作了第一个 Hybrid 项目，这一套代码兼容三端而且效率很高，所以 Hybrid App 就成了这个公司的主流，业界其余的公司也都纷纷效仿。

经过原生 SDK 提供的 API，App 能够与系统底层通讯，以建立 UI 组件或访问系统服务。这些组件被渲染到手机屏幕，屏幕产生的相应的事件会被传回给组件。由于每一个平台的系统组件是不一样的，你须要为每一个平台开发单独的 App，而 Hybrid App 没必要这样，Hybrid App 的原生 UI 组件用来展现交互复杂和渲染要求高的界面，其余的能够交给 HTML5 来展现。
Hybrid App 虽然开发效率高，能够跨平台，可是 Hybrid 体验比不上原生，对于须要快速试错、快速占领市场的团队来讲，Hybrid App 是一个不错的选择，后期团队稳定下来后，最好仍是要作体验更好的原生 APP 或者使用其余体验更好的跨平台技术。

Hybrid 相关的技术有不少，好比 PhoneGap、Cordova、Ionic、VasSonic 等等，咱们大概来了解一下。

Hybrid App——Cordova

说到 Cordova，不得不提到他的前身 PhoneGap，PhoneGap 面向 Web 开发人员，经过使用 HTML、CSS 和 Javascript 构建跨平台 App。同年10月4日，Adobe 收购了 Nitobi Software 和它的 PhoneGap 产品，并对 PhoneGap 进行开源并将其转到Apache。PhoneGap 2.0 版本时，产品改名为 Apache Cordova。目前 Cordova 支持的平台有 Android、iOS、Windows、Mac OS X、Electron。

为何叫作Cordova呢，是由于PhoneGap在建立时，Nitobi的所在地在温哥华的科尔多瓦街(Cordova Street)

Cordova的工做原理

第一部分：Cordova Application是Cordova框架独立于不一样手机操做系统的一个封装层。具体包括
1）Web App层是开发人员编写代码的主要地方，应用程序以网页的形式呈现，在一个index.html的本地页面文件中引用所须要的各类Web资源，如CSS、JavaScript、图像、影音文件等。应用程序的配置保存在config.xml文件中。

2）WebView层用来呈现用户界面，即web页面的展示。例如，在Android平台是经过WebView控件实现web页面的呈现。

3）Plugins主要用于在JavaScript代码中调用各平台native的功能。Cordova项目已经包含一些核心的plugin，如电池、摄像头、通信录等。开发人员也能够开发自定义的plugin，来实现所须要的功能。

第二部分：Mobile OS就是具体的手机操做系统层了，Cordova目前支持大部分的手机OS：ios、Android、windowsphone、黑莓等等；

实际上咱们能够这么理解所谓的“跨平台”：
Cordova预先帮咱们预先封装了各类mobile os上最经常使用的本地api调用，而后以统一的JavaScript api形式提供给webapp开发者调用。对于开发者来讲，不须要关注系统底层调用实现细节，也就实现了所谓的“跨平台”。实际上，各平台涉及到本地能力的调用的时候，都被封装成了各类插件。

用cordova写的app，运行起来的体验吧。在性能上有如下几个问题
1.某些复杂效果下感受有卡顿。
2.许多css3特效不流畅，可是在PC上就很流畅

优势	缺点
跨平台，开发简单，学习成本低	WebView性能低下时，用户体验差，反应慢
框架多，插件多，可自定义插件	国外的框架，中文文档资源少
发展最先，社区资源丰富	调试不方便，既不像原生那种调试，也不像纯web那种热重载式的调试
相同代码经过编译就能跑在各平台，大大提升了多平台开发的效率	App store相关政策存在风险？

Hybrid App——Ionic

Ionic是一个开源的移动应用程序开发框架，它能够轻松地使用web技术构建高质量的跨平台的移动应用。可让咱们快速开发移动App、移动端WEB页面、微信公众平台应用，混合app web页面。

Ionic最初只支持Angular，在2019年时推出的Ionic4正式版对 React 和 Vue 全面支持。目前最新版本是Ionic5。

Ionic的本质就是一个UI框架，若是把Cordova和Ionic做比较，实际上是没有什么可比性的。

Hybrid App——vasSonic

VasSonic取名于世嘉游戏形象音速小子，是腾讯VAS(SNG增值产品部QQ会员)团队研发的一个轻量级的高性能的Hybrid框架，专一于提高页面首屏加载速度，完美支持静态直出页面和动态直出页面，兼容离线包等方案。

语言编译转换

Xamarin 是一个开放源代码平台，用于经过 .NET 构建适用于 iOS、Android 和 Windows 的新式高性能应用程序。 Xamarin 是一个抽象层，可管理共享代码与基础平台代码的通讯。 Xamarin 在提供便利（如内存分配和垃圾回收）的托管环境中运行。

Xamarin 使开发人员能够跨平台共享其应用程序（平均 90%）。 此模式容许开发人员以一种语言编写全部业务逻辑（或重复使用现有应用程序代码），但在每一个平台上实现本机性能和外观。

Xamarin 应用程序能够在电脑或 Mac 上进行编写并编译为本机应用程序包，如 Android 上的 .apk 文件，
或 iOS 上的 .ipa 文件。

Xamarin 的工做原理

Xamarin.Android 应用程序从 C# 编译为中间语言 (IL)，随后在启动应用程序时，再实时编译 (JIT)为本机程序集。 Xamarin.Android 应用程序在 Mono 执行环境中与 Android 运行时 (ART) 虚拟机并行运行。 Xamarin 向 Android. 和 Java. 命名空间提供 .NET 绑定。 Mono 执行环境经过.NET可调用包装器 (MCW) 调入这些命名空间，并向 ART 提供 Android 可调用包装器 (ACW)，这使两种环境能够相互调用代码。

在讲述Xamarin.Android架构以前，须要先了解一些Android应用程序的背景知识：

• Android应用程序试运行在Dalvik虚拟机中的，每个应用程序对应一个单独的虚拟机实例，其代码在虚拟机的解释下得以执行。
• Dalvik主要是完成对象生命周期管理，堆栈管理，线程管理，安全和异常管理，以及垃圾回收等等重要功能。
• 不一样于Java虚拟机运行java字节码，Dalvik虚拟机运行的是其专有的文件格式

Android Callable Wrappers（ACW）
使用C#开发的Android应用程序在运行的时候，C#代码是在Mono虚拟机中执行的，而Mono虚拟机是寄宿在Dalvik虚拟机中运行的，全部的C#代码都经过ACW的方式被调用。
因为须要打包Mono环境，使用C#开发的Android应用的APK文件会比原生开发的大，执行效率也会差一些。

Managed Callable Wrapper（MCW）
若是须要在C#中调用一些系统的功能或者Java实现的类库，该如何调用那？ 答案就是MCW，MCW就是一个JNI桥梁，可使用.NET调用Android的代码。MCW将整个Android.* 以及相关的命名空间经过 jar绑定的方式暴露出来，使得C#能够调用。

Xamarin.iOS 应用程序彻底预先 (AOT) 地从 C# 编译为本机 ARM 程序集代码。 Xamarin 使用选择器和注册器（共同称为“绑定”），使 Objective-C 和 C# 能够进行通讯。

对于开发者来讲，Xamarin.IOS相对于Xamarin.Android就要简单不少了，咱们用C#开发的iOS应用程序在被编译成IL代码以后，而后转交给Apple complier直接编译成iOS的本地机器码，也就是说C#写的iOS应用程序和Objective-C 写的是同样的。
透过 Ahead-of-Time (AOT) 编译程序，直接将Xamarin.iOS程序编译为ARM的执行档。编译封装完成的应用程序被直接编译为原生的二进制执行文件。

Xamarin.Forms实现原理
在Xamarin Studio中构建Xamarin.Forms跨平台的应用的时候，会生成Android以及iOS单独的项目工程，二者共享业务逻辑以及一些UI界面，在打包生成App的时候，是分开进行的，二者互不影响。每一个平台的实现原理与上面讲的是同样的。

Xamarin的性能


Xamarin.Forms 支持的平台

• iOS 9 或更高版本。
• Android 4.4 (API 19) 或更高版本。 但建议使用 Android 5.0 (API 21) 做为最小 API。 这可确保与全部 Android 支持库彻底兼容，同时仍面向大多数 Android 设备。
• 适用于 .NET Standard 2.0 支持的 Windows 10 通用 Windows 平台(UWP)版本 10.0.16299.0或更高版本。 可是，推荐使用 10.0.18362.0 版或更高版本。
• Samsung Tizen（英特尔MeeGo系统与三星LiMo系统的混合体。）
• macOS 10.13 或更高版本

Xamarin的优缺点

优势	缺点
性能接近原生	国内开发文档欠缺
Xamarin.Forms代码复用高达94%	第三方SDK的引用相对复杂
强大的企业支持	Xamarin社区不完善
完整的开发生态系统	不适用于重图形应用程序

原生渲染

原生渲染——React Native

React Native (简称RN)是Facebook于2015年4月开源的跨平台移动应用开发框架，是Facebook早先开源的JS框架 React 在原生移动应用平台的衍生产物，支持iOS和安卓两大平台。RN使用Javascript语言，相似于HTML的JSX，以及CSS来开发移动应用，所以熟悉Web前端开发的技术人员只需不多的学习就能够进入移动应用开发领域。
React Native原理

咱们接下来以ios为例，简单讲一下React Natvie的原理。

C 系列的语言，通过编译，连接等操做后，会获得一个二进制格式的可执行文，所谓的运行程序，实际上是运行这个二进制程序。
而 JavaScript 是一种脚本语言，它不会通过编译、连接等操做，而是在运行时才动态的进行词法、语法分析，生成抽象语法树(AST)和字节码，而后由解释器负责执行或者使用 JIT 将字节码转化为机器码再执行。整个流程由 JavaScript 引擎负责完成。这个引擎就是苹果提供的 JavaScript Core 的框架。
因为JavaScript 是一种单线程的语言，它不具有自运行的能力，所以老是被动调用。不少介绍 React Native 的文章都会提到 “JavaScript 线程” 的概念，实际上，它表示的是 Objective-C 建立了一个单独的线程，这个线程只用于执行 JavaScript 代码，并且 JavaScript 代码只会在这个线程中执行。
因为 JavaScript Core 是一个面向 Objective-C 的框架，在 Objective-C 这一端，咱们对 JavaScript 上下文知根知底，能够很容易的获取到对象，方法等各类信息，固然也包括调用 JavaScript 函数。真正复杂的问题在于，JavaScript 不知道 Objective-C 有哪些方法能够调用。

React Native 解决这个问题的方案是在 Objective-C 和 JavaScript 两端都保存了一份配置表，里面标记了全部 Objective-C 暴露给 JavaScript 的模块和方法。这样，不管是哪一方调用另外一方的方法，实际上传递的数据只有 ModuleId、MethodId 和 Arguments 这三个元素，它们分别表示类、方法和方法参数，当 Objective-C 接收到这三个值后，就能够经过 runtime 惟一肯定要调用的是哪一个函数，而后调用这个函数。
React Native的优缺点

优势	缺点
复用了 React 的思想，有利于前端开发者涉足移动端。	作不到 Write once, Run everywhere
可以利用 JavaScript 动态更新的特性，快速迭代。	不能作到彻底屏蔽 iOS 端或 Android 的细节
相比于原平生台，开发速度更快，相比于 Hybrid 框架，性能更好。	因为 Objective-C 与 JavaScript 之间切换存在固定的时间开销，因此性能一定不及原生

React Native的现状和将来
2018年，React Native的贡献者数量在GitHub所有仓库的中排名第二。

React Native的社区一直在发布激动人心的新项目，并经过诸如React Native Windows，React NativemacOS和React Native Web之类的仓库来探索Android和iOS之外的平台。

原生渲染——Weex

Weex是alibaba于2015年推出的一款跨平台开发框架，其 致力于使开发者能基于通用跨平台的 Web 开发语言和开发经验，来构建 Android、iOS 和 Web 应用。简单来讲，在集成了 WeexSDK 以后，你可使用 JavaScript 语言和前端开发经验来开发移动应用。
Weex使用的前端框架

Weex 渲染引擎与 DSL 语法层是分开的，Weex 并不强依赖任何特定的前端框架。目前 Vue.js 和 Rax 这两个前端框架被普遍应用于 Weex 页面开发，同时 Weex 也对这两个前端框架提供了最完善的支持。

Weex的基本结构

Weex的基本结构能够说是4层，也能够说是3层
Vue和Rax是目前Weex使用的两大前端框架（DSL领域特定语言（Domain-specific Language））
中间的这层JS Framework是用来抹平上层前端框架差别的，他会把一些渲染类的指令对接到weex Core，weexCore有点相似于浏览器自己的那个webCore。
weexCore再往下是对接Native的渲染引擎，也就是说你用前端写的Vue组件，最终被渲染成ios和android原生的组件。
Weex各模块的实现和依赖

JS Framework和Weex Core是Weex的核心。
Vue是用js写的，JS Framework干的不少是一些偏浏览器的事情，可是依然是用js写的，weex Core是C / C++写的一层，原生是和平台的语言有关。
调用方面，JS Framework会透一些DOM API之类的东西，透到vue这层。
在内部，就是JS Framework和Weex Core中间会有Bridge API作内部通讯，包含模块的调用，事件的响应，还有DOM渲染指令等。
从Weex到native直接就是一个native级别的调用，渲染原生组件。
Weex的优缺点

优势	缺点
国内团队开发，中文文档齐全	动画实现、API丰富程度及事件机制上略逊于RN
Vue做为前端开发语言，学习成本低	不支持横竖屏切换
与RN不一样，Weex的框架较轻	阿里将其捐赠给Apache，后续维护频率低（KPI产品）

不支持横竖屏切换：
Weex 将原始样式值转换为平台 UI 系统的坐标值，以后原始样式值被丢弃。这个有必定历史缘由，且当页面很是大或复杂时，丢弃后能够节省不少内存，所以原始样式值被丢弃。
同时，目前 Weex 不支持百分比布局，大量竖屏页面使用 750px 的 viewPortWidth 值为基准进行开发，页面里的坐标值都是根据 750px 为一个屏幕宽度换算后的值。
当屏幕发生旋转后，好比 iPhone6 手机，旋转后的 “宽 高” 为 “667 375”。此时咱们须要原始的样式值来从新计算出设置给排版引擎的坐标值，如前文所说，排版引擎接收的是 iOS UIKit 的坐标值。这个时候对于仍然为 "375px" 的样式，其计算出的 UIKit 坐标值为：dimension(UIKit) = 375 / 750 * 667 = 333.5仍然为宽屏下的屏幕宽度一半。
可是由于原始样式值被丢弃，咱们不能支持横竖屏切换。

原生渲染——Dcloud（uni-app）

uni-app 是一个使用 Vue.js 开发全部前端应用的框架，开发者
编写一套代码，可发布到iOS、Android、Web（响应式）、以及各类小程序（微信/支付宝/百度/头条/QQ/钉钉/淘宝）、快应用等多个平台。

不少人觉得小程序是微信先推出的，其实，DCloud才是这个行业的开创者。
DCloud于2012年开始研发小程序技术，优化webview的功能和性能，并加入W3C和HTML5中国产业联盟，推出了HBuilder开发工具，为后续产业化作准备。
2015年，DCloud正式商用了本身的小程序，产品名为“流应用”，它不是B/S模式的轻应用，而是能接近原生功能、性能的动态App，而且即点即用。
为将该技术发扬光大，DCloud将技术标准捐献给工信部旗下的HTML5中国产业联盟，并推动各家流量巨头接入该标准，开展小程序业务。360手机助手率先接入，在其3.4版本实现应用的秒开运行。
随后DCloud推进大众点评、携程、京东、有道词典、惟品会等众多开发者为流应用平台提供应用。
在2015年9月，DCloud推动微信团队开展小程序业务，演示了流应用的秒开应用、扫码获取应用、分享连接获取应用等众多场景案例，以及分享了webview体验优化的经验。
微信团队通过分析，于2016年初决定上线小程序业务，但其没有接入联盟标准，而是订制了本身的标准。
DCloud持续在业内普及小程序理念，推动各大流量巨头，包括手机厂商，陆续上线相似小程序/快应用等业务。
部分公司接入了联盟标准，但更多公司因利益纷争严重，标准难以统一。
技术是纯粹的，不该该由于商业利益而分裂。开发者面对如此多的私有标准不是一件正确的事情。
形成混乱的局面非DCloud所愿。因而咱们决定开发一个免费开源的框架。
既然各巨头没法在标准上达成一致，那么就经过这个框架为开发者抹平各平台差别。
这，就是uni-app的由来。

uniapp的特色
uni-app是双渲染引擎，在 App端内置了一个webview和一个基于 weex 改进的原生渲染引擎，提供了原生渲染能力。

在App端：

• 若是使用vue页面，则使用webview渲染
• 若是使用nvue页面(native vue的缩写)，则使用原生渲染

以往的 weex ，有个很大的问题是它只是一个高性能的渲染器，没有足够的API能力（好比各类push sdk集成、蓝牙等能力调用），使得开发时很是依赖原生工程师协做，开发者原本想节约成本，结果须要前端、iOS、Android 3类人开发，适得反。

nvue 解决了这个问题，让前端工程师能够直接开发完整 App，并提供丰富的插件生态和云打包。这些组合方案，帮助开发者切实的提升效率、下降成本。

自渲染

Flutter

Flutter 是 Google 开源的 UI 工具包，帮助开发者经过一套代码库高效构建多平台精美应用，支持移动、Web、桌面和嵌入式平台。Flutter 开源、免费，拥有宽松的开源协议，适合商业项目。
Flutter的原理

• 原生渲染（RN / Weex）

• Flutter

Flutter 也提供响应式风格的视图。 Flutter 使用编译的编程语言即Dart 的方法来避免 JsBridge引发的性能问题,。 Dart 被“提早编译”（AOT）编译成多个平台的本地代码。 这使得 Flutter无需经过JsBridge就能够与平台进行通讯。 编译为本机代码也能够提升应用程序的启动时间。

Flutter不使用OEM Widgets（或DOM WebViews），它提供了本身的 Widgets。

Flutter将 Widgets 和渲染器从平台移动到应用程序中，从而使其能够自定义和扩展。 Flutter对平台的需求平台是一个画布，在这个画布中，Widgets 能够呈如今设备屏幕上，并能够访问事件（触摸，定时器等）和服务（位置，摄像机等）。Dart程序（绿色）和本地平台代码（iOS或Android蓝色）之间仍然存在一个接口，能够进行数据编码和解码，但这可能比JavaScript Bridge 快几个数量级。将 Widgets 和渲染器移动到应用程序中会影响应用程序的大小。 Android上Flutter应用程序的最小大小约为6.7MB，这部分是须要开发者来权衡利弊的。
高效率

Flutter的热重载可帮快速地进行测试、构建UI、添加功能并更快地修复错误。在iOS和Android模拟器或真机上能够在亚秒内重载，而且不会丢失状态。
Flutter高一致性

Flutter高性能

框架对比与选型

类型	Cordova	Xamarin	React Native	Weex	Uniapp	Flutter
性能	低	高	较高	中	高	高
上手难度	容易	较高	较高	容易	容易	中
核心	JavaScript	.NET	React	Weex	vue	Dart
框架轻重	轻	较重	较重	较轻	轻	重
特色	适合单页面	适合开发总体App	适合开发总体App	适合单页面	适合开发总体App	适合开发总体App
社区	活跃度较低	活跃度低	活跃度高，Facebook维护	活跃度中，目前托管apache	活跃度高，Dcloud维护	活跃度高，Google维护
支持平台	Android、IOS、Windows、MacOS	Android、IOS、Windows	Android、IOS、Web	Android、IOS、Web	Android、IOS、Web、小程序、快应用	Android、IOS、MacOS、Web、Linux、Windows、Fuchsia
适应性	Web开发学习成本低	.NET C#工程师开发	Web开发学习成本低	Web开发学习成本低	Web开发学习成本低	Java、C++、C#、开发学习成本低

跨平台技术的分类没有标准的答案，这里也只是粗略的进行分类，并对每一个分类的主流框架进行介绍，实际上还有不少框架没有提到，它们不是没落了，就是缺点明显难以使用，再就是大公司的 KPI 产物。跨平台技术的演进比如百家争鸣，极大的促进了跨平台技术的发展。在我看来，这些技术让不一样技术分支的程序员均可以参与到移动开发中，享受移动开发的乐趣，从这个角度来看这些跨平台技术的优劣之分是很难去评判的。

无论什么跨平台开发框架，都要去选择最合适本身团队的。但无论选择何种框架，前提还得对原生的开发环境以及开发模式有必定的了解，否则也是事倍功半。虽然如今市面上移动端的跨平台开发工具开发出来的App性能都和原生有必定的差距，但仍是有他们本身的优点，并非全部公司都能长期承担起原生App开发与维护的成本，这也是他们能长期存在的理由。

结束