Web開發者的跨平臺移動應用開發策略及工具
在之前的一篇文章中，我們曾經討論過，對于交互和視覺設計相關職能的從業人員來說，從傳統Web行業向移動應用領域轉型的過程中需要學習和注意的問題。這篇文章中提到過“混合型應用”的概念，以及與之相關的兩本開發指導書籍。今天這篇文章的英文原文，就是來自這兩本書的作者——移動應用開發者Jonathan Stark。
本文中，他將站在傳統Web前端開發人員的角度，為我們介紹一些在實際項目案例中總結出來的移動應用開發方法策略，以及幾類具有代表性的用于打造跨平臺移動應用的前端開發工具。
各位前端開發相關職能的同行們，擴展視野、提升技能、隨“機”應變的時機已然成熟;衷心希望本文可以成為推動大家事業進步發展的一個催化點。不多說了，我們來看正文。
無論站在怎樣的角度去衡量，移動互聯網及客戶端應用的發展勢頭都是非常迅猛的。日均使用量、智能手機的普及率、來自移動設備的訂閱量、搜索引擎流量、廣告呈現、應用售賣...所有這些都處于迅速上升的狀態。可以預計，在不久的將來，移動設備將擁有足夠的成熟度與普及率，并躋身于傳統桌面電腦、筆記本等硬件平臺的行列，成為我們日常生活的主要設備。
巨大的移動市場為傳統Web設計開發人員帶來了新的機遇與挑戰。各類移動設備在爆發式增長的同時，也帶來了***的分裂與混亂的狀況。如果需要同時為多平臺設備進行客戶端應用的開發、測試和維護，勢必會消耗大量的資源與成本。
本文中，我們首先會對幾種移動化解決方案進行比較和分析，然后將重點放在一些常見的用于跨平臺移動應用開發的前端框架工具上;不過我不會在***選出一個所謂的***方案——開發方式的選擇最終會取決于你的項目本身，包括業務模式、需求、目標市場、開發資源等多方面因素。本文的主要目標是提供一些有用的信息，幫助各位讀者在實際項目中選擇最合適的方法與工具。
Web應用(Web App)與原生客戶端應用(Native App)
關于這兩種移動化方案孰優孰劣的辯論已然有不少了。
我相信，如果你能以Web應用的方式打造移動化產品，那么你確實應該這樣做;反之則不應該...另外一種情況則介于兩者之間，即通過HTML、CSS、JavaScript等前端技術，結合移動設備原生開發方式，打造所謂的混合型應用。
看似廢話，但重點在于“能”或“不能”。這里我們主要指具體的項目需求，而非技術開發能力。我所在的團隊，做過的多數案例，都來自于企業級的客戶。大公司，顧名思義，在人員、產品及服務等方面都具有相當的規模，他們所需要的移動化解決方案在跨平臺方面的需求都很高。
當接手一個新的企業級移動化項目時，我會將Web App作為默認的***方式，同時結合以下三個問題進行進一步評估：
1. 功能方面，是否涉及那些只有本地應用才能利用的設備硬件資源?
比如，一款有條形碼掃描功能的應用，必須配合設備的攝像頭進行工作，而攝像頭是瀏覽器無法獲取的硬件資源，所以這款應用不能以Web App的形式存在;類似的功能還包括影像音頻的錄制傳輸、后臺運行、消息推送等。如果該產品確實必須基于這些功能才能被正常使用，那么原生客戶端應用便是不二之選。
2. 該產品的用戶是誰?
如果產品擁有大規模的公眾用戶群，那么原生或Web應用的方式都是可選的，前者可以通過平臺官方的App Store或應用市場進行推廣，后者的跨平臺性更好。如果產品屬于公司或組織內部使用的管理信息系統等類型，那么Ad hoc、類似Apperian這樣的第三方App Store或Web App都是可選的。
3. 該應用在系統資源消耗等方面的敏感度如何?
很多方面的因素會使移動設備瀏覽器占用過多的內存資源，從而影響Web App的執行效率及用戶體驗。這些因素包括半透明視覺效果及動畫效果、大量的內容數據、文件加密和解碼、基于地圖的復雜交互方式等。
回答了這三個問題之后，對解決方案的選擇便容易多了。舉例說，比如我收到的需求是為企業員工設計開發一款B2E應用，用來管理他們的個人信息及收益情況，并且不需要使用移動設備提供的高級硬件功能，那么Web App的方式是最恰當的選擇。另外一方面，如果需求是開發一款面向大眾的虛擬地圖應用，并需要配合手機的陀螺儀功能才可以工作，那么我們必須選擇本地客戶端的方式進行開發。
不過，正如我們之前提到的，在這兩者之間，還有另外一種混血方案可以去考慮，也就是混合型客戶端應用。
#p#
原生客戶端應用(Native App)與混合型客戶端應用(Hybrid App)
所謂混合型應用，就是在原生客戶端中嵌入基于前端技術構建的頁面視圖;這種方式其實已經很常見了。本質上講，頁面視圖就是HTML頁面，但它不需要另外調用移動設備中的瀏覽器進行查看和操作。
混合型應用的典型實例其實是我們非常熟悉的：iPhone、iPad等iOS設備的本地App Store或iTunes，以及Twitter和Facebook的客戶端等。
在混合型應用中，原生的部分其實只相當于一個架子或容器，應用的核心是基于HTML、CSS、JavaScrit或前端框架打造的頁面視圖。頁面的靜態文件資源可以存儲在服務器端，動態數據通過Ajax的方式在頁面視圖與移動應用中傳輸。
所以，雖然從技術上講，混合型應用是設備本地化的，但它們顯然擁有兩種不同的運作方式。下面是兩個很常見的問題，在需求評估時經常會遇到。
Q：如果我有技術及資源去開發一套純粹的原生客戶端應用，那么有什么必要使用HTML等Web前端開發方式去打造混合型應用呢?
A：混合性應用的解決方案最主要的目的是解決跨平臺的問題;對于每個平臺，只需開發和維護“容器”性質的本地應用部分，而實際的內容功能則可以統一由一套頁面視圖來擔當。
Q：那么干脆只做一套Web App好了，為什么還要使用原生客戶端作為容器呢?
A：這個問題的答案包括兩方面：
商業需求：對于很多客戶案例來說，將應用通過App Store或Market推廣出去，是一種商業方面的需求。比如，客戶也許會希望自己的產品是付費應用，或者開發前的用戶研究表明他們的用戶多數是通過App Store安裝本地客戶端的。
硬件功能需求：混合型應用的一個優勢在于，雖然本地化的框架只是作為頁面視圖的容器，但它畢竟是本地化的，在需要的時候，仍可提供訪問硬件設備及相關功能的權限;這是單一的Web App所無法做到的。技術方面，可以通過JavaScript經由本地應用框架，與硬件功能進行通訊，例如控制攝像頭等。
我確信，通過這種需求梳理，多數人會傾向于混合型應用的方式。其實這也正是本文接下來的主線——我們一起來看看有哪些前端開發工具是可以幫助我們進行混合型應用的開發的。我將它們分為四大類，接下來會分別進行介紹，并對它們的適用情況進行簡單的對比。
跨平臺的前端開發工具
這是***大類，主要包括一些在傳統Web前端開發方面比較常見的JS框架。它們在混合型應用的頁面視圖中可以起到同樣重要的作用。
jQuery顯然是最有群眾基礎的JS庫之一，為各種常見的JS功能需求提供了統一的API，包括DOM操作、Ajax、事件綁定等。它通過了A、B、C全部三個級別瀏覽器(包括桌面與移動版本)的嚴格測試，擁有龐大的開發者社區以及優質的文檔資源，并且是完全開源的。
凡事有利必有弊，jQuery在瀏覽器方面的優異表現，一定程度上取決于它包含了大量用于修正桌面瀏覽器兼容性問題的代碼;對于移動應用方面的開發來說，這方面的代碼是沒什么意義的。這讓jQuery看起來有些重了。
對我個人來說，如果需要開發一個傳統的、主要用于桌面設備瀏覽的網站，那么jQuery會是我的主要選擇。但是對于網站移動化方面的項目或是混合型應用的開發，我不會選擇它。
51CTO推薦專題：jQuery從入門到精通
Zepto（http://zeptojs.com/）
在移動化開發方面，作為一款更輕量的框架，Zepto是jQuery的一個不錯的替代品。Zepto并沒有被聲明可以兼容舊瀏覽器，包括IE6等，同時，它在功能方面卻幾乎可以與jQuery媲美。如果你習慣于使用jQuery，那么你完全可以通過Zepto進行網站移動化或是混合型應用的開發。
XUI（http://xuijs.com/）
作為一款輕量級JavaScript框架，XUI是特別為移動版本的瀏覽器打造的。XUI的側重點是移動瀏覽器中最常見的功能需求，以最少的代碼量實現最基本的功能。語法方面也很簡單，不過與jQuery的風格有所區別，需要加以習慣。
Lawnchair（http://westcoastlogic.com/lawnchair）
Lawnchair也是一款輕量級JS庫，它***的特色是，可以將客戶端抽象為持久化的“無SQL”風格的數據存儲空間。它采用適配器模式，支持多重回調機制。語法風格非常簡單直白，支持簡單的query查詢。
在開發混合型應用或傳統網站時，出于客戶端持久化存儲功能的需求，或是性能等方面的考慮，我會選擇Lawnchair作為框架。
其他
可以輔助移動應用開發的JS框架還有不少，并且會時不時的冒出一些新的。值得一提的還有now.js、backbone.js和underscore.js等。
#p#
專門用于打造移動客戶端的JavaScript UI 框架
某種程度上說，jQuery Mobile就相當于移動應用版本的jQuery UI;它是一個掛件庫，用來將語義化的HTML標記語言轉化成無論UI樣式還是交互行為都更貼近移動設備原生風格的模式。
繼承了jQuery的優點，jQuery Mobile對A、B、C三個等級的移動瀏覽器保持了全面兼容。它推出的時間不長，但目標很明確——為盡量多的移動瀏覽器打造用戶體驗最棒的移動應用。雖然略重了些，但jQuery Mobile絕對是打造移動應用的***框架之一。
51CTO推薦專題：jQuery Mobile基礎入門教程
與jQuery Mobile類似，jQTouch同樣是一款將語義化HTML標記轉化為移動設備原生風格頁面視圖的掛件庫。這兩者之間的區別是，jQTouch是特別為A級WebKit內核的移動瀏覽器打造的。這意味著jQTouch可以使用WebKit內核瀏覽器的專有功能渲染頁面，相比于JM，所需的代碼更少。所以，當我手頭項目的目標用戶多數為WebKit內核瀏覽器使用者的時候，我會選擇jQTouch進行開發。
很快，jQTouch將支持Zepto，屆時，jQuery就不再是打造頁面視圖本身功能的唯一選項了。這個改變將會有效的減小文件尺寸，降低運算處理時的系統資源開銷。
Sencha Touch是一個基于ExtJS的全功能掛件庫。與jQTouch相同，Sencha Touch也是面向A級WebKit內核的移動瀏覽器的。基于ST打造的移動應用具有很強的健壯性，在UI方面的自適應性也很出色，例如，在平板電腦中，頁面視圖會切換至大屏幕規格，包括結構和元素的布局等。
與jQuery Mobile或jQTouch不同的是，Sencha Touch不是基于HTML標記語言的，開發者必須采用客戶端MVC風格直接書寫JS代碼，所以學習曲線略微陡峭。
Sencha Touch比較適合開發那些主要運行在WebKit內核移動瀏覽器里的中到大型的Web應用。
SproutCore同樣是一款開源JS框架，最初的目的是幫助Web開發人員創建運行在桌面瀏覽器中的Web應用。實際上，它的功能太強大了，以至于蘋果公司使用它來構建了最初版本的MobileMe.
不過，源于它桌面應用的初始需求，SproutCore在尺寸方面對于真正的移動化解決方案來說還是略大了些，至少我***一次用到它的時候是這樣的情況。
#p#
跨平臺的本地應用開發工具
PhoneGap可以將基于標準HTML、CSS和JS打造的頁面視圖封裝為本地客戶端應用，目前支持10種移動平臺。在數據資源傳輸方面，可以采用普通Web App所使用的Ajax等方式。PhoneGap在頁面視圖與本地應用之間提供了一個橋梁，允許開發者通過JavaScript訪問并使用移動設備的硬件功能，比如攝像頭、聯系人信息、麥克風等;這是單純依靠移動瀏覽器運行的Web App類應用所無法實現的。
PhoneGap不屬于掛件庫，它也不會將HTML編譯為原生客戶端代碼。通過PhoneGap封裝的移動應用，只能在運行的過程中即時執行JavaScript，所以它無法像前面介紹的幾種JS UI框架那樣提供一套完整的移動化UI方案。但是PhoneGap的側重點很顯然是在本地化封裝這方面;我開發過的每一個混合型應用都會用到PhoneGap。
Titanium Mobile（http://www.appcelerator.com/products/titanium-mobile-application-development/）
Titanium Mobile可以直接將JavaScript編譯為iOS或Android平臺的本地應用代碼。開發者們經常將它與PhoneGap做比較，其實它們的機制是截然不同的。在Titanium中，開發者需要按照它規定的語法書寫應用代碼，而無法使用原生JS;從這個角度講，Titanium與前面提到的的Sencha Touch類似。對于資深JS開發者來說，這種方式不會帶來很大困難，而新手則需要學習和適應。
Corona是一款商業SDK，使用Lua構建。開發者可以通過Corona為iOS和Android兩大平臺開發原生UI效果真實飽滿的移動應用。它擁有一個完整的圖形和動畫庫，渲染引擎可以充分利用GPU的功能。這讓Corana非常適合移動游戲的開發，不過它在普通移動應用開發方面的表現同樣不錯。
企業級移動應用開發平臺(Mobile Enterprise Application Platforms,MEAPs )
MEAP一種整合性的開發平臺，通過一個后臺，對跨平臺移動應用的開發項目進行全周期的管理;涉及到的細節已經超出本文范圍。之所以把這類放進來，是因為其中RhoMobile曾經被視為PhoneGap的競爭對手，但實際上它們根本不是一回事。典型的MEAPs平臺有：
Antenna Softwware
Pyxis Mobile
RhoMobile
Sybase Unwired Platform(SUP)
總結
我個人從不會將Web應用與本地原生應用看作非此即彼的兩個獨立命題，它們更像是一個范圍的兩個極值。很多時候，要考慮的不是選擇哪種方式的問題，而是要根據需求，評估基于HTML、CSS和JS打造的Web App頁面視圖部分與原生應用的比例問題。
使用前文提到的一些方法對需求進行評估，確認可以使用混合型應用的模式開發產品項目，接下來，我建議將目標放在對頁面視圖部分的比例控制上。根據產品的具體需求和設計情況，在保證不會對用戶體驗等方面起到負面影響的前提下，可以盡量多的使用基于HTML的前端頁面視圖，以增大跨平臺功能的比例。你需要擔心的跨平臺方面的問題越少，用來打造優秀產品的精力及資源就相對越多。
原文：http://beforweb.com/node/22
【編輯推薦】
