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

標籤：android   blog   http   java   使用   strong   

PhoneGap和Appcelerator Titanium，對於封裝和配置行動裝置 App程式而言，二者都是非常受歡迎的開源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成為唯一的行動裝置 App程式平台。我們認為，iOS、Android、黑莓和WindowsPhone之類的平台繼續頗具影響力，為使用者們提供出色的體驗。這種選擇和競爭對消費者來說將是件好事，但是對開發人員來說仍是個問題。

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

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

原文地址：

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

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

【編輯精選】

1. 比較Titanium和PhoneGap兩大iOS行動裝置 App開發架構