【51CTO.com快譯】移動應(yīng)用的開發(fā)方式多種多樣。雖然從技術(shù)層面了解混合與原生應(yīng)用間的區(qū)別非常重要，但更重要的仍然是立足業(yè)務(wù)層面思考具體決策會給開發(fā)團隊及客戶帶來哪些影響。事實上，混合與原生之爭久已有之，且雙方在使用體驗、技術(shù)、投資回報以及業(yè)務(wù)影響等層面皆各擅勝場。在本文中，我們將著眼于其中最重要的幾項因素。

[[183307]]

原生應(yīng)用

原生應(yīng)用即利用特定平臺技術(shù)開發(fā)而成的應(yīng)用（例如iOS上的Objective-C或Swift，以及Android上的Java）。原生應(yīng)用能夠充分發(fā)揮平臺的既有優(yōu)勢。

原生移動應(yīng)用的優(yōu)勢與缺點

優(yōu)勢

性能更好。由非標(biāo)準(zhǔn)語言及工具開發(fā)而成的原生應(yīng)用采用原生抽象層以提升運行速度，且實際速度由應(yīng)用選擇的具體抽象層效率決定。即使是非標(biāo)準(zhǔn)原生應(yīng)用，其性能也遠遠超過Web應(yīng)用，這是因為后者必須在瀏覽器內(nèi)執(zhí)行，這會增加額外的執(zhí)行重定向?qū)印Ｒ虼?，原生?yīng)用擁有更出色的用戶體驗及更強的應(yīng)用功能（特別是與手機硬件相關(guān)的功能）。研究顯示，兩秒的延遲就足以令相當(dāng)一部分用戶選擇棄用。Facebook與領(lǐng)英曾利用HTML 5開發(fā)混合型應(yīng)用，但雙方最終還是被迫轉(zhuǎn)向原生應(yīng)用以解決性能問題。

用戶體驗。原生移動應(yīng)用的另一大優(yōu)勢在于用戶體驗。原生應(yīng)用在外觀與使用感受上類似于默認內(nèi)置應(yīng)用，且用戶能夠很快了解如何使用應(yīng)用并進行導(dǎo)航。不過原生應(yīng)用必須與系統(tǒng)升級進行匹配，否則外觀上的不協(xié)調(diào)感與運行穩(wěn)定性差等問題反而會令用戶更加無法忍受。

應(yīng)用商店推廣。另外，原生應(yīng)用與混合應(yīng)用的另一大區(qū)別在于，原生應(yīng)用更易在應(yīng)用商店當(dāng)中進行推廣。

缺點

資源與成本。要為Android與iOS開發(fā)應(yīng)用，大家必須分別建立兩支開發(fā)團隊并面對兩套獨立的代碼庫。這意味著開發(fā)成本更高且長期維護支出更可觀。因此，如果預(yù)算充足且對投資回報率要求不高，那么原生應(yīng)用顯然更具優(yōu)勢。

混合移動應(yīng)用

所有現(xiàn)代移動應(yīng)用都可被劃分為三種基本類型：原生、混合與Web。每一種都有著自己的優(yōu)勢與缺點。原生應(yīng)用能夠充分發(fā)揮設(shè)備功能，但Web應(yīng)用的開發(fā)成本與時間周期則更友好。作為二者的結(jié)合體，大家可以面向多種平臺使用同一套代碼庫并開發(fā)出類似于原生效果的應(yīng)用，這就是混合應(yīng)用。

混合移動應(yīng)用的優(yōu)勢與缺點

優(yōu)勢

要求較低。混合應(yīng)用能夠?qū)TML 5應(yīng)用嵌入至瘦原生容器當(dāng)中，從而將原生與HTMl 5元素加以結(jié)合。開發(fā)者能夠利用原生SDK增強Web代碼，從而保證其在多種平臺上輕松部署。

成本。混合移動的開發(fā)成本通常較低。一旦開發(fā)完成，大家無需額外投入即可將其同時運行在Android與iOS系統(tǒng)之上。利用混合應(yīng)用，除非企業(yè)需要向其中添加能夠顯著改變用戶體驗的新型功能，否則用戶將不需要在應(yīng)用商店內(nèi)進行應(yīng)用更新。而只要在服務(wù)器端對對應(yīng)頁面進行更新，用戶將可立即獲得更新內(nèi)容——企業(yè)選擇混合移動而非原生應(yīng)用的根本原因往往正在于此。

混合移動開發(fā)工作更快且更簡單，而應(yīng)用維護工作的難度亦更低。

舉例來說，假定客戶希望為其供應(yīng)商生命周期管理系統(tǒng)提供一套全新用戶體驗及現(xiàn)代圖形用戶界面。這意味著現(xiàn)有生命周期管理系統(tǒng)必須能夠顯示各類重要信息，且應(yīng)用本身應(yīng)能夠輕松訪問***供應(yīng)商信息并為采購者提供分組數(shù)據(jù)。另外，應(yīng)用還應(yīng)整合交互式設(shè)計、實用性改進以及可訪問性與性能水平等因素。在這種情況下，理想的選擇是利用HTML 5面向iOS開發(fā)混合應(yīng)用——客戶將能夠順利將此應(yīng)用整合至原有移動應(yīng)用平臺當(dāng)中，且混合特性亦使得應(yīng)用本身更易于遷移。

缺點

功能訪問。如果您的應(yīng)用高度依賴于原生功能，那么原生應(yīng)用無疑是***選項。在構(gòu)建混合應(yīng)用時，您所采用的框架可能導(dǎo)致無法訪問全部本機功能，具體包括相機、聯(lián)系人、短信、硬件設(shè)備按鈕、地圖、推送通知等。當(dāng)然，也有一些框架能夠在混合應(yīng)用中實現(xiàn)一部分本機功能組件。

第三種選項

考慮到以上情況，Xamarin、Codename One及Rem Objects等能夠?qū)⒃c混合應(yīng)用開發(fā)共性加以融合的平臺就變得非常重要?？傮w來講，Xamarin允許開發(fā)者使用C#作為惟一語言配合惟一IDE（可以是Visual Studio或者Xamarin Studio）完成面向蘋果、Android乃至Windows設(shè)備的原生應(yīng)用開發(fā)工作。

 遺憾的是，Xamarin平臺存在著一大致命問題，其無法在應(yīng)用中添加大量復(fù)雜的圖像與動畫。

總結(jié)：

總而言之，業(yè)務(wù)需求是決定您選擇的核心條件。在大多數(shù)情況下，原生應(yīng)用的效果通常更好。但如果您希望構(gòu)建媒體網(wǎng)站/內(nèi)容交付平臺，那么混合應(yīng)用也許同樣值得考慮。另外，也別忘記將Xamarin等平臺納入考量范圍。

原文標(biāo)題：Hybrid vs Native Mobile Аpp Development: Where to Begin?

原文作者：Stephen Channer

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】