【51CTO獨家譯文】本白皮書的目的不是確定哪一種是***的開發方法，因為不存在***的開發方法，而是列出每一種方法的優缺點，并描述最適合某一種開發方法的不同場景或企業需求。英文白皮書可以在微盤上下載：http://vdisk.weibo.com/s/6ru7u/1338949809

[[78303]]

以下為全部譯文：

開發方法介紹

一、Native App

Native App含有二進制可執行文件，直接下載到設備上，并存儲在本地。安裝過程由用戶啟動；在一些情況下，由企業的IT部門啟動。下載Native App的最常見方法是訪問應用程序商店，如蘋果的應用程序商店、安卓的應用程序市場或黑莓的應用程序世界；但是還有其他方法，有時由移動開發商來提供。

一旦應用程序安裝到了設備上，用戶可以如同啟動設備提供的其他任何服務那樣啟動應用程序。一旦完成初始化，Native App就直接與移動操作系統進行聯系，不用通過任何中介或容器。Native App可隨意訪問由操作系統開發商提供的所有應用編程接口（API）；在許多情況下，NativeApp有著某種特定的移動操作系統所常見的獨特外觀和感覺。

想創建Native App，開發者必須編寫源代碼（采用人類可讀的形式），并建立額外資源，比如鏡像、音頻段和針對特定操作系統的各種聲明文件。使用由操作系統開發商提供的工具，對源代碼進行編譯（有時還要進行鏈接），目的是為了建立一個二進制形式的可執行文件，它可以連同其余資源封裝起來，并隨時可供分發。

這些工具以及其他實用程序和文件通常名為移動操作系統的軟件開發工具包（SDK）。雖然不同操作系統上進行的開發過程常常很相似，但是SDK視特定的平臺而定，每一種移動操作系統都隨帶各自的獨特工具。下面這張表顯示了與四大移動操作系統有關的不同工具、語言、格式和分發渠道。

平臺之間的這些區別導致了Native開發方法的最重大缺點之一：為一種移動平臺編寫的代碼無法在另一種平臺上使用；這樣一來，為多種操作系統開發和維護Native App成了一項時間很長、成本很高的任務。

那么，為什么盡管存在成本高昂的這個缺點，許多公司還是選擇Native開發這條路呢？為了回答這個問題，我們就要更清楚地了解API的角色。

應用編程接口（API）

一旦Native App安裝到了移動設備上，并由用戶啟動，它就能借助操作系統公開的專有API調用，與移動操作系統進行聯系。這些API可以分為兩大類：低級API和高級API。

低級API

正是借助這些低級API調用，應用程序能直接與觸摸屏或鍵盤進行聯系、渲染圖形、連接至網絡、處理從麥克風收到的音頻、通過揚聲器或麥克風播放聲音，或者接收來自攝像頭的圖像或視頻。應用程序能訪問全球定位系統（GPS）、接收方位信息，當然還可以讀寫固態硬盤上的文件，或者訪問現有和將來會有的其他任何硬件元件。

高級API

除了提供我們剛才提到的低級硬件訪問服務外，移動操作系統還提供對個人移動體驗來說很重要的較高級服務。這類服務包括瀏覽Web，管理日歷、聯系人資料和相冊等過程，當然還包括打電話或收發文本消息的功能。

雖然大多數移動操作系統包含一組內置的應用程序可以執行這些服務，但是還讓Native App可以訪問一組公開的高級API，讓它們可以訪問上述許多重要的服務。其他API讓可下載式應用程序可以訪問操作系統開發商提供的各種基于云的服務，比如推送通知（Push Notifications）或應用程序內購買（In-App Purchase）等服務。

GUI工具包

操作系統提供的另一組重要的API是GUI工具包。每一種移動操作系統都隨帶各自的一組用戶界面組件，比如按鈕、輸入區、滑塊、菜單、菜單欄、對話框及其他。可以使用這些組件的應用程序繼承了該特定移動操作系統的外觀和感覺，通常會帶來非常流暢的用戶體驗。

值得一提的是，不同的移動平臺帶有一系列獨特的用戶界面組件。因而，為了可在多種操作系統上運行而設計的應用程序需要設計者熟悉每一種操作系統不同的用戶界面組件。

雖然API視特定的操作系統而定，并且給開發諸多Native App的工作大大增添了復雜性和成本，但是這些元素只是創建豐富移動應用程序的手段而已，這些應用程序可以充分利用現代移動設備所提供的全部功能。#p#

二、移動Web App

現代移動設備包含功能強大的瀏覽器，這些瀏覽器支持許多新的HTML5功能、CSS3和高級JavaScript。由于最近在這方面取得的進展，HTML5預示著這項技術將從一種“頁面定義語言”，轉變成一種功能強大的開發標準，用于開發豐富的、基于瀏覽器的應用程序。

表明HTML5大有潛力的幾個例子包括：高級的用戶界面組件、可以訪問豐富媒體類型、地理位置服務和離線功能。使用這些特性和處于開發中的其他更多特性，開發者就能僅僅使用Web技術，開發出高級應用程序。

不妨先來區別一下兩種極端的Web App開發方法。我們都熟悉移動瀏覽和針對移動設備優化的網站。這些網站能夠識別何時被智能手機訪問，因而呈現為了在小尺寸屏幕上提供舒適的“觸摸體驗”設計的HTML網頁。但是有些公司更進一步，建立了移動網站，以改善用戶體驗。這種移動網站看起來就像Native App，可通過快捷方式來啟動，這與啟動Native App的方式沒什么不同。

這兩個極端之間存在一系列廣泛的可能性，大多數網站實施了各自的Hybrid特性。

移動Web App是一種很有希望的趨勢。為了緊緊抓住這個趨勢，幫助開發者構建客戶端用戶界面，已開發出越來越多的JavaScript工具包，比如Sencha Touch和jQuery Mobile，它們創建的用戶界面在外觀和感覺上與Native App大同小異。兩者都完全在移動設備的瀏覽器里面執行，充分利用了現代移動瀏覽器所提供的***JavaScript、CSS和HTML5特性。

Web App最突出的優勢之一是，它支持多種平臺，而且開發成本低。大多數移動開發商利用了瀏覽器中的同一種渲染引擎：WebKit——主要由谷歌和蘋果領導的這個開源項目提供了如今最全面的HTML5實現機制。由于應用程序的代碼用與WebKit兼容的標準Web語言編寫而成，所以一個應用程序在諸多不同的設備和操作系統上提供了統一的體驗，因而使得它在默認情況下支持多種平臺。但是這些優勢并非沒有代價。盡管移動領域的Web技術大有潛力和希望，但它們仍存在相當大的局限性。為了解這些局限性，我們就要解釋Web App是如何運行的。

不像Native App是獨立的可執行文件，直接與操作系統進行聯系，Web App則在瀏覽器里面運行。而瀏覽器本身是可直接訪問操作系統API的一種Native App，但是只有數量有限的這些API向瀏覽器里面運行的Web App公開。雖然Native App可以完全訪問設備，但是許多特性只是部分可供Web App使用，或者根本不可使用。雖然預計這種情況在將來會隨著HTML的改進而改變，但是如今的移動用戶無法使用這些功能。#p#

三、Hybrid App

Hybrid開發方法結合了Native開發和Web技術。借助這種方法，開發者就能使用跨平臺Web技術，開發應用程序的大部分代碼，又可以在需要時直接訪問Native API。

App的Native代碼部分使用操作系統的API來創建嵌入式HTML渲染引擎，該引擎在瀏覽器和設備的API之間充當了橋梁。這座橋梁讓Hybrid App得以充分利用現代設備所提供的全部特性。

App開發者可以選擇編寫自己的橋梁，或者充分利用現成的解決方案，比如PhoneGap——這種開源庫為有選擇的設備功能提供了在諸操作系統上保持一致的統一JavaScript接口。

App的Native代碼部分可以獨立開發，但是市場上的一些解決方案把這種類型的Native容器作為其產品的一部分來提供，因而讓開發者有辦法只要使用Web語言，就可以構建利用設備所有特性的高級App。在一些情況下，解決方案讓開發者可以充分利用現已掌握的任何Native開發技能，根據企業的獨特要求來定制Native容器。

App的Web部分可能是駐留在服務器上的網頁，也可能是一組HTML、JavaScript、CSS和媒體文件，封裝到App代碼中，存儲在設備本地。這兩種方法都有其優勢和局限性。放置在服務器上的HTML代碼讓開發者不必經歷提交和批準過程——有些App商店要求這個過程，就可以對App進行小幅更新。遺憾的是，這個方法擯棄了任何離線可用性，因為設備與網絡沒有連接時，無法訪問設備。另一方面，把Web代碼封裝到App里面可以提高性能和可訪問性，但是不允許遠程更新。如果結合這兩種開發方法，也許可以集兩者之所長。這種系統采用的架構可以把HTML資源放置在Web服務器上，以獲得靈活性，但是又把它們本地緩存在移動設備上，以獲得高性能。

比較不同的開發方法

所以為了總結，不妨看一下這三種開發方法各自相比怎么樣。

 Native開發方法在性能和設備訪問方面很出色，但成本和更新方面有缺點。Web方法更新起來簡單得多，成本較低，也更容易，但是目前功能有限，也無法獲得使用Native API調用所能獲得的那種出色的用戶體驗。Hybrid開發方法提供了折中方案：在許多情況下，它集兩者之所長，如果開發者面向多種操作系統更是如此。

從上面這張表可以推斷出，沒有哪一種開發方法總是提供所有的優點。選擇一種合適的方法取決于企業的具體要求，可能取決于諸多因素，比如預算、時間表、內部資源、目標市場、所需的應用程序功能、IT基礎設施及其他許多方面。但是有一點很清楚：如今的大多數公司顯然在兩個方面之間作一取舍：一方面是用戶體驗和應用程序功能，另一方面是開發成本和產品上市時間。問題就變成了選擇一種合適的開發方法，能兼顧企業的要求和其在預算和產品上市時間方面的限制。

選擇合適的開發方法#p#

下面介紹有助于幫助企業選擇合適開發方法的一些場景：

一、Native開發方法的場景

現有的Native開發技能——反對Native開發方法的主要理由之一是，它缺少對多種平臺的支持。要求為多種移動平臺開發App的企業需要招聘新員工，或者對內部開發者進行眾多Native語言方面的培訓。內部擁有這種Native開發技能的企業不需要大筆新的投入，就能夠充分利用這些技能。

單一移動操作系統——在一些情況下，企業旨在向有限的目標群體發布移動App——這個群體已知使用單一移動操作系統。比如說，考慮這種場景：向員工發放黑莓設備的企業分發內部App。在這種情況下，支持多種平臺也許不是優先事項：由于開發單一的Native App只需要一套有限的技能和工具，所以這種方法很有意義。

Native功能——有些App是圍繞某一項功能開發的。就拿Skype來說，VOIP和訪問用戶的聯系人信息是App的兩大關鍵要素；考慮到現有的技術，只能采用Native方法來開發。對這類App而言，Web語言根本不夠完善，根本無力獲得所需的功能。

豐富用戶界面的需求——有些游戲類App需要提供實時響應的豐富用戶界面，對這類App而言，Web技術還無法提供足夠有效的解決方案。對有這類需求的App而言，開發者采用Native開發方法仍然比較好。

二、Web開發方法的場景

直接分發——有些企業更喜歡以一種內部控制的方式來分發App，他們不喜歡受制于有時很漫長、很不確定的審批過程。這種情況下，使用純粹的Web語言可以完全規開應用商店的審批過程，讓企業可以完全控制App的定期更新和分發。

試點App——比較Native App與Web App開發所需的成本和上市時間時，使用Web方法開發試點應用程序是一種引人入勝的、經濟高效的方法。一旦概念得到了證明，企業可以決定從頭開始創建新的App，或者充分利用Hybrid App中的部分現有代碼。

可視性——除了前面提到的分發外，構建Web App的另一個優點是搜索引擎結果具有可視性；在許多情況下，搜索引擎結果將App展示給比僅僅通過應用商店獲得的群體更龐大的群體。

三、Hybrid開發方法的場景

折衷考慮——如果企業使用Hybrid開發方法，就能集兩者之所長。一方面，Native讓開發者可以充分利用現代移動設備所提供的全部不同的特性和功能。另一方面，使用Web語言編寫的所有代碼都可以在不同的移動平臺之間共享，使得開發和日常維護過程變得集中式、更簡短、更經濟高效。

內部技能——Web開發技能十分常見，許多企業都擁有這類技能。如果選擇Hybrid開發方法，在合適解決方案的支持下，Web開發者只要僅僅運用HTML、CSS和JavaScript等Web技能，就能構建App，同時提供Native用戶體驗。

考慮未來——HTML5的可用性和功能都在迅速改進。許多分析師預測，它可能會成為開發前端App的默認技術。如果用HTML來編寫App的大部分代碼，并且只有在需要時才使用Native代碼，公司就能確保他們今天的投入在明天不會變得過時，因為HTML功能變得更豐富，可以滿足現代企業一系列更廣泛的移動要求。

總結

由于移動App繼續在商業界扮演核心角色，全球各地的企業為越來越多的關鍵任務服務賦予移動特性。許多公司正在力求找到***的開發方法來實現目標，但是許多公司很快認識到：每一種開發方法有天生的局限性，沒有哪一種方法能夠滿足現代移動企業的所有要求、應對復雜情況。

正如本白皮書試圖表明的那樣，答案不在于使用哪一種開發方法，而在于使用靈活的解決方案；這種解決方案能利用各種方法提供的優點，不僅支持首款移動App的開發，還支持將來所有的App，不管他們采用哪種開發方法。

但是Hybrid、Native和Web之間的選擇不是唯一的選擇，盡管無疑是重大的選擇。制定移動戰略的公司還必須考慮這個市場的未來：

• 移動設備和技術的進一步分散，這反過來會繼續增加與移動App開發、集成和日常管理有關的總體成本和復雜性。
• 消費者和企業內部加快采用移動技術，從而提高了安全性、擴展性和日常控制等方面的需求；
• 新的設備特性和補充技術（如近場通信、地理位置、增強現實、社交網絡及其他技術）無疑會帶來移動應用程序的新類型和新用例。
• 新的App分發渠道（包括公共和私有渠道）讓企業很容易把應用程序交到用戶手上，迅速部署更新版、管理整批App，不需要經歷漫長的提交和審批過程。

如果考慮到所有這些方方面面，公司必須選擇這樣一種解決方案：不僅足夠靈活，可以支持各種類型的App，還能支持將App安全而靈活地集成到IT基礎設施中，并且讓公司可以通過一個集中式界面來監測和控制整批App。

【51CTO譯稿，非經授權謝絕轉載，合作媒體轉載請注明原文出處、作者及51CTO譯者！】