哪條道路能帶我們通往成功的彼岸？

【2013年10月9日 51CTO外電頭條】在移動應(yīng)用開發(fā)領(lǐng)域，擺在我們面前的是三條道路：混合、原生與HTML 5。

Native（原生）：

• 豐富的用戶體驗
• 平臺指向性
• 久經(jīng)考驗的移動應(yīng)用開發(fā)途徑

Hybrid（混合）：

• 與應(yīng)用類似的使用體驗
• 利用設(shè)備自身功能
• 多平臺支持能力

HTML 5：

• 更快的開發(fā)周期
• 跨平臺運行
• 實時更新

Hybrid

對于質(zhì)量要求不高的普通業(yè)務(wù)應(yīng)用來說，混合型應(yīng)用在大多數(shù)情況下都能提供必要功能與合理的性能表現(xiàn)。一款混合移動應(yīng)用往往利用HTML 5、CSS3、JavaScript以及PhoneGap共同編寫而成，且運行在iOS、Android、Windows Phone以及黑莓設(shè)備之上。

圖示：一款利用Knockout與ASP.NET MVC的混合移動應(yīng)用

原生

對于游戲應(yīng)用這類對性能、圖形處理要求較高，但不太在乎文件尺寸的軟件來說，原生應(yīng)用才是最理想的選擇——不過大家其實也可以利用PhoneGap實現(xiàn)游戲開發(fā)。

HTML 5

最后，對于任何追求極致輕量化的網(wǎng)站（或者Web應(yīng)用）都應(yīng)該通過HTML 5進行創(chuàng)建，并使用Bootstrap或者Foundation等技術(shù)作為響應(yīng)層。響應(yīng)式Web設(shè)計為設(shè)備提供一套極度精簡化的訪問門戶，技術(shù)人員還能夠根據(jù)需求每天對其加以調(diào)整。

您是否擁有打理原生平臺的必要技能？

影響選擇的另一大重點在于，原生應(yīng)用開發(fā)工作需要大家對各種平臺上的語言具備相當了解（例如C#、Objective-C以及Java）；相比之下，混合應(yīng)用則可以通過CSS3、HTML 5以及JavaScript等比較類似的手段實現(xiàn)開發(fā)。因此，混合應(yīng)用帶來的學(xué)習(xí)曲線相對平緩，因此開發(fā)流程相對較快、成本也更低一些。

獨立平臺還是特殊平臺（也就是高性能平臺）？

除了學(xué)習(xí)曲線之外，原生應(yīng)用還帶來了平臺指向性，因此我們必須要針對每一種平臺開發(fā)一款應(yīng)用——相比之下，混合應(yīng)用能夠運行在大部分主流平臺之上，例如iOS、Android、Windows Phone以及黑莓等。不過有時候用戶對性能的要求更高，這時候具備獨特用戶界面的特殊平臺就有了用武之地。在這類情況下，大家可能發(fā)現(xiàn)原生應(yīng)用比混合應(yīng)用更具優(yōu)勢。反過來說，如果性能不太重要，那么KendoUI Mobile、Sencha Touch以及jQuery Mobile等移動庫所匯集的功能足以讓應(yīng)用成品在外觀與使用感受上與各類平臺以及同一平臺的不同版本相吻合。

何時需要重視移動應(yīng)用的用戶使用體驗？

對于版本眾多的通用型應(yīng)用程序而言，特定平臺的用戶體驗就變得非常重要。對于這類應(yīng)用程序，終端用戶顯然不希望在Android設(shè)備上看到iOS風(fēng)格的用戶界面或者在Windows Phone上體驗與Android雷同的使用感受。不過對于專門針對單一企業(yè)或者業(yè)務(wù)部門的商業(yè)應(yīng)用來說，客戶可以在不同平臺上選擇統(tǒng)一的使用體驗，從而降低開發(fā)及培訓(xùn)成本。如果特定平臺用戶體驗非常重要，那么大家最好選擇以KendoUI Mobile為代表的混合移動框架最為適合。

圖一——利用KendoUI Mobile開發(fā)出的多平臺混合應(yīng)用。

混合框架支持哪些平臺？

原生方案優(yōu)于混合方案的另一大理由在于“平臺支持能力”。大家不妨思考這樣的例子，Sencha Touch無法支持Windows 7 Phone。為了編寫出適合Windows 7平臺的移動應(yīng)用，大家很可能不得不選擇原生開發(fā)模式。大家可以通過下圖了解Sencha Touch所支持的移動設(shè)備平臺：

圖一——Sencha Touch所支持的移動平臺相對有限。

PhoneGap為混合應(yīng)用提供的功能支持

與混合框架有限的平臺支持能力類似，PhoneGap在某些情況下同樣表現(xiàn)欠佳。不過PhoneGap 3.0所提供的功能支持已經(jīng)可以滿足我們的大部分需求——只要對性能要求不是太高。舉例來說，Phone Gap不支持iPhone與黑莓的指南針功能，黑莓、WebOS、塞班以及Bada等版本的媒體功能同樣不在受支持之列。

PhoneGap 3.0在各平臺上的功能支持結(jié)果。

提交PhoneGap應(yīng)用之前的注意事項

在將PhoneGap應(yīng)用程序提交地蘋果iTunes、Google Play或者Windows Phone Marketplace等應(yīng)用程序商店之前，大家首先需要謹慎核對PhoneGap所提供的各項功能是否全部包含在內(nèi)——無論您的應(yīng)用程序是否實際使用到了這些功能。

請務(wù)必確保將下列PhoneGap功能添加到應(yīng)用程序當中，包括：數(shù)據(jù)服務(wù)、移動與方向傳感器、麥克風(fēng)、音樂及視頻庫、持有者驗證、攝像頭、聯(lián)系人以及指南針等。再次強調(diào)，不用理會這些功能是否能夠確實對應(yīng)用產(chǎn)生影響或者在終端用戶的設(shè)備上順利起效——只要添加進去就好。

有了以上列舉的各項標準，現(xiàn)在大家應(yīng)該能夠輕松判斷自己到底應(yīng)該采用混合、原生還是HTML 5等移動應(yīng)用開發(fā)方式。由于大部分使用環(huán)境傾向于以較低的技術(shù)門檻提供多平臺應(yīng)用成果，因此我們不妨將混合移動應(yīng)用視為首選方案。

#p#

混合移動應(yīng)用

混合應(yīng)用之所以被稱為“混合”，是因為它同時利用HTML 5與CSS3創(chuàng)建移動UI，同時又通過JavaScript代碼實現(xiàn)與移動SDK之間的通信。

混合應(yīng)用等同于單頁面應(yīng)用

混合移動應(yīng)用基本上就是一種單頁面應(yīng)用（或者簡稱SPA），而所謂SPA，是指那些只存在于單一HTML頁面當中的Web應(yīng)用。應(yīng)用程序的“視圖”將在用戶操作應(yīng)用程序?qū)Ш綑C制時被添加至DOM當中（或者從其中移除）。單頁面應(yīng)用架構(gòu)最適合以下幾種使用情況：

一）無需利用持續(xù)性頁面刷新實現(xiàn)與原生應(yīng)用相類似的流暢體驗的應(yīng)用程序。

二）UI被整體創(chuàng)建在客戶端上，且創(chuàng)建過程無需依賴服務(wù)器的介入，這一機制對于需要離線運行的應(yīng)用程序來講堪稱理想架構(gòu)。

PhoneGap如何工作？

PhoneGap為移動應(yīng)用開發(fā)人員提供一套名為phonegap-3.0.0.js的JavaScript API。該JavaScript API會調(diào)用PhoneGap的特殊平臺引擎/橋接機制，后者則反過來調(diào)用原生平臺SDK以實現(xiàn)對設(shè)備的操作，例如訪問聯(lián)系人名單或者撥打電話等。在Windows Phone方面，PhoneGap引擎/橋接機制則相當于被整合在WP7GapClassLib.dll文件中的SilverLight。

PhoneGap引擎由各平臺的原生語言所創(chuàng)建（例如C#、Objective-C以及Java），從而為JavaScript開發(fā)者提供顯示界面。PhoneGap JavaScript API與引擎之間的大部分通信需要借助非Chrome瀏覽器URL實現(xiàn)。

gap://SomePlugin.someMethod?arg1Name=someArg1&arg2Name=someArg2

PhoneGap應(yīng)用程序架構(gòu)

PhoneGap還提供一套與HTML 5、JavaScript以及CSS3在非Chrome瀏覽器（例如不提供用戶界面的瀏覽器）中相綁定的創(chuàng)建系統(tǒng)。

PhoneGap創(chuàng)建系統(tǒng)中綁定有js、css以及html，當然這一切只能在非Chrome瀏覽器中實現(xiàn)。

加速裝置

加速計捕捉設(shè)備會感受設(shè)備在x、y及z軸方向的運動。利用PhoneGap，大家可以訪問內(nèi)置于iPhone、Android、Windows Phone以及黑莓等設(shè)備當中的加速計。舉例來說，大家可以通過對App/Supporting Files/Cordova.plist文件的配置獲取對應(yīng)權(quán)限、從而使用iOS加速計。

<key>Plugins</key> 
<dict> 
    <key><a href="http://docs.phonegap.com/en/1.9.0/cordova_accelerometer_accelerometer.md.html#Accelerometer">Accelerometer</a></key> 
    <string>CDVAccelerometer</string> 
</dict> 

Windows Phone采用的權(quán)限獲取方式與iOS相似，大家可以通過對Properties/WPAppManifest.xml進行配置以訪問加速計數(shù)據(jù)。

<Capabilities> 
    <Capability Name="ID_CAP_SENSORS" /> 
</Capabilities> 

加速計會檢測設(shè)備在各個方向的運動軌跡。

[[86897]]

iPhone游戲“重力迷宮”就使用到了加速計功能。

#p#

混合移動應(yīng)用開發(fā)所使用的移動框架

盡管大家完全可以利用HTML 5、CSS 3以及JavaScript完成編碼工作，并將其與PhoneGap加以綁定以提供針對受支持平臺的原生鏡像，但人們通常還是會在混合移動應(yīng)用開發(fā)過程中選擇其它類型的移動框架。這不僅能夠節(jié)約大量代碼行數(shù)進而省去開發(fā)時間，下面所列出的部分熱門框架還能在技術(shù)社區(qū)的幫助下不斷獲得更多功能、平臺支持以及實施能力。

接下來，我們會分別探討KendoUI Mobile、Sencha Touch以及jQuery Mobile，從而幫助各位了解在混合移動應(yīng)用框架的選擇當中哪些因素最為重要。我們還將在后續(xù)文章中進一步剖析其它框架的優(yōu)勢與缺點。  

jQuery Mobile——混合移動應(yīng)用框架

jQuery Mobile是一款易于學(xué)習(xí)的移動框架，擁有活躍且極具規(guī)模的技術(shù)社區(qū)外加大量移動實用工具。相比之下，它的學(xué)習(xí)曲線不像Sencha Touch（售價595美元）那樣嚴酷，難度甚至不及KendoUI Mobile（售價699美元）。不過jQuery Mobile應(yīng)用的列表條目一旦達到五十到六十個，性能就會出現(xiàn)疲軟（甚至直接導(dǎo)致移動瀏覽器崩潰）。在另一方面，Sencha Touch能夠載入超過兩百個條目，且不會引發(fā)任何性能問題。

jQuery Mobile 1.3.2的組成部分包括JavaScript（147KB）、CSS（92KB）、圖片數(shù)據(jù)（約6.6MB，zip格式）以及用戶核心jQuery 1.10.2庫（91KB）。由于移動設(shè)備的內(nèi)存與CPU性能比較有限，因此在解析JavaScript代碼時文件大小就顯得非常重要。有鑒于此，谷歌Closure編譯器、Minify以及YUI壓縮工具紛紛登場，旨在剝離JavaScript代碼中不具實際意義的部分。今后我們會在獨立的文章中對優(yōu)先問題詳加闡述。在本文中，我們將把注意力集中在移動應(yīng)用框架身上。

Closure能夠大大降低JavaScript代碼的體積，同時又不影響其運行效果及原始功能。

為了設(shè)計jQuery Mobile頁面，jQuery Mobile為我們提供了一套便捷的代碼設(shè)計工具——也就是Codiqa。一旦HTML、CSS及JavaScript頁面設(shè)計完成，我們就能夠以zip格式對其進行下載。請大家記住，jQuery UI（一款專為桌面Web應(yīng)用打造的jQuery工具庫）由于同CSS存在沖突而無法被使用于jQuery Mobile。因此我們只能直接使用jQuery Mobile工具或者技術(shù)社區(qū)創(chuàng)建的工具。

用于創(chuàng)建移動UI的Codiqa。

為了構(gòu)建如上圖所示的邏輯UI，大家需要的就是利用jQuery CSS及數(shù)據(jù)屬性編寫我們所熟知的HTML代碼。數(shù)據(jù)屬性是HTML 5中的一項功能，幫助用戶以data-為前綴定義各種“保存有任何信息”的元素，而且這些元素不會對頁面布局造成影響。請注意，<div>中的data-role屬性將使其成為一個用于涵納label與textbox的容器。

KendoUI Mobile——混合移動應(yīng)用框架

KendoUI Mobile是一款基于MVVM的移動應(yīng)用框架，附帶圖表及多款非常實用的移動工具，整體方案售價為699美元。KendoUI支持Knockout等模型綁定，從而成功幫助開發(fā)人員避免編寫大量代碼行。

KendoUI Mobile提供多款實用工具及框架，幫助用戶開發(fā)混合移動應(yīng)用。

為了在移動平臺上實現(xiàn)更為順暢的布局效果，我們需要將KendoUI與Bootstrap或者Foundation等布局庫相結(jié)合來使用——這是因為KendoUI本身并非布局庫。與完全使用JavaScript的Sencha Touch相比，KendoUI的學(xué)習(xí)曲線更為和緩，但卻通過MVC架構(gòu)為開發(fā)人員帶來更出色的靈活性與性能表現(xiàn)。

KendoUI的Hierarchical ListView、ActionSheet以及ListView控制機制能夠很好地羅列應(yīng)用條目，Tablet SplitView控制機制則出色地滿足了平板設(shè)備上的主從復(fù)合使用環(huán)境需求。

KendoUI Mobile的ActionSheet控制機制在iPhone主題下的顯示效果。

KendoUI Mobile的ListView控制機制在Windows Phone主題下的顯示效果。

KendoUI Mobile的SplitView控制機制在Android平板設(shè)備主題下的顯示效果。

KendoUI Mobile主題創(chuàng)建工具能夠被用于在特定平臺上創(chuàng)建主題：

KendoUI Mobile的主題創(chuàng)建工具。

出于性能及靈活性的考量，KendoUI Mobile的iOS主題中并不包含任何圖片信息。全部UI元素都由CSS效果所創(chuàng)建，因此應(yīng)用程序本身看起來與真正的iOS應(yīng)用存在些許區(qū)別。

KendoUI利用其dataviz組件帶來交互式圖形效果，從而實現(xiàn)數(shù)據(jù)可視化功能。要繪制圖形，KendoUI會自動檢測瀏覽器功能并利用SVG（或者將VML作為備選方案）。IE 6、IE 7以及IE 8只支持VML；IE 9則支持某些SVG功能；其它主流瀏覽器則全部支持SVG。

KendoUI Mobile dataviz生成的圖形效果。

Sencha Touch——混合移動應(yīng)用框架

Sencha Touch用極高的使用復(fù)雜性外加相當夸張的學(xué)習(xí)曲線換得無與倫比的性能表現(xiàn)。Sencha Touch屬于MVC且完全采用JavaScript機制，對于Web開發(fā)人員來說其難度有些無法接受，但對Java/C#出身的開發(fā)者來說則問題不大。雖然有些不便，但其出色的性能表現(xiàn)令人印象深刻——尤其是與jQuery Mobile那孱弱的能力相比。

由于Sencha Touch最初只針對iOS平臺，而后才添加了對Android、黑莓以及Windows Phone的支持能力，因此大家應(yīng)該做好心理準備——其在各平臺上的性能表現(xiàn)并不完全一致。

Sencha Touch提供一大堆移動實用工具，例如Navigation View & Carousel以及一套強大的布局庫。

Sencha Touch中的Carousel View控制機制。

與PhoneGap一樣，Sencha Touch同樣擁有原生打包與部署系統(tǒng)。因此，大家完全可以單純利用Sencha Touch創(chuàng)建出終端到終端跨平臺解決方案且無需讓PhoneGap涉入其中。

#p#

HTML 5響應(yīng)式網(wǎng)站

我們已經(jīng)在之前的文章中討論過應(yīng)用程序開發(fā)，不過現(xiàn)在我們需要針對移動網(wǎng)站開發(fā)工作的中一些要點性概念進行深入剖析。

移動瀏覽器

移動瀏覽器與傳統(tǒng)桌面瀏覽器的區(qū)別在于，它支持兩種視圖端口——也就是Layout與Visual。Layout檢視區(qū)被所有CSS計算所使用；而Visual檢視區(qū)則作為當前設(shè)備屏幕上html文檔的組成部分。Layout檢視區(qū)在不同瀏覽器上的實際顯示寬度有所區(qū)別。iPhone上的Safari瀏覽器使用的是980像素、Opera為850像素、Android Webkit為800像素，IE則為974像素。在黑莓設(shè)備上，布局視圖始終保持100%原始檢視區(qū)尺寸，而且絕對不會變更。

window.innerWidth // and innerHeight for visual viewport dimensions
document.clientWidth //and clientHeight for layout viewport dimensions

移動瀏覽器支持兩種檢視區(qū)方案——Layout與Visual。

Hash片段被用于索引Ajax類網(wǎng)站。

大部分移動網(wǎng)站基于Ajax，也就是在必要時才載入對應(yīng)內(nèi)容。在典型網(wǎng)站當中，URL既是一種標記書簽與分享內(nèi)容的方式，又可以作為網(wǎng)站索引當中的搜索引擎。不過Ajax類網(wǎng)站，例如Twitter與Facebook，會下載JavaScript代碼，從而使Ajax調(diào)用請求獲取到更多內(nèi)容。但這會產(chǎn)生一些問題：以谷歌為代表的搜索機制并不會解析JavaScript代碼或者發(fā)出Ajax請求，因此其永遠無法獲取與用戶瀏覽內(nèi)容相一致的頁面。由此導(dǎo)致的結(jié)果？網(wǎng)站的索引機制變得亂七八糟、無法正常使用。

為了創(chuàng)建一條能夠向搜索機制返回HTML而非JavaScript內(nèi)容的URL，我們需要使用Hash片段（例如#?。?。像http://twitter.com/#!/mashable或者www.example.com/ajax.html#!key=value這樣的Ajax網(wǎng)站或者單頁面應(yīng)用會向搜索機制返回靜態(tài)HTML，從而改進站點的索引效果。

本文節(jié)選譯自Challenges & solutions - Architecture of a Modern Web Application - Mobile App。轉(zhuǎn)載請附上原文及本文鏈接。