移动应用开发工具:PhoneGap与Titanium的比较

jopen 9年前

PhoneGap和Titanium都提供了跨平台移动开发工具。两者还在一定程度上都需要使用JavaScript和Web技术。虽然这两项技术的目的都是能够实现跨平台的移动开发,但是解决这个问题的一套理念和方法却没有多少共同之处。

一、PhoneGap是如何工作的

PhoneGap的目的是让基于HTML的Web应用程序可以作为原生应用程序来部署和安装。由原生应用程序外壳来加以包装,通过面向多个平台的原生应用程序商店来发布。此外,PhoneGap力求提供Web应用程序通常无法使用的常用的原生API,比如之前在浏览器中还没有提供的功能:摄像头访问、联系人访问和传感器。

开发PhoneGap应用程序,只在本地目录中创建HTML、CSS和JavaScript文件,其方式酷似开发静态网站。想要将写好的程序编译成各个软件包,只要使用PhoneGap Build的服务即可,该服务可以在云端创建易于安装的应用程序。

PhoneGap应用程序是一种“原生包装”的Web应用程序。许多原生移动开发SDK提供了Web浏览器窗口组件,作为用户界面框架的一部分。在纯原生应用程序中,Web视图控件用来显示来自远程服务器的HTML内容,或者显示以某种方式与原生应用程序一起封装的本地HTML内容。由 PhoneGap创建的原生“包装器”把前后端开发者的HTML页面装入到这其中一个Web视图控件,并且在应用程序启动后,将随后出现的HTML作为用户界面来显示。

如果JavaScript文件包括在Web视图装入的页面中,该代码就在页面上以正常方式来运行。不过,创建Web视图的原生应用程序能够以不同的方式与Web视图里面运行的JavaScript代码进行异步通信。这项技术在PhoneGap架构中通常被称为“桥接”技术。PhoneGap利用该技术在Web视图里面创建JavaScript API,以异步方式将消息发送到包装器应用程序中的原生代码,以及接收来自包装器应用程序中原生代码的消息。每个平台实现桥接层的方式各有不同;在iOS 平台上,当你需要联系人列表时,原生方法调用就会进入到通过桥接发送的请求队列。随后PhoneGap会创建iframe,iframe会装入统一资源标识符方案(“gap://”),原生应用程序经配置后处理该统一资源标识符方案;这时候所有的队列命令将被执行。通过在Web视图的环境下执行 JavaScript,就能回过头来从原生代码联系到Web视图。PhoneGap的工作方式绝不止这些,但是通过实现桥接技术完成从Web视图到原生代码的消息传递却是这项技术的核心部分,这让本地Web应用程序得以调用原生代码。

为PhoneGap编写原生扩展需要:

  1. 为扩展编写JavaScript接口,它将使用PhoneGap的API,将发送到原生代码的消息排成队列。
  2. 以某种方式将你的扩展登记到原生项目——在iOS上,这一步在Cordova.plist文件中完成。
  3. 编写原生代码,PhoneGap将从Web视图发送请求至原生代码,并实现所需的任何原生代码。

大致上来说,开发者可以参与到驱动核心PhoneGap原生API的同一个异步消息传递系统。

PhoneGap架构方面的主要优点是,它非常小巧、简单。它只做自己擅长的工作。PhoneGap团队有意为基于Web浏览器的应用程序只实现最基本的原生API。由于原生API集非常小,因而把PhoneGap移植到许多不同的环境来得比较容易。基本上来说,支持Web视图或Web运行时环境的任何原生平台都可以是一种PhoneGap平台。PhoneGap中的非可视原生扩展也非常简单。说到登记原生代码、接收来自Web视图的消息,这方面的要求也非常低。因而可以迅速开发出简单的原生扩展。这种插入式架构还得到了很好地落实。另外,原生API和原生应用程序开发对前后端开发者来说几乎完全是抽象的。凡是能编写HTML、CSS、甚至一小段JavaScript代码的人都能用原生应用程序来包装网页,并将其作为原生应用程序来分发。使用 PhoneGap把网页包装成原生应用程序方面的准入门槛极低。

PhoneGap应用程序中用户界面的质量会不一样,取决于Web视图和平台上渲染引擎的质量。iOS平台上基于Webkit的渲染引擎很强大,并且提供了最佳性能。Android Web视图可以用,但是存在一些明显的局限性。在其他平台上,Web视图的性能可能成问题,这要看操作系统的版本。还有Web开发者始终不得不处理的常见的跨浏览器问题。现在许多移动都平台采用Webkit,但是即便在基于Webkit的环境中,仍存在很大的差异。

PhoneGap无法用原生用户界面来加以扩展。前后端开发者的应用程序本身驻留在Web视图里面,用户界面由HTML加以渲染。你可以把消息传递到原生代码,并创建在Web视图之上或邻近Web视图的原生用户界面,但是很难或不可能把动态的、基于文档对象模型(DOM)的HTML用户界面与原生用户界面组件集成起来。

二、             Titanium是如何工作的

Titanium Mobile的目的是为移动开发提供一种高级的、跨平台的JavaScript运行时环境和API。Titanium与 MacRuby/Hot Cocoa、PHP或node.js的共同之处实际上多于它与PhoneGap、Adobe AIR、Corona或 Rhomobile的共同之处。Titanium基于移动开发方面的两个现实:

  1. 有一套核心的移动开发API,它们可以跨平台进行规范。这些方面的重点应放在代码重用上。
  2. 有针对特定平台的API、用户界面公约以及功能特性,开发者在针对该特定平台从事开发时应该采用。应该有针对特定平台的代码,以便这些用例提供最佳的用户体验。

由于这些原因,Titanium并不是想“编写一次、到处运行”。开发者应该使用面向多个平台的优秀的、用户体验增强特性。必要时,原生应用程序应充分利用熟悉的、高性能的原生用户界面窗口组件。原生应用程序开发者没必要为了绘制长方形或发起HTTP请求而要学会针对特定平台的API。 Titanium试图借助统一的JavaScript API、针对特定平台的功能特性以及原生性能,实现代码重用,从而满足用户的预期要求。在编写 Titanium应用程序时,其实是用JavaScript来编写原生应用程序。Titanium应该被视作是一种用来编写原生应用程序的框架,而不是针对的实际平台予以抽象化。

想用Titanium来开发原生应用程序,开发者就需要安装面向iOS和Android的原生工具链。不过,这些工具安装完毕后,开发者通常只能与 Titanium SDK的脚本接口进行交互。这一步可以直接通过命令行来完成,也可以通过基于Eclipse的集成开发环境(IDE):Titanium Studio来完成。

使用Titanium工具集,可以创建含有配置文件和本地化文件的应用程序项目目录,以及含有图像、资源和为了运行应用程序而编写的 JavaScript源代码的目录。在默认情况下,你不用编辑HTML和CSS文件,除非你想创建同时含有原生用户界面和基于HTML的用户界面的混合型应用程序。Titanium应用程序可以、而且常常的确采用“混合型”(原生和Web)用户界面,比如非死book的原生应用程序。这样一来,开发者实际上可以实现PhoneGap和Titanium。借助该工具链,应用程序使用面向目标平台的实际仿真器/模拟器来运行。在Studio中,提供了一个向导界面,以配置任何代码签名依赖关系,然后处理将应用程序部署到连接设备上的任务。另外可以使用原生工具链来部署或包装应用程序。

开发Titanium应用程序时,底层的工具链大多数是抽象的。它们是开发所必不可少的,但是很少要求前后端开发者直接使用它们。不过,开发原生应用程序这并不抽象。用户界面是用跨平台组件和针对特定平台的组件共同开发而成的,应用程序应该处理:后台服务、本地通知、应用程序标记、配置、活动/目的……所有这些都通过Titanium JavaScript API来提供。Titanium应用程序后台发生的事情相当复杂。但大致上来说,在运行时,你的应用程序包括三个主要组件:JavaScript源代码;用原生编程语言针对特定平台实现的Titanium API;以及用来在运行时执行JavaScript的解释器。

应用程序启动后,JavaScript执行环境由原生代码来创建,应用程序源代码进行执行。被插入到应用程序JavaScript运行时环境的 “代理”对象——在原生代码中有配对对象的JavaScript对象。俗称为Titanium应用程序中的“JavaScript地带” (JavaScript land)和“原生地带”(native land),因为它们在某种程度上彼此并行。代理对象在JavaScript地带和原生地带中同时存在,充当两者之间的“桥梁”。在JavaScript代码中,当针对全局Titanium或Ti对象调用函数时,比如 var b = Ti.UI.createButton({title:’Poke Me’});,这将调用一种会创建原生用户界面对象的原生方法,并创建一个“代理”对象(b),向JavaScript提供关于底层原生用户界面对象的属性和方法。用户界面组件(视图代理)可以在层次体系上加以安排,以创建复杂的用户界面。为非可视API(比如文件系统输入/输出或数据库访问)呈现界面的代理对象用原生代码软来执行,并以同步方式将结果返回给 JavaScript;如果是网络访问等API,则以异步方式返回结果。

由于Titanium的目的是为跨平台的原生移动开发提供一种更高级的API,所以你可以直接访问一系列广泛的原生特性和功能,从用户界面组件、插座接口到通知系统集成。Titanium的目的是,将Titanium应用程序和纯原生应用程序之间在功能方面的差异缩小到几乎为零。我们可能从来不直接支持整个平台的API,但是我们希望能涵盖90%最常见的用例,并且提供一个平台,以便有需要的人可以添加剩余10%的用例。由于Titanium通过 JavaScript提供了一种高级的原生编程API,为用过基于ECMA Script的语言的任何人大大降低了原生编程方面的准入门槛。、

Titanium API的范围使得添加新平台有难度——在一种新的原生平台上实现Titanium API是项艰巨任务。正由于如此,Titanium平台只出现在目前被认为最重要的移动平台上:iOS、Android和Web。

三、PhoneGap与Titanium的差异

至此,PhoneGap和Titanium技术方面的差异已很明了。但是除了那些差异外,每个项目的目的和方向也不同。PhoneGap的既定目标是最终不复存在。从理论上来说,一旦浏览器厂商实现了PhoneGap的特性,这个平台将没有必要。PhoneGap的赞助公司Adobe对于Web作为一种平台有着非常浓厚的兴趣。Adobe是一家主攻工具的公司。平台其实是Adobe可用来销售工具的一个渠道。这个平台一度是Flash。而现在,除了 Flash外,这个平台主要还是Web浏览器。从许多方面来看,PhoneGap在Adobe的产品路线图中到底扮演与Flash相似的角色。 PhoneGap试图建立一种抽象的运行时环境,能够实现跨平台部署。

Titanium也对Web作为一种平台日臻完善抱有兴趣,并给予了支持。区别在于,Titanium并未指望Web成为唯一的移动应用程序平台。 iOS、Android、黑莓和WindowsPhone之类的平台继续颇具影响力,为用户们提供出色的体验。这种选择和竞争对消费者来说将是件好事,但是对开发者来说仍是个问题。Titanium为开发者提供的是这样一种方式:借助单一代码库,同时涵盖Web平台和原生平台,同时保留该平台的用户所期望的特性、性能以及紧密的平台集成。

最后,如果想快速开发一个iOS or/and Android原生UI的程序,选择Titanium或许更适合,如果想实现一个跨平台的基于HTML的移动应用,PhoneGap或许更适合。

参考信息:

引用地址:http://www.biaodianfu.com/phonegap-vs-titanium.html