前端開發人員的跨平台行動裝置 App開發策略及工具

文章目錄

• Web應用(Web App)與原生用戶端應用(Native App)
• 原生用戶端應用(Native App)與混合型用戶端應用(Hybrid App)
• 跨平台的前端開發工具
• 專門用於打造移動用戶端的JavaScript 使用者介面架構
• 跨平台的本地應用開發工具
• 企業級行動裝置 App開發平台(Mobile Enterprise Application Platforms,MEAPs )
• 總結

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的方式是最恰當的選擇。另外一方面，如果需求是開發一款面向福士的虛擬地圖應用，並需要配合手機的陀螺儀功能才可以工作，那麼我們必須選擇本地客戶 端的方式進行開發。

不過，正如我們之前提到的，在這兩者之間，還有另外一種混血方案可以去考慮，也就是混合型用戶端應用。

原生用戶端應用(Native App)與混合型用戶端應用(Hybrid App)

所謂混合型應用，就是在原生用戶端中嵌入基於前端技術構建的整頁模式；這種方式其實已經很常見了。本質上講，整頁模式就是HTML頁面，但它不需要另外調用行動裝置中的瀏覽器進行查看和操作。

混合型應用的典型執行個體其實是我們非常熟悉的：iPhone、iPad等iOS裝置的本地App Store或iTunes，以及Twitter和Facebook的用戶端等。

在混合型應用中，原生的部分其實只相當於一個架子或容器，應用的核心是基於HTML、CSS、JavaScrit或前端架構打造的整頁模式。頁面的靜態檔案資源可以儲存在伺服器端，動態資料通過Ajax的方式在整頁模式與行動裝置 App中傳輸。

所以，雖然從技術上講，混合型應用是裝置本地化的，但它們顯然擁有兩種不同的運作方式。下面是兩個很常見的問題，在需求評估時經常會遇到。

Q：如果我有技術及資源去開發一套純粹的原生用戶端應用，那麼有什麼必要使用HTML等Web前端開發方式去打造混合型應用呢？

A：混合性應用的解決方案最主要的目的是解決跨平台的問題；對於每個平台，只需開發和維護“容器”性質的本地應用部分，而實際的內容功能則可以統一由一套整頁模式來擔當。

Q：那麼乾脆只做一套Web App好了，為什麼還要使用原生用戶端作為容器呢？

A：這個問題的答案包括兩方面：

1. 商業需求：對於很多客戶案例來說，將應用通過App Store或Market推廣出去，是一種商業方面的需求。比如，客戶也許會希望自己的產品是付費應用，或者開發前的使用者研究表明他們的使用者多數是通過App Store安裝本地用戶端的。
2. 硬體功能需求：混合型應用的一個優勢在於，雖然本地化的架構只是作為整頁模式的容器，但它畢竟是本地化的，在需要的時候，仍可提供訪問硬體裝置及相關功能 的許可權；這是單一的Web App所無法做到的。技術方面，可以通過JavaScript經由本地應用程式框架，與硬體功能進行通訊，例如控制網路攝影機等。

我確信，通過這種需求梳理，多數人會傾向於混合型應用的方式。其實這也正是本文接下來的主線——我們一起來看看有哪些前端開發工具是可以協助我們進行混合型應用的開發的。我將它們分為四大類，接下來會分別進行介紹，並對它們的適用情況進行簡單的對比。

跨平台的前端開發工具

這是第一大類，主要包括一些在傳統Web前端開發方面比較常見的JS架構。它們在混合型應用的整頁模式中可以起到同樣重要的作用。

jQuery

jQuery顯然是最有群眾基礎的JS庫之一，為各種常見的JS功能需求提供了統一的API，包括DOM操作、Ajax、事件綁定等。它通過了A、B、C全部三個層級瀏覽器(包括案頭與移動版本)的嚴格測試，擁有龐大的開發人員社區以及優質的文檔資源，並且是完全開源的。

凡事有利必有弊，jQuery在瀏覽器方面的優異表現，一定程度上取決於它包含了大量用於修正案頭瀏覽器安全色性問題的代碼；對於行動裝置 App方面的開發來說，這方面的代碼是沒什麼意義的。這讓jQuery看起來有些重了。

對我個人來說，如果需要開發一個傳統的、主要用於電腦裝置瀏覽的網站，那麼jQuery會是我的主要選擇。但是對於網站移動化方面的項目或是混合型應用的開發，我不會選擇它。

Zepto

在移動化開發方面，作為一款更輕量的架構，Zepto是jQuery的一個不錯的替代品。Zepto並沒有被聲明可以相容舊瀏覽器，包括IE6等，同時，它在功能方面卻幾乎可以與jQuery媲美。如果你習慣於使用jQuery，那麼你完全可以通過Zepto進行網站移動化或是混合型應用的開發。

XUI

作為一款輕量級JavaScript架構，XUI是特別為移動版本的瀏覽器打造的。XUI的側重點是行動瀏覽器中最常見的功能需求，以最少的代碼量實現最基本的功能。文法方面也很簡單，不過與jQuery的風格有所區別，需要加以習慣。

Lawnchair

Lawnchair也是一款輕量級JS庫，它最大的特色是，可以將用戶端抽象為持久化的“無SQL”風格的資料存放區空間。它採用適配器模式，支援多重回調機制。文法風格非常簡單直白，支援簡單的query查詢。

在開發混合型應用或傳統網站時，出於用戶端持久化儲存功能的需求，或是效能等方面的考慮，我會選擇Lawnchair作為架構。

其他

可以輔助行動裝置 App開發的JS架構還有不少，並且會時不時的冒出一些新的。值得一提的還有now.js、backbone.js和underscore.js等。

專門用於打造移動用戶端的JavaScript 使用者介面架構jQuery Mobile

某種程度上說，jQuery Mobile就相當於行動裝置 App版本的jQuery UI；它是一個掛件庫，用來將語義化的HTML標記語言轉化成無論UI樣式還是互動行為都更貼近行動裝置原生風格的模式。

繼 承了jQuery的優點，jQuery Mobile對A、B、C三個等級的行動瀏覽器保持了全面相容。它推出的時間不長，但目標很明確——為盡量多的行動瀏覽器打造使用者體驗最棒的行動裝置 App。雖 然略重了些，但jQuery Mobile絕對是打造行動裝置 App的最佳架構之一。

jQTouch

與jQuery Mobile類似，jQTouch同 樣是一款將語義化HTML標記轉化為行動裝置原生風格整頁模式的掛件庫。這兩者之間的區別是，jQTouch是特別為A級WebKit核心的行動瀏覽器打 造的。這意味著jQTouch可以使用WebKit核心瀏覽器的專有功能渲染頁面，相比於JM，所需的代碼更少。所以，當我手頭項目的目標使用者多數為 WebKit核心瀏覽器使用者的時候，我會選擇jQTouch進行開發。

很快，jQTouch將支援Zepto，屆時，jQuery就不再是打造整頁模式本身功能的唯一選項了。這個改變將會有效減小檔案尺寸，降低運算處理時的系統資源開銷。

Sencha Touch

Sencha Touch是 一個基於ExtJS的全功能掛件庫。與jQTouch相同，Sencha Touch也是面向A級WebKit核心的行動瀏覽器的。基於ST打造的行動裝置 App具有很強的健壯性，在UI方面的自適應性也很出色，例如，在平板電腦中， 整頁模式會切換至大螢幕規格，包括結構和元素的布局等。

與jQuery Mobile或jQTouch不同的是，Sencha Touch不是基於HTML標記語言的，開發人員必須採用用戶端MVC風格直接書寫JS代碼，所以學習曲線略微陡峭。

Sencha Touch比較適合開發那些主要運行在WebKit核心行動瀏覽器裡的中到大型的Web應用。

SproutCore

SproutCore同樣是一款開源JS架構，最初的目的是協助Web開發人員建立運行在案頭瀏覽器中的Web應用。實際上，它的功能太強大了，以至於蘋果公司使用它來構建了最初版本的MobileMe.

不過，源於它案頭應用的初始需求，SproutCore在尺寸方面對於真正的移動化解決方案來說還是略大了些，至少我最後一次用到它的時候是這樣的情況。

 

跨平台的本地應用開發工具PhoneGap

PhoneGap可 以將基於標準HTML、CSS和JS打造的整頁模式封裝為本地用戶端應用，目前支援10種移動平台。在資料資源傳輸方面，可以採用普通Web App所使用的Ajax等方式。PhoneGap在整頁模式與本地應用之間提供了一個橋樑，允許開發人員通過JavaScript訪問並使用行動裝置的硬體 功能，比如網路攝影機、連絡人資訊、麥克風等；這是單純依靠行動瀏覽器啟動並執行Web App類應用所無法實現的。

PhoneGap不屬於掛件 庫，它也不會將HTML編譯為原生用戶端代碼。通過PhoneGap封裝的行動裝置 App，只能在啟動並執行過程中即時執行JavaScript，所以它無法像前面 介紹的幾種JS UI架構那樣提供一套完整的移動化UI方案。但是PhoneGap的側重點很顯然是在本地化封裝這方面；我開發過的每一個混合型應用都會用到 PhoneGap。

Titanium Mobile

Titanium Mobile可 以直接將JavaScript編譯為iOS或Android平台的本地應用代碼。開發人員們經常將它與PhoneGap做比較，其實它們的機制是截然不同 的。在Titanium中，開發人員需要按照它規定的文法書寫應用代碼，而無法使用原生JS；從這個角度講，Titanium與前面提到的的Sencha Touch類似。對於資深JS開發人員來說，這種方式不會帶來很大困難，而新手則需要學習和適應。

Corona

Corona是一款商業SDK，使用Lua構建。開發人員可以通過Corona為iOS和Android兩大平台開發原生UI效果真實飽滿的行動裝置 App。它擁有一個完整的圖形和動畫庫，渲染引擎可以充分利用GPU的功能。這讓Corana非常適合移動遊戲的開發，不過它在普通行動裝置 App開發方面的表現同樣不錯。

企業級行動裝置 App開發平台(Mobile Enterprise Application Platforms,MEAPs )

MEAP一種整合性的開發平台，通過一個後台，對跨平台行動裝置 App的開發項目進行全周期的管理；涉及到的細節已經超出本文範圍。之所以把這類放進來，是因為其中RhoMobile曾經被視為PhoneGap的競爭者，但實際上它們根本不是一回事。典型的MEAPs平台有：

• Antenna Softwware
• Pyxis Mobile
• RhoMobile
• Sybase Unwired Platform(SUP)

總結

我個人從不會將Web應用與本地原生應用看作非此即彼的兩個獨立命題，它們更像是一個範圍的兩個極值。很多時候，要考慮的不是選擇哪種方式的問題，而是要根據需求，評估基於HTML、CSS和JS打造的Web App整頁模式部分與原生應用的比例問題。

使 用前文提到的一些方法對需求進行評估，確認可以使用混合型應用的模式開發產品項目，接下來，我建議將目標放在對整頁模式部分的比例控制上。根據產品的具體 需求和設計情況，在保證不會對使用者體驗等方面起到負面影響的前提下，可以盡量多的使用基於HTML的前端整頁模式，以增大跨平台功能的比例。你需要擔心的 跨平台方面的問題越少，用來打造優秀產品的精力及資源就相對越多。

 

出處:http://www.20ju.com/content/V185296.htm