Hybrid App—Hybrid App開發模式介紹和各類開發模式對比

時間 2020-06-20

標籤 hybrid app 開發模式介紹各類對比欄目 Hybrid 简体版

原文原文鏈接

什麼是Hybrid Appcss

最開的App開發只有原生開發這個概念,但自從H5普遍流行後,一種效率更高的開發模式Hybrid應運而生,它就是"Hybrid模式"html

Hybrid APP是目前普遍流行的一種APP開發模式前端

H5滲入APP開發css3

咱們都知道,原生APP開發中有一個webview的組件(Android中是webview,iOS7如下有UIWebview,7以上有WKWebview),這個組件能夠加載Html文件。web

在Html5沒有興盛以前,加載的Html每每只能用來作一些簡單的靜態資源顯示,可是H5大行其道之後,Html5中有不少新增的功能,炫酷的效果,特別是iOS中H5支持一直都很良好,Android 4.4以上支持也足夠編程

因此這時候發現能夠將一些主要的邏輯都用H5頁面來編寫,而後原生直接用webview加載顯示,這樣大大提升了開發效率,並且體驗也很不錯小程序

Hybrid的興盛微信小程序

所謂Hybrid,即混合開發,意味着半原生半Web,其實在H5興盛以前,Hybrid模式就已經比較成熟了,可是一直不慍不火(由於系統的一些如今以及html自己功能的限制)api

可是自從H5興盛以後,你們發現原來不少功能均可以用web來實現,而後原生做爲容器顯示瀏覽器

因此爲了提升開發效率,愈來愈多的人使用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功能)

Hybrid面臨的挑戰

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

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

Native、Hybrid、React Native、Web App方案的分析比較

目前的主流應用程序有四大類型:Native App、Hybrid App、React Native App、Web App。本文分別對這幾種方案作一些分析對比

Native App

即傳統的原生APP開發模式,Android基於Java語言,底層調用Google的 API;iOS基於OC或者Swift語言,底層調用App官方提供的API。體驗最好

直接依託於操做系統,交互性最強,性能最好，相比於其它模式的交互,原生APP體驗是最優的

功能最爲強大,特別是在與系統交互中,幾乎全部功能都能實現。得益於原生是直接依託於系統的,因此能夠直接調用官方提供的api,功能最爲全面(好比本地資源操做,通知,動畫等)

開發成本高,沒法跨平臺,不一樣平臺Android和iOS上都要各自獨立開發。Android上基於Java開發,iOS上基於OC或Swift開發,相互之間獨立,必需要有各自的開發人員

門檻較高,原生人員有必定的入門門檻,相比廣大的前端人員而言,較少。原生的一個很大特色就是獨立,因此不太容易入門,不像web前端同樣那麼普遍,並且Android,iOS都須要獨立學習

更新緩慢,特別是發佈應用商店後,須要等到審覈週期。原生應用更新是一個很大的問題,Android中還能直接下載整包APK進行更新,可是iOS中,若是是發佈AppStore,必須經過AppStore地址更新,而每次更新都須要審覈,因此沒法達到及時更新

維護成本高。同開發同樣,項目上線後,維護起來也很爲麻煩

Web App

即移動端的網站,將頁面部署在服務器上,而後用戶使用各大瀏覽器訪問。通常泛指 SPA(Single Page Application)模式開發出的網站。體驗最差。不是獨立APP,沒法安裝和發佈

Web網站通常分兩種,MPA(Multi-page Application)和SPA(Single-page Application)。而Web App通常泛指後面的SPA形式開發出的網站(由於能夠模仿一些APP的特性),有以下優勢和缺點

開發成本低,能夠跨平臺,調試方便。web app通常只須要一個前端人員開發出一套代碼,而後便可應用於各大主流瀏覽器(特殊狀況能夠代碼進行下兼容),沒有新的學習成本,並且能夠直接在瀏覽器中調試

維護成本低同上,若是代碼合理,只須要一名前端就能夠維護多個web app

更新最爲快速。因爲web app資源是直接部署在服務器端的,因此只須要替換服務器端的文件,用戶訪問是就已經更新了(固然須要解決一些緩存問題)

無需安裝App,不會佔用手機內存。經過瀏覽器便可訪問,無需安裝,用戶就會比較願意去用

性能低,用戶體驗差。因爲是直接經過的瀏覽器訪問,因此沒法使用原生的API,操做體驗很差

依賴於網絡,頁面訪問速度慢,耗費流量。Web App每次訪問都須要去服務端加載資源訪問,因此必須依賴於網絡,並且網速慢時訪問速度很不理想,特別是在移動端,若是網站優化很差會無端消耗大量流量

功能受限,大量功能沒法實現。只能使用Html5的一些特殊api,沒法調用原生API,因此不少功能存在沒法實現狀況

臨時性入口,用戶留存率低。這既是它的優勢,也是缺點,優勢是無需安裝,肯定是用完後有時候很難再找到,或者說很難專門爲某個web app留存一個入口,致使用戶很難再次使用

Hybrid App

即混合開發,由Native經過JSBridge等方法提供統一的API,而後用Html5+JS來寫實際的邏輯,調用API,這種模式下,因爲Android,iOS的API通常有一致性,並且最終的頁面也是在webview中顯示,有有跨平臺效果

開發成本較低,能夠跨平臺,調試方便Hybrid模式下,由原生提供統一的API給JS調用,實際的主要邏輯有Html和JS來完成,而因爲最終是放在webview中顯示的,因此只須要寫一套代碼便可,達到跨平臺效果,另外也能夠直接在瀏覽器中調試,很爲方便

最重要的是隻須要一個前端人員稍微學習下JS api的調用便可,無需兩個獨立的原生人員。通常Hybrid中的跨平臺最少能夠跨三個平臺:Android App,iOS App,普通webkit瀏覽器

維護成本低,功能可複用。同上,若是代碼合理,只須要一名前端就能夠維護多個app,並且不少功能還能夠互相複用

更新較爲自由。雖然沒有web app更新那麼快速,可是Hybrid中也能夠經過原生提供api,進行資源主動下載,達到只更新資源文件,不更新apk(ipa)的效果

針對新手友好,學習成本較低。這種開發模式下,只須要前端人員關注一些原生提供的API,具體的實現無需關心,沒有新的學習內容,只須要前端人員便可開發

功能更加完善,性能和體驗要比起web app好太多。由於能夠調用原生api,因此不少功能只要原生提供出就能夠實現,另外性能也比較接近原生了

部分性能要求的頁面可用原生實現。這應該是Hybrid模式的最多一個好處了,由於這種模式是原生混合web,因此咱們徹底能夠將交互強,性能要求高的頁面用原生寫,而後一些其它頁面用JS寫,嵌入webview中,達到最佳體驗

相比原生,性能仍然有較大損耗。這種模式受限於webview的性能桎梏,相比原生而言有很多損耗,體驗沒法和原生相比

不適用於交互性較強的app。這種模式的主要應用是:一些新聞閱讀類,信息展現類的app;可是不適用於一些交互較強或者性能要求較高的app(好比動畫較多就不適合)

React Native App

Facebook發起的開源的一套新的APP開發方案,使用JS+部分原生語法來實現功能。初次學習成本較高,可是在入門後,通過良好的封裝也可以實現大部分的跨平臺。並且體驗很好。

雖說開發成本大於Hybrid模式,可是小於原生模式,大部分代碼可複用。相比於原生模式,這種模式是統一用JS寫代碼,因此每每只須要一名成員投入學習,便可完成跨平臺app的開發,並且後續代碼封裝的好,不少功能可複用

性能體驗高於Hybrid,不遜色與原生。這種模式和Hybrid不同,Hybrid中的view層實際上仍是dom,可是這種模式的view層是虛擬dom,因此性能要高於Hybrid,距離原生差距不大

這種模式能夠認爲是用JS寫原生,即頁面用JS寫,而後原生經過Bridge技術分析JS,將JS內容單獨渲染成原生Android和iOS,因此也就是爲何性能不遜色原生

開發人員單一技術棧,一次學習,跨平臺開發。這種模式是統一由JS編寫,有着獨特的語法,因此只須要學習一次,便可同時開發Android和iOS

社區繁榮,遇到問題容易解決。這應該是React Native的很大一個優點,不像Hybrid模式和原生模式同樣各自爲營,這種模式是Facebook統一發起的,因此有一個統一的社區,裏面有大量資源和活躍的人員,對開發者很友好

雖然能夠部分跨平臺,但並非Hybrid中的一次編寫,兩次運行那種,而是不一樣平臺代碼有所區別這種模式實際上仍是JS來寫原生,因此Android和iOS中的原生代碼會有所區別,若是須要跨平臺,對開發人員有必定要求固然了,若是發展了有必定時間,組件庫夠豐富了,那麼其實影響也就不大了,甚至會比Hybrid更快

開發人員學習有必定成本。雖然社區已經比較成熟了,可是一個新的普通前端學習起來仍是有必定學習成本的,沒法像Hybrid模式同樣平滑

各大開發模式直觀對比

	Native App	Web App	Hybrid App	React Native App
原生功能體驗	優秀	差	良好	接近優秀
渲染性能	很是快	慢	接近快	快
是否支持設備底層訪問	支持	不支持	支持	支持
網絡要求	支持離線	依賴網絡	支持離線(資源存本地狀況)	支持離線
更新複雜度	高(幾乎老是經過應用商店更新)	低(服務器端直接更新)	較低(能夠進行資源包更新)	較低(能夠進行資源包更新)
編程語言	Android(Java),iOS(OC/Swift)	js+html+css3	js+html+css3	主要使用JS編寫,語法規則JSX
社區資源	豐富(Android,iOS單獨學習)	豐富(大量前端資源)	有侷限(不一樣的Hybrid相互獨立)	豐富(統一的活躍社區)
上手難度	難(不一樣平臺須要單獨學習)	簡單(寫一次,支持不一樣平臺訪問)	簡單(寫一次,運行任何平臺)	中等(學習一次,寫任何平臺)
開發週期	長	短	較短	中等
開發成本	昂貴	便宜	較爲便宜	中等
跨平臺	不跨平臺	全部H5瀏覽器	Android,iOS,h5瀏覽器	Android,iOS
APP發佈	App Store	Web服務器	App Store	App Store