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

简介

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

移动跨平台开发介绍

传统移动端开发

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

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高性能

框架对比与选型

性能	低	高	较高	中	高	高
上手难度	容易	较高	较高	容易	容易	中
核心	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开发与维护的成本，这也是他们能长期存在的理由。

结束