Hybrid APP基礎篇(一)->什麼是Hybrid App
Hybrid APP基礎篇(一)->什麼是Hybrid App
最新更新
一個開源的快速混合開發框架：https://github.com/quickhybrid/quickhybrid
Android、iOS、JS三端內容初步都已經完成，有完善的設計思路、教程以及API文檔。
說明
Hybrid APP是目前廣泛流行的一種APP開發模式,本文對其做簡單介紹
目錄
前言
參考來源
前人栽樹,後臺乘涼,本文參考了以下來源
- HTML5 APP----2014年H5沒火，why？2016年H5能火，why？
- 淺談Hybrid技術的設計與實現
- HybridApp解決方案_No1_混合模式(Hybrid)App開發概述
- 你真的瞭解Hybrid APP嗎
- 2016最新安卓版本分佈
- hybrid app
楔子
現在概念上的APP誕生是在Google推出Android,Apple推出iOS後,從這時候開始,就有了App開發工程師這個職位,比如Android工程師,iOS工程師(當然了,一些被歷史淘汰的,比如Symbian,win phone就暫不算進來了)
最開的App開發只有原生開發這個概念,但自從H5廣泛流行後,一種效率更高的開發模式Hybrid應運而生,它就是"Hybrid模式",本文針對這種模式做簡單介紹
Hybrid發家史
突然興盛的H5
Html5是在2014年9月份正式發佈的,這一次的發佈做了一個最大的改變就是-"從以前的XML子集升級成爲一個獨立集合",也就是說,HTML5和之前的HTML是有很大區別的,這次自己不再是某門派的弟子傳人了,而是成爲了開宗立派的祖師爺
子Html5發佈開始,就慢慢開始掀起了一股H5狂潮,比如"微信朋友圈小遊戲","圍住神經貓"之類的,但是真正HTML5大火之際,應該算是2015之後了,爲什麼,首先我們來看下谷歌公佈的2015年2月份的Android系統版本分佈情況
從上圖中我們可以看到Android4.0以上的市場佔有率已經接近90%,特別是4.4以上的比重已經超過40%了,也就是說,我們這時候開發就已經幾乎可以不考慮4.0以下的系統了,而4.0以上H5的支持是要遠遠高於4.0以下的。所以這時候就可以使用H5技術了
H5大行其道
我們先看下谷歌2016年4月份公佈的Android系統佔有率
我們可以看到,幾乎所有的設備都是4.0以上了,而且4.4以上已經超過70%,特別是5.0以上都已經超過40%了,而Android 4.4以上對H5的支持就已經很不錯了,所以我們幾乎以及可以肆無忌憚的使用H5了
H5滲入APP開發
我們都知道,原生APP開發中有一個webview的組件(Android中是webview,iOS7以下有UIWebview,7以上有WKWebview),這個組件可以加載Html文件。
在Html5沒有興盛之前,加載的Html往往只能用來做一些簡單的靜態資源顯示,但是H5大行其道以後,Html5中有很多新增的功能,炫酷的效果,特別是iOS中H5支持一直都很良好,Android 4.4以上支持也足夠,所以這時候發現可以將一些主要的邏輯都用H5頁面來編寫,然後原生直接用webview加載顯示,這樣大大提高了開發效率,而且體驗也很不錯
Hybrid的興盛
所謂Hybrid,即混合開發,意味着半原生半Web,其實在H5興盛之前,Hybrid模式就已經比較成熟了,但是一直不慍不火(因爲系統的一些現在以及html本身功能的限制)
但是自從H5興盛之後,大家發現原來很多功能都可以用web來實現,然後原生作爲容器顯示,所以爲了提高開發效率,越來越多的人使用Hybrid模式進行開發,越來越多的Hybrid開發框架,越來越多的前端專職成爲Hybrid開發,也就是說Hybrid也隨之興盛起來了
Hybrid概述
Hybrid定義
前面有提到Hybrid這種模式,那麼它是怎麼樣定義的呢？怎麼樣的開發模式纔算是Hybrid模式呢?
- Hybrid是半Native半web開發模式
Hybrid模式中,底層功能API均由原生容器通過某種方式提供,然後業務邏輯由H5頁面完成,最終原生容器加載H5頁面,完成整個App
- 成熟的Hybrid模式意味着業務邏輯均由H5實現
一款成熟的Hybrid框架,意味着各種類型的api都很完善,那麼這時候幾乎所有與業務相關的邏輯都是放在H5頁面中的,原生只作爲容器存在
- 成熟的Hybrid模式可複用性非常高,可以跨平臺開發
成熟的Hybrid框架,那麼原生只會提供底層API,也就是說所有的業務是H5完成,不管是什麼項目,業務只由H5實現,這時候就可以發現,業務代碼是可以跨平臺的,也就是說,開發一次,就可以和各自原生容器結合,組成兩種原生安裝包了,達到了跨平臺開發效果
Hybrid App的類型劃分
上面提到過Hybrid的定義,但實際上,根據Native和web的混合程度,Hybrid也可以再次細分爲多種類型(參考百科上的說法)
- 多View混合型
這種模式主要特點是將webview作爲Native中的一個view組件,當需要的時候在獨立運行顯示,也就是說主體是Native,web技術只是起來一些補充作用
這種模式幾乎就是原生開發,沒有降低什麼難度,到了16年幾乎已經沒人使用了
- 單View混合型
這種模式是在同一個view內,同時包括Native view和webview(互相之間是層疊的關係),比如一些應用會用H5來加載百度地圖作爲整個頁面的主體內容,然後再webview之上覆蓋一些原生的view,比如搜索什麼的
這種模式開發完成後體驗較好,但是開發成本較大,一般適合一些原生人員使用
- Web主體型
這種模式算是傳統意義上的Hybrid開發,很多Hybrid框架都是基於這種模式的,比如PhoneGap,AppCan,Html5+等
這種模式的一個最大特點是,Hybrid框架已經提供各種api,打包工具,調試工具,然後實際開發時不會使用到任何原生技術,實際上只會使用H5和js來編寫,然後js可以調用原生提供的api來實現一些拓展功能。往往程序從入口頁面,到每一個功能都是h5和js完成的
理論上來說,這種模式應該是最佳的一種模式(因爲用H5和js編寫最爲快速,能夠調用原生api,功能夠完善),但是由於一些webview自身的限制,導致了這種模式在性能上損耗不小,包括在一些內存控制上的不足,所以導致體驗要遜色於原生不少
當然了,如果能解決體驗差問題,這種模式應當是最優的(比如由於iOS對H5支持很好,iOS上的體驗就很不錯)
- 多主體共存型（靈活型）
這種模式的存在是爲了解決web主體型的不足,這種模式的一個最大特點是,原生開發和h5開發共存,也就是說,對於一些性能要求很高的頁面模塊,用原生來完成,對於一些通用型模塊,用h5和js來完成
這種模式通用有跨平臺特性,而且用戶體驗號,性能高,不遜色與原生,但是有一個很大的限制就是,採用這種模式需要一定的技術前提
也就是說這種模式不同於web主體型可以直接用第三方框架,這種模式一般是一些有技術支持的公司自己實現的,包括H5和原生的通信,原生API提供,容器的一些處理全部由原生人員來完成,所以說,使用這種技術的前提是得有專業的原生人員(包括Android,iOS)以及業務開發人員(原生開發負責功能,前端解決簡單通用h5功能)
當然了,如果技術上沒有問題,用這種方案開發出來的App體驗是很好的,而且性能也不遜色原生,所以是一種很優的方案
Hybrid架構
基本原理
如下圖,痛過JSBridge,H5頁面可以調用Native的api,Native也可調用H5頁面的方法或者通知H5頁面回調
內部的實現原理流程
知道了Hybrid的基本原理,那麼Hybrid模式內部是如何實現的呢?H5和Native直接的通信又是如何實現的呢?
請參考 後續系列文章
Hybrid的未來
現行多種App開發模式以及分析比較
現在的App開發,除了Hybrid,還有Native,純web,React Native等方案,下面介紹下各種方案的分析對比
參考 Native、Hybrid、React Native、Web App方案的分析比較
Hybrid面臨的挑戰
比如Facebook推出的React Native方案,這是Facebook在放棄h5後自行推出一個'反H5方案',一句話總結就是:裏面可以用JS來完整的寫一個原生應用
比如微信推出的小程序(16年9月份內測),這也是一個微信主導的'反H5方案',一句話總結就是:裏面可以同JS+微信自制的UI方案來寫一個類似於原生的應用,只不過這個應用不是發佈到App Store中,而是發佈到微信中
像以上技術都不斷的在衝擊着Hybrid模式(當然Native也會有影響),不過都很推崇JS(話說很多前端猿一直希望JS一統天下)
到現在爲止,2016年已經快過去了,新的技術也不斷的在涌出,各類的新技術都不斷的在衝擊着Hybrid模式的地位,正如一句話"長江後浪拍前浪,前浪*****",任何技術都會被時間無情的篩選,請不要奇怪,也許不久後的某天,你會突然發現Hybrid模式已經完全落伍了。