什么是Hybrid App
最開的App開發只有原生開發這個概念,但自從H5廣泛流行后,一種效率更高的開發模式Hybrid應運而生,它就是"Hybrid模式"。Hybrid APP是目前廣泛流行的一種APP開發模式
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是半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中,而是發布到微信中
像以上技術都不斷的在沖擊着Hybrid模式(當然Native也會有影響),不過都很推崇JS(話說很多前端猿一直希望JS一統天下)
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 |
如何選擇開發模式
目前有多種開發模式,那么我們平時開發時如何選擇用哪種模式呢？如下
選擇純Native App模式的情況
性能要求極高,體驗要求極好,不追求開發效率。一般屬於吹毛求疵的那種級別了,因為正常來說如果要求不是特別高,會有Hybrid
選擇Web App模式的情況
不追求用戶體驗和性能,對離線訪問沒要求。正常來說,如果追求性能和體驗,都不會選用web app
沒有額外功能,只有一些信息展示。因為web有限制,很多功能都無法實現,所以有額外功能就只能棄用這種方案了
選擇Hybrid App模式的情況
大部分情況下的App都推薦采用這種模式這種模式可以用原生來實現要求高的界面,對於一些比較通用型,展示型的頁面完全可以用web來實現,達到跨平台效果,提升效率
當然了,一般好一點的Hybrid方案,都會把資源放在本地的,可以減少網絡流量消耗
選擇React Native App模式的情況
追求性能,體驗,同時追求開發效率,而且有一定的技術資本,舍得前期投入
React Native這種模式學習成本較高,所以需要前期投入不少時間才能達到較好水平,但是有了一定水准后,開發起來它的優勢就體現出來了,性能不遜色原生,而且開發速度也很快
另類的app方案
除了以上的幾種常見app開發模式,其實還有一些其它的類似方案
微網頁
比如在進行微信網頁開發時,可以調用一些微信的特殊api,這其實就是算是微信的Hybrid模式,實質上仍然是在瀏覽器中(只不過是騰訊的X5內核)
當然了,微信在這方面做了很多限制,比如權限認證等等,所以導致開發起來效果不是很完美。這里不再贅述其功能
微信小程序
微信小程序是微信新推出的一種新的app方案,2016年9月開始進行內測,2016年11月准備全面面向開發者
需要注意的是,這種模式是“反HTML5”的,相當於是微信提供的一套封閉開發模式,有自己的語法和IDE,有的類似於iOS開發的感覺。