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编写原生扩展需要：

• 为扩展编写JavaScript接口，它将使用PhoneGap的API，将发送到原生代码的消息排成队列。

• 以某种方式将你的扩展登记到原生项目——在iOS上，这一步在Cordova.plist文件中完成。

• 编写原生代码，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基于移动开发方面的两个现实：

• 有一套核心的移动开发API，它们可以跨平台进行规范。这些方面的重点应放在代码重用上。

• 有针对特定平台的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)用户界面，比如Facebook的原生应用程序。这样一来，开发者实际上可以实现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://developer.appcelerator.com/blog/2012/05/comparing-titanium-and-phonegap.html

• http://savagelook.com/blog/portfolio/a-deeper-look-at-appcelerator-and-phonegap

• http://savagelook.com/blog/portfolio/phonegap-is-web-based-appcelerator-is-pure-javascript

建议继续学习：

1. 基于 PhoneGap 与 Java 开发的 Android 应用的性能对比    (阅读：4978)
2. Phonegap + HTML5 开发经验小结    (阅读：4111)
3. 一个简单的基于PhoneGap的开源微博客户端    (阅读：3866)
4. PhoneGap应用开发的那些坑爹事儿    (阅读：3357)
5. PhoneGap开发不可或缺的五件装备    (阅读：2450)
6. 初识PhoneGap    (阅读：1926)