深入解析跨平臺工具:背后技術,對應開發階段及垂直發展
在本系列的第一篇文章（跨平臺領域的淘金潮——為什么跨平臺領域工具會改變現狀）中，為大家介紹了跨平臺工具產生的背景以及其粗略的介紹。
那么接下來，究竟選擇Web App還是本機App，在眾多的跨平臺工具中又該何去何從？ 你也許能從本篇文章中得到你想要的答案。
一個跨平臺工具由五部分組成，它們和app生命周期的五個階段相對應，這五個階段分別為開發階段，集成階段，發布階段，部署階段和管理階段。
1.開發階段：跨平臺工具提供從低級到高級的各類開發語言，底層精簡的語言比如LiveCode和Lua以及像HTML，CSS和JavaScript這樣的web語言，中間層語言如Java、C#/.NET以及像C++這樣的更底層的語言。
許多工具都提供可視化拖放環境，另外一些則只提供限制性的基于模板的app開發流程。一些工具只針對特定的開發人群，例如Impact JS和Lime JS Javascript 框架針對游戲開發者，而RhoMobile和Worklight則用于企業級開發。跨平臺開發工具（CPTs）提供不同的語言來滿足各類開發者的需求，無論你是腳本開發人員、經驗豐富的web開發人員、有創造性的設計者還是核心軟件開發人員。
開發階段的核心部分包括集成開發環境（IDE）、仿真器以及調試器。Eclipse是當前最流行的開源IDE，作為跨平臺的開發環境可以在PC、Mac以及Linux上使用。許多供應商在Eclipse之上提供額外的插件和仿真器。一些供應商會專門為企業級應用的開發人員和品牌設計人員提供免安裝、基于web的開發環境。
開發階段也包括源碼控制，團隊協作和工作流輔助工具。RhoMobile公司的 RhoHub開發平臺使用Git套件進行源碼管理和團隊協作。Unity、Appcelerator、RunRev提供了一個組件交易市場，設計及開發人員可以通過此交易市場出售自己的組件，旨在利用這些現成的組件幫助他人縮短開發周期。Sencha在2011年11月也提供類似的組件出售市場，而Corana和Marmalade則分別推出了模板庫和代碼社區服務。
2.集成階段：本階段是有關如何與本地設備功能、云服務APIs及企業數據庫進行集成的。
為了集成本地設備功能，通常的做法是使用JavaScript以及PhoneGap APIs和庫，這些捆綁集成在一個稱為混合-本地（hybrid-native）的應用程序中。Worklight、AppMobi、Feedhenry和BKrender在他們提供的工具中也包含PhoneGap功能。MoSync和Qt使用類似的方法，將本地APIs和平臺無關的APIs抽象集合封裝在一起。
開發者使用像JavaScript、Lua、LiveCode或者C++這樣的編程語言提供的APIs，來與本地設備功能集成在一起。不同目標平臺上功能相似的函數共享相同的工具級別API，這些API在業務邏輯層面上提供更高級別的代碼復用，而在UI和特定硬件特性的支持方面的復用程度就沒有那么充足。 例如，Mono Touch和Mono for Andriod就沒有共享相同的UI APIs，所有與設備特性有關的APIs在不同設備上面的表現也不盡相同。Apps能夠在運行時調用設備功能，調用要么在編譯期被解釋，要么通過運行時提供的橋接功能傳遞給底層平臺。
集成階段另一個主要部分是要連接到cloud APIs。Cloud APIs正在逐漸變成一個屬于自己的細分市場。對于開發者來說，社交游戲網絡顯得越來越重要，這里不僅僅指Facebook或者LinkedIn。Apple Game Center、OpenFeint、Scoreloop、Skiller，Papaya Mobile和Swarm都為社交游戲提供基于云的APIs。
社交游戲APIs僅僅是其中的冰山一角。包括Bango、Social Gold和Paythru在內有超過14家供應商提供應用程序內計費以及虛擬物品交易平臺。有超過27個像App Annie、Distimo和Flurry這樣的銷售分析工具。有超過8個像Bugsense和Testflight這樣的app測試工具。VisionMobile的Atlas服務有這些提供商的詳細列表。當然，這其中不乏合并的跡象。舉個特殊例子來講，Appcelerator雖然有自己的分析和貨幣平臺，但還是通過收購Cocoafish來集成社交共享和消息推送功能。
針對企業級（B2B）開發者使用的應用平臺通常會提供數據庫連接管理服務。RhoMobile推出RhoConnect移動app集成服務，當后臺有更新時該服務將更新推送給設備以實現數據同步。Antenna、Feedhenry和Worklight推出的跨平臺工具（CPT）提供類似功能的集成中間件。其他專注于企業級應用程序開發的著名跨平臺工具有Stackmob，Oracle（ADF），Aperra和Sybase（Unwired Plaform）等。
3.構建階段：跨平臺的“魔力”通常體現在構建階段。構建應用程序有許多不同的方法。兩種流行的方法：一種是將代碼和UI模板直接編譯成本地平臺二進制碼；另一種是將代碼打包進本地shell然后在運行時解釋執行，這種本地shell可以是一個只包含該代碼的“簡易瀏覽器”，也可以是設備自帶的瀏覽器渲染引擎。下一章節我們將討論構建跨平臺apps的技術方法。
4.發布階段：發布應用包含將app提交到Apple App Store或者Andriod Market這樣的App Store，或者是內部發布并且可以選擇是否將app托管到像Feedhenry，Antanna，RhoMobile或者Worklight這樣的私有企業App Store。包括Sencha2.0，AppMobi的PhoneGap XDK和RhoMobile的RhoHub在內的許多跨平臺工具（CPT）產品都在一定程度上協助管理app發布過程。包括Appcelerator LiveCode和Corona在內的一些提供商將在其網站上展示apps，而Unity則支持將app發布到其他平臺上。
5.管理階段：提供App管理功能是面向企業級的跨平臺工具（CPTs）的特色，比如Worklight，RhoMobile，Antanna和Feedhenry。App管理包括消息推送，數據流管理，遠程安裝（卸載），策略管理和庫存管理。商業Apps管理增加了業績管理功能（即分析工具），該功能可以由工作方法商合作伙伴提供。例如Appcelerator就將自己的分析工具整合進Titanium，而Ansca Mobile將Flurry的分析APIs整合進自己的Corona SDK中。
#p#
跨平臺工具（CPTs）的技術分類
在這份跨平臺工具（CPTs）分析報告中，我們甄別出了五種不同的技術方法，即：JavaScript框架，app工廠，web-to-native框架，運行時以及源代碼翻譯。每種技術都針對特定的開發人群（從非技術人員到經驗豐富的開發人員），并且可以滿足不同的app用例。這些技術方法并不是相互孤立的，許多工具混合使用這些技術方法。例如一些基于運行時的跨平臺開發工具（CPTs）解決方案都會增加一個網頁視圖組件，從而具有了創建混合web app 包裝器的功能。
JavaScript frameworks：JavaScript框架由許多代碼庫組成，旨在加速復雜web任務（例如管理觸摸屏交互，構架跨瀏覽器UI， 管理游戲畫面等）的開發速度。主要提供商有jQuery Mobile，Sencha Touch， Cocos2D，DHTMLX Touch, Zepto JS, Impact.js, iUI以及Wink。JavaScript框架針對這樣一類web開發人員，他們想要創建可觸摸UIs，實現跨平臺瀏覽器兼容，提供本地外觀和感覺，或者是實現復雜的游戲功能。
App factories：App工廠是能夠快速構建簡單移動應用的開源可視化設計工具。它們由一個可安裝或是基于云的開發環境構成，在此開發環境中開發人員可使用模板、拖拽、或者向導來生成app代碼。利用App factories最簡單的可以創建基于RSS的新聞閱讀器或者經濟型apps。在較高層面上，App factories提供基本的可拖拽設計功能。而在最高層面上，App factories提供無須編碼的，基于組件的設計方法，包括與設備和云集成。
非開發人員也可以通過App factories創建他們自己的app。一些app工廠允許開發人員查看和修改自動生成的代碼。其他的app工廠提供包括分析，消息推送和廣告管理在內的一系列post-download服務。這些App工廠包括AppMkr，AppsGeyser，Wix Mobile，Tiggr，Mobile Nation HQ，Mobjectify，Red Foundry和Spot Specific。
Web-to-native wrappers：Web-to-native框架是使用web HTML5，CSS和JavaScript技術來生成本地apps的解決方案。web代碼和其實現本地功能所需要的庫文件被一起打包到本地app shell中。Apps使用web語言編寫，能夠訪問設備上的webView組件（一種“chromeless”瀏覽器組件）以及JavaScript API擴展，JavaScript API擴展使得app能夠使用通知、加速器、指南針、連接性、地理位置以及文件系統這樣的平臺功能，這些都是超乎瀏覽器通常所能提供的。
web-to-native框架主要有PhoneGap，Uxebu’s Apparat.io以及Sencha v2，Sencha v2還將這種包裝功能引進到JavaScript框架中來。另外一個例子就是MoSync Wormhole，它可以提供比PhoneGap更強大的API功能集。web-to-native框架針對這樣一類web開發人員，他們需要將web apps轉換為本地apps并通過app商店進行分銷、訪問本地設備功能或者做一些優化工作。
Runtimes：運行時是本地操作系統之上的一種執行環境以及跨平臺兼容層。運行時從本質上來說屏蔽了app在不同底層平臺上的差異。不同的運行時有不同的大小和復雜性，并且使用不同的方法在設備上面執行代碼，例如虛擬化，解釋，及時編譯或者提前編譯。
Java ME，BREW，Flash Lite和Openwave MIDAS都是早期運行時的先驅。這些重量級的執行環境似乎介于瀏覽器和完整的操作系統之間。但這些工具在2009年前后就不再流行，原因是：開發者感覺很痛苦（平臺分散、無直接市場渠道）；缺乏手機制造商的合作（集成復雜度）；與Aandriod、iOS、HTML5瀏覽器的競爭。
現在的跨平臺運行時將設備軟件層的復雜性轉移到了設計階段的開發工具中來。通常來講，跨平臺翻譯部分發生在設計階段（翻譯成進制代碼），部分發生在運行時（執行進制代碼）。流行的運行時有Appcelerator，Adobe Flex，Corona，AppMobi，Antix和Unity等。運行時針對這樣一些軟件開發人員，他們需要更寬泛的跨（本地）平臺或者跨屏幕（手機，電腦，游戲，電視等）功能。
Source code translators：源代碼翻譯器解決方案將源碼交叉編譯成中間字節碼，本地語言（如C++，Objective-C，JavaScript）或者直接轉化為更低級的機器碼（如匯編語言）。源代碼翻譯器通常和運行時元素結合在一起使用。
舉個例子來說，Metismo（現在的AG軟件）將J2ME應用程序轉換為C++，ActionScript和JavaScript，然后編譯成能在ARM，MIPS，PowerPC和x86設備上執行的代碼。類似的，Eqela將一個使用類C語言編寫的app翻譯成目標平臺可運行的中間碼，例如在web瀏覽器上執行的JavaScript，Java，C或者匯編語言。
Haxe/NME結合本地標準庫把類似ActionScript的Haxe(具有類似Flash的API)源代碼轉換成Shockwave或C++代碼。XMLVM使用Java，.NET或者Ruby源碼，這些源碼先被編譯成字節碼，然后再交叉編譯成JavaScript，C++或者Objective C。其他的源代碼翻譯工具有MoSync，Marmalade和Xamarin’s Mono。這些翻譯工具針對的是高級軟件開發人員，他們需要創建邏輯復雜、性能優越的跨平臺apps或者需要對app進行優化。
#p#
跨平臺工具垂直發展
除以上五種技術手段外，跨平臺工具提供商已經開始垂直分化，根據企業，游戲，媒體應用開發者的不同需求，為他們提供不同的解決方案。
企業級應用平臺是跨平臺的開發工具，它支持應用的整個生命周期（開發->集成->發布->管理），它具有數據連接器、中間件、云服務（如：應用托管、策略管理、信息推送等）。很多這樣的平臺是面向企業的，而不是面向消費者的應用。比較著名的移動應用開發平臺有：Worklight, Kony, Antenna Mobility Platform, Application Craft, RhoMobile 以及Verivo等。
游戲開發工具是專門針對游戲開發者的完整的開發環境。游戲引擎是更為重量級的運行時組件；通常是由低級語言（如：C++語言）與用于編寫游戲邏輯部分的腳本語言（如：Lua語言）相結合。Unreal 和Unity在高端3D游戲市場完全處于領先地位。他們提供了一系列的集成開發工具、工作流及協作管理工具。在類似的游戲工具市場上，還有Moai, SiO2, Antix 和 Shiva3D等。雖然Marmalade 和 Corona支持更多的功能（如：支持本機UI元素），但是它們畢竟還是由一個舊版的游戲引擎發展而來的。也有一些像GameSalad這樣的稍微輕量級的游戲工具，GameSalad被稱為“游戲締造者”，它將app工廠提供的無須編碼方法和游戲引擎工具結合在一起。像Impact JS 和 Lime JS 這樣的輕量級JavaScript庫被認為是HTML5的游戲框架。
The next table lists over 50 cross-platform tools by technology approach, authoring language and deployment format (web vs. native).
下表列出了50多種跨平臺工具，從技術方法、開發語言及部署格式方面（網絡或本機）進行了展示。
跨平臺工具總表：我們的研究所關注的100種跨平臺工具總表如下。
#p#
部署格式：Web還是本機？
是用web瀏覽器來部署移動應用程序還是創建本機應用？這是令許多開發人員長期困擾的問題。Web apps 具有廣闊的市場前景，但只能在網絡上部署，并且相對于本地apps的用戶體驗也不是那么好，本地apps具有更好的設備集成度并提供更優秀的用戶體驗，但是不能跨平臺，其潛在市場只能限定于特定平臺內。
使用跨平臺工具可使這些區別模糊不清，Web程序員可以通過工具（如著名的Appcelerator）來開發本機應用程序。Web開發者可以使用諸如PhoneGap這樣的Web-to-native框架在瀏覽器中動態調用本機設備的功能。
但是本機與web問題在部署時還是存在的。無論是web app還是本機應用，在分銷渠道（網站或應用程序商店）和經驗積累（膚淺或深入）上都會有很大的不同。
HTML5的確增強了web瀏覽器的功能，例如：允許精確的可視化布局（畫布元素）和對視頻、持久存儲、地理定位、訪問聯系人名單、傳感器和SQL數據庫訪問的固有支持。同時，由于各瀏覽器實現HTML規范的方式是不同的，web程序員必須對由此帶來的巨大差異進行處理。在所有的移動瀏覽器當中，遵循HTML5規范方面做得最好的是Firefox Mobile，獲得了最高分10分，緊隨其后的是蘋果的iOS5平臺。與之相對的另一極端是Windows Phone7.5瀏覽器，它對HTML5規范的遵循程度大約只有蘋果的一半。桌面瀏覽器和電視瀏覽器在對HTML5規范的遵循程度方面，也存在同樣的多樣化和兩極化現象。上面的圖表是移動平臺對HTML5瀏覽器規范的遵循程度的得分情況。
這種“遵約分化”現象導致的后果是：web應用開發者為了使他們的應用能在各主流智能手機平臺上實現最優運行，他們需要耗費大量的開發時間以及昂貴的成本。最典型的例子是“金融時報”廣受歡迎的HTML5應用的開發商Assanka，該公司花了24人月來開發iPad平臺上的HTML5應用—新聞閱讀器（news reader），又花了12個月把這一應用移植到Android平臺。
Web Hybrid apps彌補不足
開發人員應該選擇web還是本地apps? 混合app方法致力于結合web和本地apps兩者的優點。像PhoneGap，BKRender，Sencha v2， Worklight和Appcelerator等許多跨平臺工具已經可以進行混合apps開發。
從用戶的觀點來看，混合apps跟本地apps很相似，人們可以通過本地平臺app stores來尋找下載混合apps，同時使用相似的過程來安裝混合apps。安裝完成之后，混合apps可以從iOS這樣的主屏幕或者從Android這樣的app抽屜(drawer)中啟動，并且經常可以在不需要數據連接的情況下正常運行。
從開發人員的角度來講，開發混合apps和開發本地apps的工作流很相似，只有一點不同的是，開發人員可以使用HTML，CSS和JavaScript來編寫混合apps的某些部分。由于混合app開發模型在所有主流移動平臺上得到支持，使得不同平臺版本的app可以復用HTML，CSS和JavaScript代碼。
混合apps由一個包含HTML，CSS和JavaScript的本地代碼shell（或者說是一個包裝器）組成。當一個混合app運行在一臺設備上，該包裝器就會啟動一個web視圖的實例，同時加載其中的HTML，CSS和JavaScript代碼。該web視圖實例通常是“chromeless”，即它沒有web瀏覽器控件，因此使得混合app看起來類似一個本地app。
下面的表格從技術和商業角度比較了本地，混合以及web app方法的異同。就像表格所顯示地那樣，混合apps將本地apps的特性和pure web apps的特性結合了起來。
容易發現和獲取：用戶可以像找本地apps一樣找到他們需要的混合apps。為了支持多個移動平臺的用戶，需要開發不同版本的app。
更好的用戶體驗：混合apps提供良好的用戶體驗。他們允許HTML代碼訪問本地APIs（以此來提供更豐富的用戶體驗），當然這是以非本地UI為代價的，因為這涉及到web技術。
用戶所有權和條款：就用戶所有權和條款來講，混合apps和本地apps完全一樣。開發人員通過本地平臺app stores來和客戶進行交易，并且必須遵守app store強加的包括準許政策在內的各種條款和約束。
迎合用戶：由于混合apps安裝在設備上，并且顯示在主屏幕或者app抽屜上面，他們在留住用戶和重復使用方面和本地apps是完全一樣的。用戶可以像啟動（launch）本地apps一樣來啟動混合apps，而不用去記住任何URLs，或者像pure web apps一樣在主屏幕上顯式生成一個捷徑。
盈利模式：混合apps的開發者可以和本地apps開發者一樣通過相同的方式盈利，這里面包括下載后付款或者應用程序內支付。
最后，對于一些UI信息豐富的app,混合apps允許顯著的UI資源共享并且易于web開發。然而就像上面圖表顯示的那樣, 在不同的移動平臺上web瀏覽器的實現都千差萬別。結果，充分使用web瀏覽器功能的高級apps需要自適應來完全支持不同平臺的移動瀏覽器。
我該使用哪個工具？
我們追蹤調查過超過100個跨平臺開發工具，他們都各不相同。如果避開他們支持的編程語言和目標平臺不談，我們可以發現使用跨平臺開發工具開發的app有一些收斂的類別（a convergence in the categories of apps）。開發者調查報告顯示，如果不考慮主要的開發工具的話，35%的調查對象認為企業級apps是其首選。生產力，游戲，教育/參考和實用工具排名前五。
與此同時，這些開發工具不能被化為到具體的app類別中來，當然開發人員在決定使用哪個跨平臺工具之前，應該考慮他們的應用背景以及需要。下面這個表格提供了一些指導意見。
原文鏈接：http://www.webapptrend.com/2012/05/2952.html
【編輯推薦】
