关于cordova:移动跨平台开发框架解析与选型

简介

在以后挪动端跨平台框架漫天飞的状况下，很多开发者不晓得该抉择哪种框架来进行开发，哪种框架适宜前期保护、稳定性等问题。本文会带大家理解目前市场上比拟风行的一些框架的比照

挪动跨平台开发介绍

传统挪动端开发

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

传统挪动端开发优缺点

跨平台技术的诞生

早在 2010 年，过后从事 Android 和 iOS 开发的人很少，也不火，所有人都在“摸着河底过河”，我的项目更没有第三方框架一说，大都是本人写的，不像当初各种的框架满天飞。随着挪动开发的倒退，互联网公司也是层出不穷，有些公司迫于竞争，想要更疾速的更省老本的进行开发，就不再满足 Android 端一套代码，iOS 端一套代码。同时，其余技术畛域和各大公司也都各自推出相干的技术，这样跨平台技术随之诞生，并且开始在公司中生根发芽。
因为 Android 和 iOS 生态很大，咱们能够把它们比作第一级生态，也有厂商想要颠覆这两个零碎，但都失败了，因而建设次级生态才是最稳当的策略，Android 平台更加凋谢，因而建设次级生态的核心就是 Android，次生态的模式多种多样，比方在 Android 零碎的根底上魔改建设本人的生态，再或者推出各种跨平台技术建设生态。跨平台技术产生的框架切实太多了，很多还没等咱们去学去理解，它们就败落了，也就成为了跨平台技术倒退的一个适度产物。

挪动跨平台开发演进

为什么要跨平台开发？

作为开发不同利用而应用不同的开发语言，对开发者而言并不是一个坏事。实质上，跨平台开发是为了减少代码复用，缩小开发者对多个平台差别适配的工作量，升高开发成本，进步业务专一的同时，提供比 web 更好的体验，跨平台开发正是解决了这一问题。

跨平台开发的优缺点

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

挪动跨平台开发框架解析

跨平台技术演进

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 上就很晦涩

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 的优缺点

原生渲染

原生渲染——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 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 的优缺点

不反对横竖屏切换：
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 高性能

框架比照与选型

跨平台技术的分类没有规范的答案，这里也只是粗略的进行分类，并对每个分类的支流框架进行介绍，实际上还有很多框架没有提到，它们不是败落了，就是毛病显著难以使用，再就是大公司的 KPI 产物。跨平台技术的演进好比百家争鸣，极大的促成了跨平台技术的倒退。在我看来，这些技术让不同技术分支的程序员都能够参加到挪动开发中，享受挪动开发的乐趣，从这个角度来看这些跨平台技术的优劣之分是很难去评判的。

不论什么跨平台开发框架，都要去抉择最合适本人团队的。但不论抉择何种框架，前提还得对原生的开发环境以及开发模式有肯定的理解，不然也是事倍功半。尽管当初市面上挪动端的跨平台开发工具开发进去的 App 性能都和原生有肯定的差距，但还是有他们本人的劣势，并不是所有公司都能长期承当起原生 App 开发与保护的老本，这也是他们能长期存在的理由。

完结