【51CTO譯文】PhoneGap和Appcelerator Titanium，對于封裝和配置移動應用程序而言，二者都是非常受歡迎的開源JavaScript框架。本文為Appcelerator開發者Kevin Whinnery對PhoneGap和Appcelerator Titanium進行的全方位的比較。

以下為全部譯文：

我在面向開發者的各項活動和大會上經常被問及一個問題：Titanium與PhoneGap相比到底怎樣。我想，看來有必要抽點時間，從宏觀層面解釋每一項技術是如何工作的，并且評估這兩項技術彼此相比怎樣。

從宏觀層面來看，PhoneGap和Titanium似乎很相似。它們都提供了跨平臺移動開發工具。兩者還在一定程度上都需要使用JavaScript和Web技術。Titanium和PhoneGap都是采用寬松許可證的開源軟件（Titanium Mobile SDK是采用Apache 2.0許可證發布的；PhoneGap采用了類似的許可方式，PhoneGap又被稱為是Apache軟件基金會管理的項目“Cordova”的一個“發行版”）。

但是兩者的相似之處其實僅限于此。雖然這兩項技術的目的都是能夠實現跨平臺的移動開發，但是解決這個問題的一套理念和方法卻沒有多少共同之處。此外，從贊助公司的角度來看——PhoneGap的贊助公司是Adobe，Titanium的贊助公司是Appcelerator，每個項目背后的商業目的大不一樣。我將從自己的視角，在下文盡量詳細地描述技術、理念和商業模式方面的這些差異。

另外，要是你之前還沒有了解，我要聲明一下：本人長期以來是Appcelerator的代碼捐獻者和雇員。話雖如此，我還是盡量立足于客觀的技術事實，從技術和理論層面對這兩項技術作一番評述。如果你覺得我闡述的觀點哪里與事實不符或者誤人子弟，請留言告訴我，我會酌情更新這篇博文。

我會先從宏觀層面描述這兩項技術是如何工作的，還會描述這兩項技術如何用額外的原生功能來擴展。就每項技術而言，我還會總結它們所選擇的跨平臺開發方法存在的主要優缺點。技術上的差異很快就會一目了然，但是我做了這些概述和比較后，還會描述這兩個平臺在理念上和戰略上有什么差異、它們將何去何從。

不妨先來介紹一下PhoneGap及其是如何工作的。#p#

PhoneGap想實現什么樣的目的？

PhoneGap的目的是，讓基于HTML的Web應用程序可以作為原生應用程序來部署和安裝。PhoneGap Web應用程序由原生應用程序外殼來加以包裝，可以通過面向多個平臺的原生應用程序商店來加以安裝。此外，PhoneGap力求提供Web應用程序通常無法使用的常用的原生API（應用編程接口）集，比如之前在瀏覽器中還沒有提供的基本攝像頭訪問、設備中的聯系人資料和傳感器。

從更宏觀的層面來看，PhoneGap可以看作是新興的萬維網聯盟（W3C）設備API標準的開路先鋒，因為它們試圖現在就讓Web開發者感受和領略未來。如今，沒有哪個平臺將Web應用程序視作一等公民，不過Mozilla大有希望的Boot To Gecko平臺有機會改變這種情況。在優先通過API訪問Web應用程序方面，微軟的Windows 8也正在取得進展，值得關注。但是PhoneGap的目的是，現在就為Web應用程序獲得一小部分的此類權利。

PhoneGap的最終用戶工作流、工具和接口

想開發PhoneGap應用程序，開發者就要在本地目錄中創建HTML、CSS和JavaScript文件，其方式酷似開發靜態網站。實際上，一些PhoneGap開發者提到了這款工具的額外好處：自己大多數時候可以在桌面Web瀏覽器中進行開發，根本不需要原生工具鏈（toolchain）。

想在原生仿真器/模擬器上運行PhoneGap應用程序，開發者就得為自己想要支持的每一個原生平臺創建一個項目，并且使用Xcode、Eclipse或所需的任何原生工具鏈，配置該項目的“web root”目錄，然后使用該工具來運行項目。具體步驟在每個平臺各自的入門指南中均有概述。符號鏈接常常用來跨多個原生項目，把“www”文件夾傳送到一個共同的目錄位置。

把原生包裝的PhoneGap應用程序安裝到設備上需要相似的工作流。不過，為了補充這個過程，并且緩解本地安裝原生軟件開發工具包（SDK）的需要，最近被Adobe收購的Nitobi建立了一項名為PhoneGap Build的服務，該服務可以在云端創建易于安裝的應用程序。支持PhoneGap編譯部署的功能最近已集成到了Adobe的Dreamweaver工具中。

與PhoneGap結合使用的工具是標準的Web開發工具，比如Firebug、Web Inspector和你所選擇的文本編輯器。還出現了一種用于遠程調試的新興工具，名為Weinre；這款工具如今得到了更廣泛的應用。總的來說，你開發原生應用程序這個事實在開發過程中基本上是抽象的。#p#

PhoneGap是如何工作的？

正如我們之前提到的那樣，PhoneGap應用程序是一種“原生包裝”的Web應用程序。不妨探討一下Web應用程序是如何加以“包裝”的。

許多原生移動開發SDK提供了Web瀏覽器窗口組件（“Web視圖”），作為用戶界面框架（比如iOS和Android）的一部分。在純原生應用程序中，Web視圖控件用來顯示來自遠程服務器的HTML內容，或者顯示以某種方式與原生應用程序一起封裝的本地HTML內容。由PhoneGap創建的原生“包裝器”（wrapper）應用程序把前后端開發者的HTML頁面裝入到這其中一個Web視圖控件，并且在應用程序啟動后，將隨后出現的HTML作為用戶界面來顯示。

如果JavaScript文件包括在Web視圖裝入的頁面中，該代碼就在頁面上以正常方式來評估。不過，創建Web視圖的原生應用程序能夠以不同的方式（取決于具體平臺），與Web視圖里面運行的JavaScript代碼進行異步通信。這項技術在PhoneGap架構中通常被稱為“橋接”（bridge）技術——在Titanium中，“橋接”又有著稍有不同的含義，本文后面會有介紹。

PhoneGap充分利用該技術在Web視圖里面創建JavaScriptAPI，能夠以異步方式將消息發送到包裝器應用程序中的原生代碼，以及接收來自包裝器應用程序中原生代碼的消息。每個平臺實現橋接層的方式各有不同；但在iOS平臺上，當你需要聯系人列表時，你的原生方法調用就會進入到通過橋接發送的請求隊列。隨后，PhoneGap會創建iframe，iframe會裝入統一資源標識符方案（“gap://”），原生應用程序經配置后處理該統一資源標識符方案；這時候所有的隊列命令將被執行。通過在Web視圖的環境下評估JavaScript串，就能回過頭來從原生代碼聯系到Web視圖。

PhoneGap的工作方式絕不止這些，但是通過實現橋接技術完成從Web視圖到原生代碼的消息傳遞卻是這項技術的核心部分，這讓本地Web應用程序得以調用原生代碼。

擴展PhoneGap

為PhoneGap編寫原生擴展需要你：

1. 為擴展編寫JavaScript接口，它將使用PhoneGap的API，將發送到原生代碼的消息排成隊列。 
2. 以某種方式將你的擴展登記到原生項目——在iOS上，這一步在Cordova.plist文件中完成。
3. 編寫原生代碼，PhoneGap將從Web視圖發送請求至原生代碼，并實現所需的任何原生代碼。

大致上來說，開發者可以參與到驅動核心PhoneGap原生API的同一個異步消息傳遞系統.#p#

PhoneGap方法的優點

據本人估計，PhoneGap架構方面的主要優點是，它非常小巧、簡單。它只做自己擅長的工作。PhoneGap團隊有意為基于Web瀏覽器的應用程序只實現最基本的原生API。由于原生API集非常小，因而把PhoneGap移植到許多不同的環境來得比較容易。基本上來說，支持Web視圖或Web運行時環境的任何原生平臺都可以是一種PhoneGap平臺。

PhoneGap中的非可視原生擴展也非常簡單。說到登記原生代碼、接收來自Web視圖的消息，這方面的要求也非常低。因而可以迅速開發出簡單的原生擴展。在我看來，這種插入式架構還得到了很好地落實。

另外還有這個優點：原生API和原生應用程序開發對前后端開發者來說幾乎完全是抽象的。凡是能編寫HTML、CSS、甚至一小段JavaScript代碼的人都能用原生應用程序來包裝網頁，并將其作為原生應用程序來分發。使用PhoneGap把網頁包裝成原生應用程序方面的準入門檻極低。

PhoneGap方法的缺點

PhoneGap應用程序中用戶界面的質量會不一樣，取決于Web視圖和平臺上渲染引擎的質量。iOS平臺上基于Webkit的渲染引擎很強大，并且提供了最佳性能。AndroidWeb視圖可以用，但是存在一些明顯的局限性。在其他平臺上，Web視圖的性能可能成問題，這要看操作系統的版本。

還有Web開發者始終不得不處理的常見的跨瀏覽器問題。用戶界面需要采用漸進式增強、媒體查詢和種種辦法，才能在多個平臺上依然可以使用。現在許多移動平臺采用Webkit，這有所幫助；但是即便在基于Webkit的環境中，仍存在很大的差異。

移動瀏覽器一直在變得越來越好，這將有助于緩解那些問題。但著手處理瀏覽器中原生用戶界面質量的用戶界面性能絕非易事——Sencha雇用了一大批的Web編程專家，讓這些專職人員專門解決這個問題。即使如此，在大多數平臺上，在如今的大多數瀏覽器中，根本不可能達到原生用戶界面質量的用戶界面性能和響應能力，哪怕使用像Sencha Touch這么高級的框架。不過，瀏覽器是不是已經“足夠好”？這取決于你的需求和感受，但是毫無疑問它不如原生用戶界面來得好。有時候要差得多，這取決于實際的瀏覽器。

PhoneGap還無法用原生用戶界面來加以擴展。前后端開發者的應用程序本身駐留在Web視圖里面，用戶界面由HTML加以渲染。你可以把消息傳遞到原生代碼，并創建在Web視圖之上或鄰近Web視圖的原生用戶界面，但是很難或不可能把動態的、基于文檔對象模型（DOM）的HTML用戶界面與原生用戶界面組件集成起來。Appcelerator會想出辦法——我們試圖及早把原生用戶界面與DOM元素聯系起來，但由于結果無法預測，而且質量不夠好，因而需要放棄這方面的工作。

力求“最基本”是把雙刃劍，它還有另一面。默認情況下，提供給PhoneGap應用程序的原生API非常少，這使得平臺集成很有限。現在有各種各樣的插件，它們用來堵住其中一些漏洞；但是在我看來，它們的質量和維護水平參差不一。不過，這方面的情況很可能會繼續得到改進——PhoneGap有一個強大的社區。

   我們不久會更深入地探討PhoneGap的理念方面，但是先來探討一下Titanium的同樣這些技術方面。#p#

Titanium想實現什么樣的目的？

Titanium Mobile的目的是，為移動開發提供一種高級的、跨平臺的JavaScript運行時環境和API（今天，我們支持iOS、Android和瀏覽器，很快會支持黑莓10，最終會支持Windows Phone。）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的最終用戶工作流、工具和接口

想用Titanium來開發原生應用程序，開發者就需要安裝面向iOS和Android的原生工具鏈。不過，這些工具安裝完畢后，開發者通常只能與TitaniumSDK的腳本接口（如今基于Python）進行交互。這一步可以直接通過命令行來完成，也可以通過我們基于Eclipse的集成開發環境（IDE）：Titanium Studio來完成，后一種方式比較常見。

使用Titanium工具集，你可以創建含有配置文件和本地化文件的應用程序項目目錄，以及含有圖像、資產和為了運行應用程序而編寫的JavaScript源代碼的目錄。在默認情況下，你不用編輯HTML和CSS文件，除非你想創建同時含有原生用戶界面和基于HTML的用戶界面的混合型應用程序。Titanium應用程序可以、而且常常的確采用“混合型”（原生和Web）用戶界面，比如Facebook的原生應用程序。這樣一來，開發者實際上可以實現PhoneGap和Titanium，但是這不在本文的討論范圍之內。

借助該工具鏈，你的應用程序使用面向目標平臺的實際仿真器/模擬器來運行。TitaniumStudio還提供了逐步調試、代碼完成及其他IDE級別的特性。

安裝到設備上進行測試也通常使用我們的編譯系統來完成。在Studio中，我們提供了一個向導界面，以配置任何代碼簽名依賴關系，然后處理將應用程序部署到連接設備上的任務。還可以使用原生工具鏈來部署或包裝你的應用程序，如果你喜歡這么做的話。

等到將你的應用程序發布到應用程序商店時，我們的編譯系統將為你處理創建最終應用程序包的任務。借助原生工具鏈，這一步在開發者的機器上本地完成。上傳過程對純原生應用程序開發者來說一樣。

開發Titanium應用程序時，底層的工具鏈大多數是抽象的。它們是開發所必不可少的，但是很少要求前后端開發者直接使用它們。不過，開發原生應用程序這并不抽象。用戶界面是用跨平臺組件和針對特定平臺的組件共同開發而成的，你的應用程序應該處理這些事務：后臺服務、本地通知、應用程序標記、配置、活動/目的（在Android平臺上）……所有這些都通過Titanium JavaScript API來提供。#p#

Titanium是如何工作的？

Titanium應用程序后臺發生的事情相當復雜。但大致上來說，在運行時，你的應用程序包括三個主要組件：JavaScript源代碼（內嵌在Java或Objective-C文件中，作為編碼字符串來編譯）；用原生編程語言針對特定平臺實現的TitaniumAPI；以及用來在運行時評估代碼的JavaScript解釋器（默認解釋器是V8，或面向Android的Rhino解釋器，或面向iOS的JavaScriptCore解釋器）。當然在瀏覽器中除外，這時將使用內置的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方面的兩個常見的誤解——第一個誤解是，Titanium從來不需要使用Web視圖組件。開發者可以把Web視圖創建成原生用戶界面窗口組件，但是Web視圖并不用來評估Titanium源代碼。第二個誤解是，JavaScript代碼在Titanium中并不交叉編譯成Objective-C或Java。你的JavaScript源代碼在運行時加以評估。

擴展Titanium

Titanium可以用原生代碼，由非可視功能和用戶界面功能來擴展。通過用原生代碼來實現代理接口及/或視圖代理接口，開發者就能為由JavaScript提供的Titanium應用程序創建新的原生功能。我們為使用iOS和Android平臺的模塊開發者提供了用來創建Titanium自有內部接口的同一接口。#p#

Titanium方法的優點

由于Titanium的目的是為跨平臺的原生移動開發提供一種更高級的API，所以你可以直接訪問一系列廣泛的原生特性和功能，從用戶界面組件、插座接口到通知系統集成。Titanium的目的是，將Titanium應用程序和純原生應用程序之間在功能方面的差異縮小到幾乎為零。我們可能從來不直接支持整個平臺的API，但是我們希望能涵蓋90%最常見的用例，并且提供一個平臺，以便有需要的人可以添加剩余10%的用例。

由于Titanium可以用插入到與應用程序其余部分一樣的視圖層次體系的可視組件來擴展，你最終能夠在底層原生平臺上實現任何可能的用戶界面。需要使用特殊的原生代碼，讓表格視圖（TableView）以60fps的速度滾動？你能做到這一點。想無縫地集成游戲的OpenGL繪制曲面，同時用JavaScript保留運行循環的邏輯？你能做到這一點。你可以把這些用戶界面擴展直接集成到用核心Titanium API編寫的應用程序中。

使用常用的用戶界面窗口組件時，Titanium應用程序的外觀和感覺也是這種平臺的一個優點。不用進行可視仿真（或通過應用CSS，或者使用OpenGL或Flash渲染用戶界面窗口組件）。當你創建NavigationGroup時，它得到iOS上的實際UINavigationController的支持。動畫和行為與原生應用程序用戶預期的相一致，因為你使用同樣的用戶界面控件。

由于Titanium通過JavaScript提供了一種高級的原生編程API，為用過基于ECMAScript的語言（這門語言擁有眾多開發者）的任何人大大降低了原生編程方面的準入門檻。正由于Titanium，阿特伍德定律（Atwood’s Law）依然適用。該定律是指：凡是可以用JavaScript編寫的應用程序，最終都會用JavaScript來編寫（詳見）。

Titanium方法的缺點

Titanium API的范圍使得添加新平臺有難度——在一種新的原生平臺上實現Titanium API是項艱巨任務。正由于如此，Titanium平臺只出現在目前被認為最重要的移動平臺上：iOS、Android和Web。

我們的移動Web瀏覽器支持還沒有達到可以投放市場的質量——我們在繼續致力于改進我們的用戶界面窗口組件集的性能和感覺上，同時完善核心Titanium API的實現。

由于Titanium提供的抽象層很龐大，我們自己的內部框架仍存在API實現未達到最佳標準的問題。在一些情況下，一些用戶界面組件還無法做到性能與原生用戶界面組件一樣好，比如布局高度定制化的非常龐大的表格視圖。優化核心的用戶界面組件對我們團隊來說仍是首要的技術任務。由于我們日漸克服缺陷、硬件日臻完善，我們看到這不再是個問題。我們還發現，許多情況下需要運用信息架構，對龐大數據集而言更是如此。

另外由于Titanium平臺的宏偉目標，擴展Titanium并非易事。想有效地集成一種新的原生控件或API，深入了解Titanium的架構和環境必不可少。開發者體驗、API文檔和面向模塊開發者的總體指南。因我們最新的2.0版本而有了大幅改進，但仍是我們關注的一個方面。#p#

理念方面的差異

至此，我希望PhoneGap和Titanium技術方面的差異已很明了。但是除了那些差異外，每個項目的目的和方向也不同。PhoneGap的既定目標是最終不復存在。如前所述，PhoneGap旨在成為實現設備方面新興瀏覽器標準的主要手段。從理論上來說，一旦瀏覽器廠商實現了PhoneGap的特性，這個平臺將再也沒有必要。PhoneGap本身不想成為一種平臺——它是把類似原生應用程序的功能添加到Web應用程序的一種插件（shim）。Web旨在成為這樣的平臺。

PhoneGap新的贊助公司Adobe對于Web作為一種平臺日臻完善也有著非常濃厚的興趣。近幾個月來，Adobe一直在不遺余力地生產能夠開發HTML 5/CSS 3 Web應用程序的工具。在我及其他許多人看來，由于標準Web技術不斷發展，Adobe顯然認為Flash的角色日漸式微。

就本質而言，Adobe是一家主攻工具的公司。平臺其實是Adobe可用來銷售工具的一個渠道。這個平臺一度是Flash。而現在，除了Flash外，這個平臺主要還是Web瀏覽器。我不知道PhoneGap在Adobe的產品路線圖中到底扮演怎樣的角色，但是從許多方面來看，它起到了與Flash相似的用途。PhoneGap試圖建立一種抽象的運行時環境，能夠實現跨平臺部署。

如果Adobe能銷售為Web進行開發的工具，Web又可以用來開發更多種類的應用程序，那么這對Adobe來說顯然是一大勝利。順便說一下，這很好——銷售工具沒什么不對。

不過值得一提的是，Adobe并不是Cordova項目的管理機構，如今PhoneGap基于該項目。這個項目歸Apache軟件基金會擁有和管理。這兩個項目之間會產生怎樣的相互影響仍需拭目以待；但是我的直覺認為，它們不會出現很大的分歧。我認為，這兩個項目的目的在理念上仍會保持一致。

Appcelerator也對Web作為一種平臺日臻完善抱有興趣，并給予了支持。當Web作為一種應用程序平臺變得更強大，大家都是贏家。區別在于，我們認為Web是其中一種出色的平臺，具有獨有的特性和一系列優缺點。我們并未指望Web成為唯一的移動應用程序平臺。我們認為，iOS、Android、黑莓和WindowsPhone之類的平臺繼續頗具影響力，為用戶們提供出色的體驗。這種選擇和競爭對消費者來說將是件好事，但是對開發者來說仍是個問題。

我們期望通過Titanium為開發者提供的是這樣一種方式：借助單一代碼庫，同時涵蓋Web平臺和原生平臺，同時保留該平臺的用戶所期望的特性、性能以及緊密的平臺集成。我們期望為移動客戶端開發建立一種持久不衰的平臺，而服務和工具可以加快這個過程。我們不是一家主攻工具的公司——我們是一家平臺公司，我們的成功將與使用我們平臺的開發者的成功息息相關。隨著時間的推移，我們希望打造一家開源平臺公司，本著紅帽及該領域其他巨頭的精神。

哪種工具或方法適合你？就像軟件開發領域的所有方面一樣，這得看情況。沒有什么萬能的技術。不過但愿這番描述和比較會幫助你做出適合自己情形的選擇。

原文地址：

http://developer.appcelerator.com/blog/2012/05/comparing-titanium-and-phonegap.html

【51CTO譯稿，非經授權謝絕轉載，合作媒體轉載請注明原文出處、作者及51CTO譯者！】