首页 > 语言 > 关键词   >  移动开发技术最新资讯  > 正文

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

2015-05-12 10:22 · 稿源: 百度Fex

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 在功能上还有很大差距

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

而对于 Android 的支持,微软应该使用了虚拟机的方式,所以放到下个章节介绍。

RoboVM

RoboVM 可以将 Java 字节码编译为可在 iOS 下运行的机器码,这有点类似 GCJ,但它的具体实现是先使用 Soot 将字节码编译为 LLVM IR,然后通过 LLVM 的编译器编译成不同平台下的二进制文件。

比如简单的 new UITextField(new CGRect(44, 32, 232, 31)) 最后会变如下的机器码(x86):

call imp___jump_table__[j]org.robovm.apple.uikit.UITextField[allocator][clinit]mov esi, eaxmov dword [ss:esp], ebxcall imp___jump_table__[j]org.robovm.apple.coregraphics.CGRect[allocator][clinit]mov edi, eaxmov dword [ss:esp+0x4], edimov dword [ss:esp], ebxmov dword [ss:esp+0xc], 0x40460000...

基于字节码编译的好处是可以支持各种在 JVM 上构建的语言,比如 Scala、Kotlin、Clojure 等。

在运行环境上,它使用的 GC 和 GCJ 一样,都是 Boehm GC,这是一个保守 GC,会有内存泄露问题,尽管官方说已经优化过了影响不大。

在 UI 的支持方面,它和 Xamarin 挺像,可以直接用 Java 调用系统接口来创建界面(最近支持 Interface Builder 了),比如上面的示例就是。另外还号称能使用 JavaFX,这样就能在 iOS 和 Android 上使用同一套 UI 了,不过目前看起来很不靠谱。

在我看来 RoboVM 目前比较大的用途就是使用 libGDX 开发游戏了,尽管在功能上远不如 Cocos2d-x(尤其是场景及对象管理),但不管怎么说用 Java 比 C++ 还是方便很多(别跟我说没人用 Java 做游戏,价值 25 亿美元的 Minecraft 就是),不过本文主要关心的是 UI 开发,所以这方面的话题就不深入讨论了,

RoboVM 和 Xamarin 很像,但 RoboVM 风险会小些,因为它只需要把 iOS 支持好就行了,对优先开发 Android 版本的团队挺适用,但目前官方文档太少了,而且不清楚 RoboVM 在 iOS 上的性能和稳定性怎样。

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,太非主流了,所以实在懒得研究它。

使用 Swift 编译为 SO 给 Android 用虽然可行,但目前相关工具都不太成熟,所以不推荐使用。

Go

Go 是最近几年很火的后端服务开发语言,它语法简单且高性能,目前在国内有不少用户。

Go 从 1.4 版本开始支持开发 Android 应用(并将在 1.5 版本支持 iOS),不过前只能调用很少 的 API,比如 OpenGL 等,所以只能用来开发游戏,但我感觉并不靠谱,现在还有谁直接基于 OpenGL 开发游戏?大部分游戏都是基于某个框架的,而 Go 在这方面太缺乏了,我只看到一个桌面端 Azul3D,而且非常不成熟。

因为 Android 的 View 层完全是基于 Java 写的,要想用 Go 来写 UI 不可避免要调用 Java 代码,而这方面 Go 还没有简便的方式,目前 Go 调用外部代码只能使用 cgo,通过 cgo 再调用 jni,这需要写很多中间代码,所以目前 Go 1.4 采用的是类似 RPC 通讯的方式来做,从它源码中例子可以看出这种方式有多麻烦,性能肯定有不小的损失。

而且 cgo 的实现本身就对性能有损失,除了各种无关函数的调用,它还会锁定一个 Go 的系统线程,这会影响其它 gorountine 的运行,如果同时运行太多外部调用,甚至会导致所有 gorountine 等待。

这个问题的根源在于 Go 的栈是可以自动扩充的,这种方式有利于创建无数 gorountine,但却也导致了无法直接调用 C 编译后的函数,需要进行栈切换。

所以使用 Go 开发跨平台移动端应用目前不靠谱。

话说 Rust 没有 Go 的性能,它调用 C 函数是没有性能损耗的,但目前 Rust 还没提供对 iOS/Android 的官方支持,尽管有人还是尝试过是可行的,但现在还不稳定,从 Rust 语言本身的设计来看,它挺适合取代 C++ 来做这种跨平台公共代码,但它的缺点是语法复杂,会吓跑很多开发者。

Xojo

我之前一直以为 BASIC 挂了,没想到还有这么一个特例,Xojo 使用的就是 BASIC,它有看起来很强大的 IDE,让人感觉像是在用 VisualBasic。

它的定位应该是给小朋友或业余开发者用的,因为似乎看起来学习成本低,但我不这么认为,因为用得人少,反而网上资料会很少,所以恐怕成本会更高。

因为时间关系,以及对 BASIC 无爱,我并没有怎么研究它。

小结

从目前分析的情况看,C++ 是比较稳妥的选择,但它对团队成员有要求,如果大家都没写过 C++,可以试试 Xamrin 或 RoboVM。

虚拟机流

除了编译为不同平台下的二进制文件,还有另一种常见做法是通过虚拟机来支持跨平台运行,比如 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 */}app/views/index.xml        

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

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

  1. API 有限,因为这是由 Titanium 提供的,它肯定会比官方 API 少且有延迟,Titanium 是肯定跟不过来的
  2. 相关资料及社区有限,比起 Android/iOS 差远了,遇到问题都不知道去哪找答案
  3. 缺乏第三方库,第三方库肯定不会专门为 Titanium 提供一个版本,所以不管用什么都得自己封装

Titanium 也意识到了这个问题,所以目前在开发下一代的解决方案 Hyperloop,它可以将 JavaScript 编译为原生代码,这样的好处是调用原生 API 会比较方便,比如它的 iOS 是这样写的

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

这个方案和之前的说的 Xamarin 很相似,基本上等于将 Objective-C 翻译为 JavaScript 后的样子,意味着你可以对着 Apple 的官方文档开发,不过如果发现某些 Objective-C 语法发现不知道对应的 JavaScript 怎么写时就悲剧了,只有自己摸索。

但从 Github 上的提交历史看,这项目都快开发两年了,但至今仍然是试验阶段,从更新频率来看,最近一年只提交了 8 次,所以恐怕是要弃坑了,非常不靠谱。

因此我认为 Titanium/Hyperloop 都非常不靠谱,不推荐使用。

NativeScript

之前说到 Titanium 自定义 API 带来的各种问题,于是就有人换了个思路,比如前段时间推出的 NativeScript,它的方法说白了就是用工具来自动生成 wrapper API,和系统 API 保持一致。

有了这个自动生成 wrapper 的工具,它就能方便基于系统 API 来开发跨平台组件,以简单的 Button 为例,源码在 cross-platform-modules/ui/button 中,它在 Android 下是这样实现的(TypeScript 省略了很多代码)

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。

举报

  • 相关推荐
  • 大家在看
  • 浙江文交所与鲸探携手“科技+文化” 实现文化数字资产跨平台“秒转”流通

    7月7日,浙江文交所与蚂蚁集团旗下鲸探科技达成合作,推出数字资产跨系统"秒转"功能,实现数字藏品在数文链和蚂蚁链间的便捷互转。首批支持《愤怒小鱼篓》等5款藏品跨平台流通,并同步发行文旅数字藏品《东坡行旅·石刻踪迹》1.2万份。此次合作创新"瞬时交割"交易模式,推动数字资产跨平台智能流通,促进文化数字资产市场繁荣发展。未来双方将深化合

  • 融合数据中台与动态调度:林剑峰在共享出行智能算法开发中的技术探索

    本文讲述了林剑峰在智能出行领域的十年深耕历程。作为系统工程师,他主导构建了融合数据、算法与规则引擎的智能调度体系,通过动态聚类和路径规划模型显著提升了共享单车调度效率。其创新包括分级围栏模型、嵌入式调度判断模块等专利技术,实现了跨区域精准调度和系统自主运行能力。数据显示,他推动的系统使车辆调度效率提升37.38%,异常识别准确率显著提高。林剑峰的工作体现了"技术+业务"的系统设计理念,为城市智能交通建设提供了可借鉴的技术范式。

  • 企业如何低成本搭建可快速响应的远程技术支持平台?

    文章探讨了极端天气下企业技术支持的转型需求,重点介绍了远程技术支持的解决方案。传统线下服务面临出行困难、安全隐患等问题,而远程技术支持能实现设备监测、故障排查等操作,保障人员安全。贝锐向日葵推出的远程控制方案具有高效稳定、快速响应等特点,支持文件传输、工单流转等功能,并与ITSM平台深度整合,形成闭环服务体系。方案还提供团队版共享机制,适合初创团队低成本使用。在极端天气频发的当下,远程方案能显著提升企业抗灾能力,实现降本增效。

  • 玄武云出席崔牛会AI活动,聊聊AI大模型如何掌握终端信息

    6月20日,崔牛会主办的AI发现者计划之AI+OPEN DAY在广州举办,玄武云与百度云等企业围绕AI大模型应用展开探讨。玄武云分享了快消行业数字化转型解决方案,推出SKU超级模型和价签识别模型,帮助品牌商提升终端管理效率。其中SKU模型覆盖6000+商品,识别准确率达90%;价签模型准确率85%,已应用于知名薯片品牌。通过AI技术实现商品陈列优化、价格监控和渠道布局分析,助力快消企业从经验驱动转向数据智能驱动,在存量市场中创造增量价值。

  • 推荐几个国内比较主流的API管理平台

    本文介绍了国内主流的API管理平台,包括Apifox、RestCloud iPaaS、YApi、API Umbrella、Postcat、白山云和数环通。这些平台各具特色:Apifox集文档、调试、Mock和测试于一体;RestCloud iPaaS支持AI助手和300+ SaaS应用连接;YApi适合跨语言开发团队;API Umbrella提供多团队协同和实时监控;Postcat轻量可扩展;白山云专注企业级全流程管理;数环通主打智能化自动化。企业应根据自身规模、行业需�

  • 最新AI模型哪里看?查找最佳AI模型平台推荐

    文章介绍了AI领域快速迭代背景下,开发者如何高效追踪最新模型动态。主要渠道包括:1)官方渠道(GitHub、公司官网/博客);2)科技媒体和社区(Twitter、Reddit等);3)专业聚合平台(推荐AIbase模型广场)。重点推荐AIbase平台,其优势在于:实时更新全球最新模型、结构化展示关键信息、支持多维筛选排序、直达相关资源链接。建议开发者善用官方渠道获取源头信息,同时�

  • AI日报:阿里通义推Qwen-TTS模型;Cursor已支持网页和手机端;字节发布图像合成技术XVerse

    【AI日报】今日AI领域7大突破:1)阿里通义Qwen-TTS实现方言语音合成重大突破;2)Cursor发布Web版AI编程工具;3)字节XVerse技术实现多对象精准图像生成;4)NoteGen跨平台AI笔记工具革新知识管理;5)ManimML动画库可视化Transformer架构;6)TEN+Agent开源语音交互技术降低延迟;7)Chai-2抗体设计模型将药物研发周期缩短至两周。淘宝同时上线RecGPT推荐模型提升购物体验。

  • 外卖大战有骑手称要跑通宵:平台补贴很高

    新一轮的外卖补贴大战”在本周末重燃战火,社交媒体上充斥着低价甚至免单的咖啡奶茶订单,淘宝闪购和美团外卖两大话题再度冲上热搜榜。 据网友反馈,美团在这个周末送出了多个线下咖啡茶饮的通兑券,但需要自取,淘宝闪购则依旧发放188元的红包,包括满38减18.8的午餐外卖红包,不过免单卡”仍需要消费者随机抽取获得。

  • GCDG丨江阴站:AI赋能,开发者技术沙龙圆满举办!

    2025年6月8日,葡萄城开发者社区在江苏举办"AI赋能·开发者技术交流会"。活动汇聚多地开发者,共同探讨AI+低代码创新实践。开发者谷凯展示如何利用GPT-4等AI工具提升开发效率,强调独立开发者"一人也能创造价值"的理念。钟代冬分享家纺电商低代码工程案例,展示活字格平台实现复杂任务自动化运维的能力。技术顾问薛禹坤介绍"All-in-One一站式智能体开发"理念,演示活字格V11.0新版本AI功能。活动促进跨地域、跨领域思维碰撞,为开发者搭建紧密连接平台,推动前沿技术交流与实践经验分享。

  • 用领先技术破局,TCL电视以技术普惠战略树立行业标杆

    2025年第一季度,TCL电视全球出货量达651万台,同比增长11.4%,其中Mini LED电视出货量激增194.5%,市占率28.8%跃居全球第一。在国内市场,TCL电视618大促期间成交额登顶多平台榜首。文章指出,消费者需求正从"唯价格论"转向"唯价值论",75英寸以上大尺寸电视出货量同比增长45.4%。TCL T6L Pro新品通过"蝶翼星曜屏"实现7000:1超高对比度,配合"万象分区"技术提升控光效果,搭载1300nits绚彩XDR和量子点Pro2025技术,支持96% DCI-P3色域。灵控系统3.0实现0.7秒极速开机,支持NAS协议播放。这些创新技术使TCL在疲软市场中实现逆势增长,体现了"技术普惠"理念。

这篇文章对你有价值吗?

今日大家都在搜的词: