移动端跨平台技术总结

标签: 移动 跨平台 技术 | 发表时间:2017-03-29 23:08 | 作者:xiangzhihong8
出处:http://blog.csdn.net

概述

曾经大家以为在手机上可以像桌面那样通过 Web 技术来实现跨平台开发,却因为性能或其他问题而放弃,不得不针对不同平台开发多个版本。这也违背了跨平台开发的初衷。而React Native让跨平台移动端开发在次回到人们的视野中,其成功的原因除了他“一次编写处处运行”,还因为它相比h5等前端技术,有了更接近原生的体验。
为了方便理解,笔者将跨平台技术分为4大流派:

  • Web 流:也被称为 Hybrid 技术,它基于 Web 相关技术来实现界面及功能
  • 代码转换流:将某个语言转成 Objective-C、Java 或 C#,然后使用不同平台下的官方工具来开发
  • 编译流:将某个语言编译为二进制文件,生成动态库或打包成 apk/ipa/xap 文件
  • 虚拟机流:通过将某个语言的虚拟机移植到不同平台上来运行

web流

Web 流,如大家熟知的PhoneGap/Cordova等技术,它将原生的接口封装后暴露给 JavaScript,然后通过系统自带的 WebView 运行,也可以视野自己内嵌Chrome内核。
Web 流最常被吐槽的就是性能差,渲染速度慢。现在说到 Web 性能差主要说的是 Android 下比较差,在 iOS 下已经很流畅了。
说到性能差,主要原因是在Android和ios的早期设备中,由于没有实现GPU加速,所以造成每次重绘界面的卡顿。
而造成渲染慢的第二个原因是:css过于复杂。因为从实现原理上看 Chrome 和 Android View 并没有本质上的差别,但过于复杂的css会加重gpu的负担。那是不是可以通过简化 CSS 来解决?实际上还真有人这么尝试了,比如 Famo.us,它最大的特色就是不让你写 CSS,只能使用固定的几种布局方法,完全靠 JavaScript 来写界面,所以它能有效避免写出低效的 CSS,从而提升性能。
造成绘制缓慢的第三个原因是,业务需求的复杂,如要实现超长的 ListView商品展示。因为 DOM 是一个很上层的 API,使得 JavaScript 无法做到像 Native 那样细粒度的控制内存及线程,所以难以进行优化,则在硬件较差的机器上会比较明显
上面三个问题现在都不好解决。其实除了性能之外,Web 流更严重的问题是功能缺失。比如 iOS 8 就新增 4000+ API,而 Web 标准需要漫长的编写和评审过程,而等到web审核通过,即便是Cordova这样的框架自己封装也是忙不过来的。所以为了更好地使用系统新功能,Native是最快的选择。
虽然前面提到 HTML/CSS 过于复杂导致性能问题,但其实这正是 Web 最大的优势所在,因为 Web 最初的目的就是显示文档,如果你想显示丰富的图文排版,虽然 iOS/Android 都有富文本组件,但比起 CSS 差太远了,所以在很多 Native 应用中是不可避免要嵌 Web 的。

代码转换流

不同平台下的官方语言不一样,并且平台对官方语言的支持最好,这就导致同样的逻辑,我们需要写多套代码。比如Android平台用Java,ios用oc或者swift。于是就有人想到了通过代码转换的方式来减少重复的工作量,这就是所以的代码转换流。
这种方式虽然听起来不是很靠谱,但它却是成本和风险都最小的,因为代码转换后就可以用官方提供的各种工具了,和普通开发区别不大。并且转换后,可以利用原生的优点,这也可以减少兼容的问题。
目前存在的几种代码转换方式:

将 Java 转成 Objective-C

j2objc 能将 Java 代码转成 Objective-C,据说 Google 内部就是使用它来降低跨平台开发成本的,比如 Google Inbox 项目就号称通过它共用了 70% 的代码,效果很显著。
可能有人会觉得奇怪,为何 Google 要专门开发一个帮助大家写 Objective-C 的工具?还有媒体说 Google 做了件好事,其实吧,我觉得 Google 这算盘打得不错,因为基本上重要的应用都会同时开发 Android 和 iOS 版本,有了这个工具就意味着,你可以先开发 Android 版本,然后再开发 iOS 版本。。。
既然都有成功案例了,这个方案确实值得尝试,而且关键是会 Java 的人多啊,可以通过它来快速移植代码到 Objective-C 中。

将 Objective-C 转成 Java

除了有 Java 转成 Objective-C,还有 Objective-C 转成 Java 的方案,那就是 MyAppConverter,比起前面的 j2objc,这个工具更有野心,它还打算将 UI 部分也包含进来,从它已转换的列表中可以看到还有 UIKit、CoreGraphics 等组件,使得有些应用可以不改代码就能转成功,不过这点我并不看好,对于大部分应用来说并不现实。
由于目前是收费项目,我没有尝试过,对技术细节也不了解,所以这里不做评价。

将 Java 转成 C

Mono 提供了一个将 Java 代码转成 C# 的工具 Sharpen,不过似乎用的人不多,Star 才 118,所以看起来不靠谱。
还有 JUniversal 这个工具可以将 Java 转成 C#,但目前它并没有发布公开版本,所以具体情况还待了解,它的一个特色是自带了简单的跨平台库,里面包括文件处理、JSON、HTTP、OAuth 组件,可以基于它来开发可复用的业务逻辑。
比起转成 Objective-C 和 Java 的工具,转成 C# 的这两个工具看起来都非常不成熟,估计是用 Windows Phone 的人少。

XMLVM

除了前面提到的源码到源码的转换,还有 XMLVM 这种与众不同的方式,它首先将字节码转成一种基于 XML 的中间格式,然后再通过 XSL 来生成不同语言,目前支持生成 C、Objective-C、JavaScript、C#、Python 和 Java。
虽然基于一个中间字节码可以方便支持多语言,然而它也导致生成代码不可读,因为很多语言中的语法糖会在字节码中被抹掉,这是不可逆的,以下是一个简单示例生成的 Objective-C 代码,看起来就像汇编:

  XMLVM_ENTER_METHOD("org.xmlvm.tutorial.ios.helloworld.portrait.HelloWorld", "didFinishLaunchingWithOptions", "?")
 XMLVMElem _r0;
 XMLVMElem _r1;
 XMLVMElem _r2;
 XMLVMElem _r3;
 XMLVMElem _r4;
 XMLVMElem _r5;
 XMLVMElem _r6;
 XMLVMElem _r7;
 _r5.o = me;
 _r6.o = n1;
 _r7.o = n2;
 _r4.i = 0;
 _r0.o = org_xmlvm_iphone_UIScreen_mainScreen__();
 XMLVM_CHECK_NPE(0)
 _r0.o = org_xmlvm_iphone_UIScreen_getApplicationFrame__(_r0.o);
 _r1.o = __NEW_org_xmlvm_iphone_UIWindow();
 XMLVM_CHECK_NPE(1)
...

终上所述,虽然代码转换这种方式风险小,但我觉得对于很多小 APP 来说共享不了多少代码,因为这类应用大多数围绕 UI 来开发的,大部分代码都和 UI 耦合,所以公共部分不多,其借鉴性意义不大。

编译流

编译流比代码转换流的代码转换更进一步,它直接将某个语言编译为普通平台下能够识别的二进制文件。采用这种方式主要有以下特点:

优点

  • 可以重用一些实现很复杂的代码,比如之前用 C++ 实现的游戏引擎,重写一遍成本太高
  • 编译后的代码反编译困难

缺点

  • 转换过于复杂,并且后期定位和修改成本会很高
  • 编译后体积太大,尤其是支持 ARMv8 和 x86等CPU架构的时候

接下来,我们通过不同的语言来介绍这个流派下不同的技术实现。

C++方案

因为目前Android、iOS和Windows Phone都提供了对C++开发的支持。特别是C++ 在实现非界面部分,性能是非常高效的。而如果C++ 要实现非界面部分,还是比较有挑战的。这主要是因为Android 的界面绝大部分是 Java 实现,而在 iOS 和 Windows Phone下可以分别使用C++的超集Objective-C++和 C++/CX来开发。那么要解决用C++开发Android界面,目前主要有两种方案:

  • 通过 JNI 调用系统提供的 Java 方法
  • 自己画 UI

第一种方式虽然可行,但是代码冗余高,实现过于复杂。那第二种方式呢,比如 JUCE 和 QT就是自己用代码画的。不过在Android 5下就悲剧了,很多效果都没出来,比如按钮没有涟漪效果。根本原因在于它是通过 Qt Quick Controls 的自定义样式来模拟的,而不是使用系统UI组件,因此它享受不到系统升级自动带来的界面优化。
当然我们可以使用OpenGL来绘制界面,因为EGL+OpenGL本身就是跨平台的。并且目前大多数跨平台游戏底层都是这么做的。
既然可以基于 OpenGL 来开发跨平台游戏,是否能用它来实现界面?当然是可行的,而且Android 4的界面就是基于OpenGL的,不过它并不是只用 OpenGL 的 API,那样是不现实的,因为 OpenGL API 最初设计并不是为了画 2D 图形的,所以连画个圆形都没有直接的方法,因此Android 4中是通过Skia将路径转换为位置数组或纹理,然后再交给 OpenGL 渲染的。
然而直接使用OpenGL来做界面的绘制,代价是非常大的,并且目前在各个平台下都会有良好的官方支持。因此对于大多数应用来说自己画UI是很不划算的。

Xamarin

Xamarin 可以使用 C# 来开发 Android 及 iOS 应用,它是从 Mono 发展而来的,目前看起来商业运作得不错,相关工具及文档都挺健全。
因为它在 iOS 下是以 AOT 的方式编译为二进制文件的,所以把它归到编译流来讨论,其实它在 Android 是内嵌了 Mono 虚拟机 来实现的,因此需要装一个 17M 的运行环境。
在 UI 方面,它可以通过调用系统 API 来使用系统内置的界面组件,或者基于 Xamarin.Forms 开发定制要求不高的跨平台 UI。
对于熟悉 C# 的团队来说,这还真是一个看起来很不错的,但这种方案最大的问题就是相关资料不足,遇到问题很可能搜不到解决方案,不过由于时间关系我并没有仔细研究,推荐看看这篇文章,其中谈到它的优缺点是:

优点

  • 开发 app 所需的基本功能全部都有
  • 有商业支持,而且这个项目对 Windows Phone 很有利,微软会大力支持

缺点

  • 如果深入后会发现功能缺失,尤其是定制 UI,因为未开源使得遇到问题时不知道如何修复
  • Xamarin 本身有些 Bug
  • 相关资源太少,没有原生平台那么多第三方库
  • Xamarin studio 比起 Xcode 和 Android Studio 在功能上还有很大差距

Objective-C 编译为 Windows Phone

微软知道自己的 Windows Phone 太非主流,所以很懂事地推出了将 Objective-C 项目编译到 Windows Phone 上运行的工具,目前这个工具的相关资料很少,鉴于 Visual Studio 支持 Clang,所以极有可能是使用 Clang 的前端来编译,这样最大的好处是以后支持 Swift 会很方便,因此我归到编译流。

Swift – Apportable/Silver

apportable 可以直接将 Swift/Objective-C 编译为机器码,但它官网的成功案例全部都是游戏,所以用这个来做 APP 感觉很不靠谱。
所以后来它又推出了 Tengu 这个专门针对 APP 开发的工具,它的比起之前的方案更灵活些,本质上有点类似 C++ 公共库的方案,只不过语言变成了 Swift/Objective-C,使用 Swift/Objective-C 来编译生成跨平台的 SO 文件,提供给 Android 调用。
另一个类似的是 Silver,不过目前没正式发布,它不仅支持 Swift,还支持 C# 和自创的 Oxygene 语言(看起来像 Pascal),在界面方面它还有个跨平台非 UI 库 Sugar,然而目前 Star 数只有 17,太非主流了,所以不值得研究它。

Go

Go做为后端服务开发语言,专门针对多处理器系统应用程序的编程进行了优化,使用Go编译的程序可以媲美C或C++代码的速度,而且更加安全、支持并行进程。Go 从 1.4 版本开始支持开发Android应用(并在1.5 版本支持iOS)。虽然能同时支持Android和ios,但是目前可用的api很少,Go仍然专注于后端语言开发。
Android的View层完全是基于Java写的,要想用Go来写UI不可避免要调用Java 代码,而这方面Go还没有简便的方式,目前Go调用外部代码只能使用cgo,通过cgo再调用jni,这就不可避免的需要写很多的中间件。而且 cgo 的实现本身就对性能有损失,除了各种无关函数的调用,它还会锁定一个 Go 的系统线程,这会影响其它 gorountine 的运行,如果同时运行太多外部调用,甚至会导致所有 gorountine 等待
所以使用Go开发跨平台移动端应用目前不靠谱。

虚拟机流

除了编译为不同平台下的二进制文件,还有另一种常见做法是通过虚拟机来支持跨平台运行,比如 JavaScript 和 Lua 都是天生的内嵌语言,所以在这个流派中很多方案都使用了这两个语言。
不过虚拟机流会遇到两个问题:一个是性能损耗,另一个是虚拟机本身也会占不小的体积。

Java 系

说到跨平台虚拟机大家都会想到 Java,因为这个语言一开始就是为了跨平台设计的,Sun 的 J2ME 早在 1998 年就有了,在 iPhone 出来前的手机上,很多小游戏都是基于 J2ME 开发的,这个项目至今还活着,能运行在 Raspberry Pi 上。
前面提到微软提供了将 Objective-C 编译在 Windows Phone 上运行的工具,在对 Android 的支持上我没找到的详细资料,所以就暂时认为它是虚拟机的方式,从 Astoria 项目的介绍上看它做得非常完善,不仅能支持 NDK 中的 C++,还实现了 Java 的 debug 接口,使得可以直接用 Android Studio 等 IDE 来调试,整个开发体验和在 Android 手机上几乎没区别。
另外 BlackBerry 10 也是通过内嵌虚拟机来支持直接运行 Android 应用,不过据说比较卡。
不过前面提到 C# 和 Java 在 iOS 端的方案都是通过 AOT 的方式实现的,目前还没见到有 Java 虚拟机的方案,我想主要原因是 iOS 的限制,普通 app 不能调用 mmap、mprotect,所以无法使用 JIT 来优化性能,如果 iOS 开放,或许哪天有人开发一个像微软那样能直接在 iOS 上运行 Android 应用的虚拟机,就不需要跨平台开发了,大家只需要学 Android 开发就够了。

Titanium/Hyperloop

Titanium 应该不少人听过,它和 PhoneGap 几乎是同时期的著名跨平台方案,和 PhoneGap 最大的区别是:它的界面没有使用 HTML/CSS,而是自己设计了一套基于 XML 的 UI 框架 Alloy,代码类似下面这个样子:

  app/styles/index.tss
 ".container": {
 backgroundColor:"white"
 },
 // This is applied to all Labels in the view
 "Label": {
 width: Ti.UI.SIZE,
 height: Ti.UI.SIZE,
 color: "#000", // black
 transform: Alloy.Globals.rotateLeft // value is defined in the alloy.js file
 },
 // This is only applied to an element with the id attribute assigned to "label"
 "#label": {
 color: "#999" /* gray */
 }

前面我们说过由于 CSS 的过于灵活拖累了浏览器的性能,那是否自己建立一套 UI 机制会更靠谱呢?尽管这么做对性能确实有好处,然而它又带来了学习成本问题,做简单的界面问题不大,一旦要深入定制开发就会发现相关资料太少,所以还是不靠谱。

Titanium 还提供了一套跨平台的 API 来方便调用,这么做是它的优点更是缺点,尤其是下面三个问题:

API 有限,因为这是由 Titanium 提供的,它肯定会比官方 API 少且有延迟,Titanium 是肯定跟不过来的
相关资料及社区有限,比起 Android/iOS 差远了,遇到问题都不知道去哪找答案
缺乏第三方库,第三方库肯定不会专门为 Titanium 提供一个版本,所以不管用什么都得自己封装
Titanium 也意识到了这个问题,所以目前在开发下一代的解决方案 Hyperloop,它可以将 JavaScript 编译为原生代码,这样的好处是调用原生 API 会比较方便,比如它的 iOS 是这样写的:

   @import("UIKit");
 @import("CoreGraphics");
 var view = new UIView();
 view.frame = CGRectMake(0, 0, 100, 100);

这个方案和之前的说的Xamarin如出一辙,也是将JavaScript将翻译为Objective-C然后由官方的方案运行。不过这项目开发都快三年了,但至今仍然是试验阶段,显然有点不靠谱。

NativeScript

之前说到 Titanium 自定义 API 带来的各种问题,于是就有人换了个思路,比如前段时间推出的 NativeScript,它的方法说白了就是用工具来自动生成 wrapper API,和系统 API 保持一致。
有了这个自动生成 wrapper 的工具,它就能方便基于系统 API 来开发跨平台组件,以简单的 Button 为例,源码在 cross-platform-modules/ui/button 中,它在 Android 下是这样实现的:

  export class Button extends common.Button {
 private _android: android.widget.Button;
 private _isPressed: boolean;
  public _createUI() {
 var that = new WeakRef(this);
 this._android = new android.widget.Button(this._context);
 this._android.setOnClickListener(new android.view.View.OnClickListener({
 get owner() {
 return that.get();
 },
 onClick: function (v) {
 if (this.owner) {
 this.owner._emit(common.knownEvents.tap);
 }
 }
 }));
 }
 }

在 iOS 下是这样实现的:

   export class Button extends common.Button {
 private _ios: UIButton;
 private _tapHandler: NSObject;
 private _stateChangedHandler: stateChanged.ControlStateChangeListener;
  constructor() {
 super();
 this._ios = UIButton.buttonWithType(UIButtonType.UIButtonTypeSystem);
  this._tapHandler = TapHandlerImpl.new().initWithOwner(this);
 this._ios.addTargetActionForControlEvents(this._tapHandler, "tap", UIControlEvents.UIControlEventTouchUpInside);
  this._stateChangedHandler = new stateChanged.ControlStateChangeListener(this._ios, (s: string) => {
 this._goToVisualState(s);
 });
 }
  get ios(): UIButton {
 return this._ios;
 }
 }

可以看到用法和官方 SDK 中的调用方式是一样的,只不过语言换成了 JavaScript,并且写法看起来比较诡异罢了,风格类似前面的 Hyperloop 类似,所以也同样会有语法转换的问题。
这么做最大的好处就是能完整支持所有系统 API,对于第三方库也能很好支持,但它目前最大缺点是生成的文件体积过大,即便什么都不做,生成的 apk 文件也有 8.4 MB,因为它将所有 API binding 都生成了,而且这也导致在 Android 下首次打开速度很慢。
从底层实现上看,NativeScript 在 Android 下内嵌了 V8,而在 iOS 下内嵌了自己编译的 JavaScriptCore(这意味着没有 JIT 优化,具体原因前面提到了),这样的好处是能调用更底层的 API,也避免了不同操作系统版本下 JS 引擎不一致带来的问题,但后果是生成文件的体积变大和在 iOS 下性能不如 WKWebView。
WKWebView 是基于多进程实现的,它在 iOS 的白名单中,所以能支持 JIT。它的使用体验很不错,做到了一键编译运行,而且还有 MVVM 的支持,能进行数据双向绑定。
在我看来 NativeScript 和 Titanium 都有个很大的缺点,那就是排它性太强,如果你要用这两个方案,就得完整基于它们进行开发,不能在某些 View 下进行尝试,也不支持直接嵌入第三方 View,有没有方案能很好地解决这两个问题?有,那就是我们接下来要介绍的 React Native。

React Native

React Native是由FaceBook开源的基于JavaScript和React搭建的一套跨平台开发框架。而在设计之初,React Native采用就是在不同平台下使用平台自带的UI组件。以为它采用JavaScript和React来开发,所以获得了不少前端程序猿的青睐。
有人说,React Native采用js等前端技术是回归H5,但其实 React Native和Web 扯不上太多关系。ReactNative虽然借鉴了CSS中的Flexbox、navigator、XMLHttpRequest 等Api的写法,但是大部分还是通过原生的组件或者自己封装的组件来开发的。就像FaceBooK的内部软件Facebook Groups,iOS版本很大一部分基于React Native开发,其中用到了不少内部通用组件。
React Native相比传统Objective-C和UIView,学习成本更低了,熟悉JavaScript 的开发者可以在半天写个使用标准UI界面,而且用XML+CSS 画界面也远比 UIView 中用 Frame 进行手工布局更易读。在加上React Native师出名门,截止目前,React Native已更新到0.4.2版本,并且逐步趋于稳定。由于其更加接近原生的体验,国内一些大厂纷纷加入,诸如阿里、腾讯、美团等纷纷开始自己app想React Native的改造。

React Native代码:

  @implementation ArticleComponent
+ (instancetype)newWithArticle:(ArticleModel *)article
 {
 return [super newWithComponent:
 [CKStackLayoutComponent
 newWithView:{}
 size:{}
 style:{
 .direction = CKStackLayoutDirectionVertical,
 }
 children:{
 {[HeaderComponent newWithArticle:article]},
 {[MessageComponent newWithMessage:article.message]},
 {[FooterComponent newWithFooter:article.footer]},
 }];
 }
 ...

很多人觉得跨平台从来都不靠谱,但其实是有的,那就是 Web,这个历史上最成功的例子,就像当年web挤掉pc成为互联网的主流一样,未来的互联网必将是web的时代。

作者:xiangzhihong8 发表于2017/3/29 17:41:11 原文链接
阅读:255 评论:0 查看评论

相关 [移动 跨平台 技术] 推荐:

移动端跨平台技术总结

- - CSDN博客推荐文章
曾经大家以为在手机上可以像桌面那样通过 Web 技术来实现跨平台开发,却因为性能或其他问题而放弃,不得不针对不同平台开发多个版本. 而React Native让跨平台移动端开发在次回到人们的视野中,其成功的原因除了他“一次编写处处运行”,还因为它相比h5等前端技术,有了更接近原生的体验. 为了方便理解,笔者将跨平台技术分为4大流派:.

聊聊移动端跨平台开发的各种技术

- - FEX 百度 Web 前端研发部
最近出现的 React Native 再次让跨平台移动端开发这个话题火起来了,曾经大家以为在手机上可以像桌面那样通过 Web 技术来实现跨平台开发,却大多因为性能或功能问题而放弃,不得不针对不同平台开发多个版本. 但这并没有阻止人们对跨平台开发技术的探索,毕竟谁不想降低开发成本,一次编写就处处运行呢.

移动跨平台技术方案总结 - xiangzhihong8的专栏 - CSDN博客

- -
“得移动端者得天下”,移动端取代PC端,成为了互联网行业最大的流量分发入口,因此不少公司制定了“移动优先”的发展策略. 为了帮助读者更好地学习WEEX,本节将对React Native、Weex和Flutter等主流的跨平台方案进行简单的介绍和对比. React Native (简称RN)是Facebook于2015年4月开源的跨平台移动应用开发框架,是Facebook早先开源的React框架在原生移动应用平台的衍生产物,目前主要支持iOS和安卓两大平台.

跨平台开发技术年终盘点

- - SegmentFault 最新的文章
一直以来,效率都是互联网企业的生命线. 而 “通过技术升级实现三个人干五个人的活,赚四个人的工资”是企业和个人一直渴望达到的双赢局面. 随着行业竞争加剧,为进一步提升开发效率,跨平台开发逐渐的成为了互联网行业的刚需. 这样的大趋势下,一些头部互联网公司基于自身技术背景和当时技术条件,推出了不同类型的跨平台解决方案.

Moscrif:用JavaScript进行跨平台移动开发

- - InfoQ cn
Moscrif是构建在定制虚拟机上的跨平台移动开发环境. 尽管该平台提供了访问原生设备的功能,但编程语言却是JavaScript的一个定制版本. 据公司联合创始人Michal Habalcik所说,Moscrif已支持iOS、Android、Symbian、Windows Mobile和Bada等平台,而且还将在微软发布API之后,添加对Windows Phone 8的支持.

文章: Calatrava:自由构建UI的跨平台移动框架

- - InfoQ cn
移动是未来计算的趋势,越来越多的人使用移动设备来访问互联网. 但是目前至少三大平台:iOS、Android、移动Web. 相比桌面Web,移动用户需要更好的体验、界面和设计. 然而移动设备受限于电池、不可靠的网络连接和小尺寸屏幕. 创业者之翼为创业新星免费提供甲级办公场所,详情请点击. 2012RIA天地行•西南游戏开发者大会11月25日,火热报名中.

跨平台移动框架iMAG开发入门

- - IT技术博客大学习
iMAG是一个非常简洁高效的移动跨平台开发框架,开发一次可以同时兼容Android和iOS平台,有点儿Web开发基础就能很快上手. 当前移动端跨平台开发的框架有很多,但用iMAG还有一个好处,就是用iMAG开发出的App是原生的. iMAG采用XML + JavaScript(配置 + 脚本)的开发方式,它的原理是将符合iMAG开发规范的XML文件解释成对应的原生应用代码来执行.

移动端跨平台开发的深度解析

- - IT瘾-dev
  跨平台一直是老生常谈的话题,cordova、ionic、react-native、weex、kotlin-native、flutter等跨平台框架的百花齐放,颇有一股推倒原生开发者的势头. (事实上更多是共存发展)看完本篇,相信你会对于当下跨平台移动开发的现状、实现原理、框架的选择等有更深入的理解.

移动跨平台框架Flutter介绍和学习线路

- - SegmentFault 最新的文章
Flutter是一款移动应用程序SDK,一份代码可以同时生成iOS和Android两个高性能、高保真的应用程序. Flutter目标是使开发人员能够交付在不同平台上都感觉自然流畅的高性能应用程序. 我们兼容滚动行为、排版、图标等方面的差异. 在全世界,Flutter正在被越来越多的开发者和组织使用,并且Flutter是完全免费、开源的.

从Flutter聊聊跨平台移动研发方案

- - 掘金 架构
Flutter 是一款由 Google 开发的开源、跨平台移动端开发框架. Flutter 使用 Dart 作为开发语言,这是一门简洁、强类型的编程语言. 它允许使用同一个代码库构建高性能、漂亮的 iOS 和 Android 应用,Flutter还提供了两套视觉库,可以针对不同的平台有不同的展示效果.