跨平臺 webapp 開發技術之 Hybrid App

前所知的 APP 開發模式有三種：

1. 基於操做系統運行的 APP -> Native App，側重於原生開發，用戶體驗好，須要安裝纔會升級
2. 基於瀏覽器運行的 APP -> Web App，側重於網頁技術實現，跨平臺兼容性好，只要開發人員更新代碼，無需經過安裝升級
3. 基於移動應用引擎 -> Hybrid App，使用H5和JS開發。若是不追求用戶體檢時，這種方式最快也最省錢

下面的圖摘自簡書，是對三種不一樣形態的 APP 的對比：

 

 

Hybrid APP是目前普遍流行的一種APP開發模式，Android、iOS、JS三端內容初步都已經完成，有完善的設計思路、教程以及API文檔。

 

Hybrid App，這種既有跨平臺開發週期短、成本低的基因，又能發揮Native App體驗和性能的優點，HybridApp混合式移動應用開發逐漸成爲企業移動開發的首選。
Hybrid App一般是基於第三方跨平臺移動應用引擎框架進行開發：

在國內開發者中比較知名的有PhoneGap、Titanium和AppCan這些引擎框架通常使用HTML5和Javascript做爲編程語言，調用引擎封裝的底層功能如照相機、傳感器、通信錄、二維碼等。HTML5和Javascript只是做爲一種解析語言，真正調用的都是NativeApp同樣封裝的底層功能，這是和Web App的最大區別和不一樣。由於使用了瀏覽器技術，因此Hybrid App一般具備跨平臺的特性，而且開發成本和WebApp接近，開發效率也遠高於Native App。

說實在的，從表面上看的話，很難區分一個App究竟是Native App仍是Hybrid App，但實際上咱們更多的是把Hybrid App當作是Webapp的一部分，由於他是一部分Native（比較少），絕大部分的web頁面（html5頁面）。

Hybrid App和Native App同樣都是須要用戶在各類App分發渠道上下載並安裝到手機上才能用的。Hybrid App的體驗固然是沒話說，比較棒的，有這Native App的所有優勢。html5很好的解決了跨平臺性的問題，也解決了開發成本太高的問題。

 

國內外Hybrid App的開發平臺衆多，目前有三種開發模式：

1. 使用PhoneGap、AppCan之類的中間件，以WebView做爲用戶界面層，以JavaScript做爲基本邏輯，以及和中間件通信，再由中間件訪問底層API的方式，進行應用開發。這種架構通常會很是依賴WebView層的性能。
2. 使用Adobe Air、RubyMotion、Appcelerator或者是Xamarin這種非官方語言的工具，打包成原生應用的方式開發。爲何筆者會將它們定義爲Hybrid App，主要是它們並無很單純地使用原生提供的語言進行開發，而是經過對開發者提供友好的開發工具，並折中地把這種開發語言轉換成原生語言，最終打包出整個應用，因此也屬於混合應用範疇。
3. 在開發原生應用的基礎上，嵌入WebView可是總體的架構使用原生應用提供，通常這樣的開發由Native開發人員和Web前端開發人員組成。Native開發人員會寫好基本的架構以及API讓Web開發人員開發界面以及大部分的渲染。保證到交互設計，以及開發都有一個比較折中的效果出來，優化得好也會有很棒的效果。

國內 Hybrid App 框架，比較多：

dcloud

成立時間：2014年

融資狀況：1200萬人民幣

產品：hbuilder、5+runtime、mui（免費）

集成的原生sdk：經過5＋sdk自行集成

 

phonegap(Cordova)

成立時間：2008年8月

融資狀況：已被adobe收購

產品：phonegap(cordova)

集成的原生sdk：自行集成

產品功能：

PhoneGap是一款國外的開源移動開發平臺。目前已經將核心代碼貢獻給Apache cordova，最新版本是2.6.0，它是基於HTML，CSS和JavaScript的，可使用一些開源的框架好比jQuery Mobile，Dojo Mobile，Sencha Touch等等來提升用戶體驗，也提供了比較豐富的原生插件調用。

缺點：

1. 須要針對相應的平臺環境配置，進行編譯，打包測試，發佈等等。因爲使用Hybrid開發的用戶羣，大部分是web開發者，對原生開發基本不瞭解，這無疑給每個開發者增長了沉重的負擔，須要對各個平臺的開發都要須要瞭解，對硬件等等都要配置，加大開發成本。

2. 使用效果啓動慢，頁面切換響應慢，數據請求慢。調試難度大，內存消耗大。不能徹底跨平臺，不一樣平臺代碼須要微調。

3. 文檔雖比較詳細可是基本是英文，對於國內大部分用戶英文水平較差的是比較大的挑戰。

4. 由於是國外的框架，技術支持不夠到位，出現問題，沒法排解，成爲技術攻關的難點。

側重點：側重於對硬件的訪問控制

 

appcan

成立時間：2010年初

融資狀況：1億元人民幣

產品：公衆版（免費）與企業版（收費）

缺點：

1. 雖然有中文的開發文檔，但描述比較簡單，但願他們豐富他們的API文檔。

2. 免費版本不支持自定義插件（聽說企業版能夠自定義插件）。

3. 暫時只支持iOS，Android兩大平臺，不知道何時推出Windows Phone 8？

4. 許多功能須要企業版才能實現，不過是收費的。

5. AppCan免費版因須要把源代碼上傳到廠商的服務器上打包，對於企業開發來講源代碼泄露安全性上有必定風險。企業版雖然能夠解決，但企業版穩定尚待觀察。

6. AppCan採用封裝的組件，依賴性比較高。不是開源代碼。

7. AppCan 不能很好的解決原生代碼的功能。

 

phonegap與appcan什麼區別？

大概瀏覽了一下appcan的文檔，api設計只能用莫名其妙來形容，各類縮寫，各類看不懂。 

比較表格	Phonegap	AppCan
框架功能	簡單	豐富
支持平臺	大部分平臺	僅4種平臺
開發環境	不一樣平臺須要不一樣開發環境	只需一個IDE包
調試	可直接調試	本地發佈的IOS包，必須部署在越獄的機器上
發佈	在本地能夠直接發佈	必須將代碼上傳至服務器，才能發佈
IOS 簽名管理	本地管理	須要上傳至服務器
代碼泄露風險	低：僅在本地、svn保存代碼	高：需將代碼上傳至appcan服務器

 

 

Hybrid面臨的挑戰

Facebook推出的React Native方案,這是Facebook在放棄h5後自行推出一個'反H5方案',一句話總結就是:裏面能夠用JS來完整的寫一個原生應用。

微信推出的小程序，這也是一個微信主導的'反H5方案',一句話總結就是:裏面能夠同JS+微信自制的UI方案來寫一個相似於原生的應用,只不過這個應用不是發佈到App Store中,而是發佈到微信中。