跨平臺移動開發工具:PhoneGap與Titanium全方位比拼

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及其是如何工做的。

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；這款工具現在獲得了更普遍的應用。總的來講，你開發原生應用程序這個事實在開發過程當中基本上是抽象的。

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的同一個異步消息傳遞系統.

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的一樣這些技術方面。

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來提供。

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自有內部接口的同一接口。

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版本而有了大幅改進，但還是咱們關注的一個方面。

理念方面的差別

至此，我但願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譯者！】

【編輯推薦】

1. 比較Titanium和PhoneGap兩大iOS移動應用開發框架