跨平台移动开发框架概述

引言


在工作中,我曾多次不得不选择适合移动开发的技术。 下面,我尝试根据使用的方法,优点和缺点对主要框架进行收集和分类。


如果我的某些信息不正确或过时-欢迎发表评论。


跨平台开发的共同缺点


有限的平台支持


任何跨平台框架都是本机平台之上的抽象层,并且允许您仅访问框架直接支持的功能。


在大多数情况下,可以通过为框架编写本机插件来扩展对平台的支持,但是在某些情况下,这可能会使开发变得非常复杂。 轰动一时的AirBnb文章中的一个新示例是React Native,它目前不知道如何使用64位Android库立即使用。


您还需要注意,本机插件和跨平台应用程序的主要代码通常在不同的进程中执行,并且它们之间的交互会导致性能问题。 对于使用传感器或SQLite来说,这通常不是问题,但是,例如,如果您将OpenCV库用作本机插件,并开始在其与主应用程序之间抛出视频,则速度会很慢。


劳动力市场上的供应有限


首先,开发人员的存在取决于框架的普遍性。 在React Native下查找人员甚至比本地开发人员更容易,但是例如,使用Flutter则困难得多。


需要考虑多少因素取决于任务。 大多数初创公司可能不会关注它,因为学习新技术更可能是现有和潜在员工的红利。 另一方面,大企业被迫考虑劳动力市场。


支持风险


可以相信,对跨平台框架的支持将终止的可能性比针对移动OS发生相同事件的可能性要高得多。


实际上,这个问题很复杂。 可以像框架一样关闭OS(Windows Phone的示例是完全新鲜的)。 另外,在本机开发中,某些技术也可能是封闭的,有时跨平台框架上的代码更具生存性。


一个例子是在游戏和多媒体领域-苹果公司将把OpenGL技术发送到其操作系统上,并且编写本机3D应用程序的每个人都必须完全重写它们以发布新版本。 同时,对于那些使用跨平台游戏引擎的用户(例如Unity),更新将不需要任何额外的努力。


主要方向


混合开发,HTML + JavaScript


从技术上讲,混合类型的应用程序是在嵌入式浏览器中显示的HTML页面。 通常,此方法不需要框架,但是Cordova提供了一组用于访问平台功能的插件,这就是为什么通常使用它们。


主要优点


最低开发成本


混合方法使您不仅可以重用开发人员的技能,而且可以重用为网站编写的代码。


整合网络元素的能力


HTML / JS的库数量大大超过了本机应用程序的库数量。 有趣的是,例如Google Analytics(分析)或各种各样的广告网络。


关键缺点


生产力低下


现代JavaScript本身使用JIT编译,经过了很好的优化并且可以快速运行,但是基于DOM树构建接口并不是一个非常有效的过程。 现代JS框架的使用提供了更高级别的负载。 对于较弱的电话和/或积极使用交互元素,这可能是一个问题。


“原生的感觉”


这是相当非正式的,但非常重要的一点。 浏览器中的网站对手势的响应和显示与移动应用程序略有不同。 这种感觉最明显的元素是,按下时会延迟300毫秒,科尔多瓦决定,但还有许多其他细节。


浏览器兼容性问题


在较旧版本的Android(版本5之前)上,WebView是平台的一部分,并且不会自动更新。 因此,将不可能在这些设备上的混合应用程序中使用现代浏览器功能。


结果,混合应用程序要么限制了Android的最低版本(目前大约落后了13%的设备),要么在应用程序代码中包含了WebView(CrossWalk项目),从而使应用程序大小增加了数十兆字节。


目的地


快速创建一次性应用程序。 如果有大量的开发预算,通常不愿采用混合方法。


基本框架


所有主要混合框架的核心是Cordova,它提供对本机插件的访问。 PhoneGap提供了用于在Cordova上进行构建的工具,而Ionic是用于在其中构建用户界面的框架和一组组件。


本机UI,通用代码


重要的是要注意,使用这种方法,用户界面和业务逻辑是在通过网桥交互的不同进程中执行的。 该方法有许多缺点。


这种方法有几个实现选项。


可执行代码的分类


编译代码


Xamarin使用C#语言,将其编译为本地平台代码。 通常,此方法可提供较小的应用程序大小和较高的速度。


用JIT编译解释语言


这种方法中的大多数框架都使用JavaScript处理业务逻辑。


通过接口描述方法分类


本机工具


Xamarin不仅使用本机接口组件,而且以每个平台可接受的格式描述它们。


通用界面元素


Xamarin Forms和Appcelerator使用它们自己的一组小部件,这些小部件将转换为每个平台的适当接口组件。


不同平台的界面不同,但采用通用方法


React Native在本地接口组件周围使用包装器。 因此,针对每个平台分别描述了接口,但是描述方法是相同的。


主要优点


完全本机界面


首先,应用程序的外观和“感觉”与本机应用程序完全一致。


其次,它允许在应用程序中使用本机接口库。 以其他方式使用专注于移动应用程序的原生广告(Native Ads)将不起作用。 的确,对于这种方法,相关库的集合非常有限。 我只知道React Native中对Facebook Native Ads的支持。


重用开发人员技能的能力


设计了该组的许多框架,以便其他领域的开发人员可以学习如何以最小的成本创建移动应用程序。 对于React,本机是React,对于Xamarin,.NET等。


关键缺点


接口功能的限制,或单独开发的额外费用


减号的格式取决于描述接口的方式对框架的分类:


Xamarin允许您使用平台的几乎所有功能,但是您必须在每个平台的界面上花费大量时间。 结果,人工成本与本地开发相比并不少。


Xamarin Forms和Appcelerator仅允许您描述一次接口,但是它们只能使用非常有限的本机功能子集(正式的来说,不超过每个平台功能集的最小交集)。


React Native处于中间,结合了两个缺点,但是形式不太明显。
接口交互性能
在不同过程中,接口和业务逻辑的执行因素在这里发挥了作用。 当需要通过网桥高速交换大量信息时(高频复杂动画),这种方法可能会遇到困难。


内存泄漏


内存泄漏可以在任何应用程序中发生,但是大多数标准情况是由垃圾收集器处理的。


具有本机接口的跨平台应用程序的问题再次在于它们在具有单独的垃圾收集器的两个进程中运行。 如果业务逻辑对象引用接口对象,则此接口对象不是垃圾,因为 从桥上有一个链接。 如果接口对象引用回业务逻辑对象,即使没有更多引用,它们也不会被视为垃圾。


遇到问题的机会及其规模直接取决于应用程序。 如果与该接口关联的对象被主动创建并在其中删除(如无休止的滚动),则泄漏的可能性会增加。 如果这些物体很大(例如,图像),则泄漏的影响会增加。


实际上,使用本机插件时也存在此问题,这些插件也在单独的过程中执行。 但是,在大多数情况下,要么没有大型对象的这种密集操作,要么以严格的过程方法进行交互,而没有交叉引用。


目的地


具有完全本机界面的应用程序,尤其是在具有相关技术专家的情况下。


基本框架


反应本机


它具有Facebook支持,并使用最受欢迎的React JS框架的方法,因此非常受欢迎。 最近一篇有关AirBnb放弃React Native的文章引起了很大的反响,但是如果意识到风险,那将是一个非常有效的解决方案。


Xamarin


除了主要方法外,它还具有Xamarin.Forms库,该库使您可以高效地跨平台设计简单的界面。 受到Microsoft的积极支持。 在服务器上使用ASP.NET时,它允许您通过使用服务器上和移动应用程序中的通用业务逻辑类来另外节省一定数量的工作。


本机犯罪


它是为拥有其他JS框架(Angular和Vue.js)的开发人员在React Native上建模的。 不太流行,但是在建筑方面有许多更现代的解决方案。


本机UI,通用代码


几乎所有的游戏引擎都使用这种方法,但是它们不在本文讨论范围之内。


这种方法的原理是应用程序使用自己的代码和自己的用户界面呈现。


主要优点


高性能接口


实际上,自己绘制自己的界面的应用程序执行与本机界面中的OS相同的操作。 从理论上讲,它甚至可以更快,因为 在进程和内核之间没有切换,但是在实践中,其他因素影响特定接口的渲染速度,起着更大的作用。


“设计界面”


本机应用程序使用现成的接口组件,并且对它们可以完成的操作有一些限制。 反过来,自己绘制自己的界面的应用程序也没有这种限制,可以自由地将现成的元素与单独的渲染混合在一起。


关键缺点


这些缺点仅与模仿标准OS接口的应用程序有关。 如前所述,对于设计界面和游戏,这种方法是最佳的。


申请规模


采用这种方法的应用程序必须携带用于呈现所有接口元素(包括有条件的标准接口元素)的代码。 这会影响安装过程中应用程序的大小以及操作过程中的RAM。


如果第一个问题可以通过有效的Tree Shaking(如Flutter的最新版本)来最小化,则这些应用程序将通过RAM稳定地丢失其本机内存。 但是,此问题也是其他跨平台框架的特征。


本机界面


默认情况下,该应用程序在所有平台上看起来都是相同的,这可能会使用户感到不适。 主题用于解决这些问题,但是它们无法营造出完全本机应用程序的感觉。


但是,还有一个更大的缺点-使用这种方法,最难使用为本机应用程序(包括前面提到的本机广告)创建的第三方界面元素。


目的地


公共应用程序,尤其是带有设计界面的应用程序。


基本框架


颤动


Google正在推动Flutter作为其未来Fuscia OS的核心跨平台开发框架和接口。 尽管该框架还很年轻(处于“发布预览”阶段),并且并不常见,但是它很快就变得流行起来。 使用Dart语言(编译成本机代码)。


它具有年轻人的所有优点和缺点-考虑到其前辈的错误,经过深思熟虑的体系结构,但生态系统非常有限。


QT Mobile


在桌面QT的开发人员中很受欢迎。 JavaScript可用于开发中。 没有大公司的支持不是很受欢迎。


基维


另一个不是很流行的框架很有趣,主要是因为它是列表中唯一使用Python的框架。 对于只熟悉这种语言的开发人员(信息技术的某些领域有很多),这可能至关重要。


相关资料


在Xamarin和类似框架中的内存
比较本机应用程序,Flutter和React Native的性能

Source: https://habr.com/ru/post/zh-CN421227/


All Articles