隨著智能手機(jī)的普及，移動(dòng)端應(yīng)用幾乎成為每個(gè)互聯(lián)網(wǎng)產(chǎn)品的標(biāo)配晌该。在快速迭代的互聯(lián)網(wǎng)戰(zhàn)場(chǎng)中高效開(kāi)發(fā)肥荔、低成本上線產(chǎn)品，是每個(gè)應(yīng)用開(kāi)發(fā)團(tuán)隊(duì)追求的目標(biāo)朝群。此時(shí)燕耿，選擇合適的應(yīng)用類型和開(kāi)發(fā)模式便至關(guān)重要。移動(dòng)應(yīng)用可以粗分為三種：原生應(yīng)用(native app)姜胖， 網(wǎng)頁(yè)應(yīng)用(web app誉帅，或HTML5 app)，以及它們的混血兒——混合模式移動(dòng)應(yīng)用(hybrid app)右莱。
今天就來(lái)和大家簡(jiǎn)單聊聊近年來(lái)蓬勃發(fā)展的hybrid app蚜锨。

一、什么是Hybrid Mobile App

Hybrid app從外觀上來(lái)看是一個(gè)native app慢蜓，實(shí)則只有一個(gè)UIWebView亚再，里面訪問(wèn)的是一個(gè)web app，如新聞?lì)惡鸵曨l類的應(yīng)用普遍采取該策略：native的框架加上web的內(nèi)容胀瞪。不同于native app需要針對(duì)不同的平臺(tái)使用不同的開(kāi)發(fā)語(yǔ)言（如使用Objective-C针余、Swift開(kāi)發(fā)iOS應(yīng)用，使用Java等開(kāi)發(fā)Android應(yīng)用凄诞，使用C#開(kāi)發(fā)Windows Phone應(yīng)用）圆雁，hybrid app允許開(kāi)發(fā)者僅使用一套網(wǎng)頁(yè)語(yǔ)言代碼（HTML5+CSS+JavaScript）梢褐，即可開(kāi)發(fā)能夠在不同平臺(tái)上部署的類原生應(yīng)用 颠放。由于hybrid app結(jié)合了native app良好用戶交互體驗(yàn)和web app跨平臺(tái)開(kāi)發(fā)的優(yōu)勢(shì)，能夠顯著節(jié)省移動(dòng)應(yīng)用開(kāi)發(fā)的時(shí)間和成本铭乾，hybrid app得到越來(lái)越多公司的青睞汛蝙。

Source: Native, HTML5, or Hybrid: Understanding Your Mobile Application Development Options

按照網(wǎng)頁(yè)語(yǔ)言和程序語(yǔ)言的混合烈涮，hybrid app通常可以分為三種類型：

1. 多View混合型： native view和web view獨(dú)立展示窖剑，交替出現(xiàn)坚洽。 其應(yīng)用主體通常是native app，web技術(shù)作為補(bǔ)充西土。即在需要的時(shí)候讶舰，將web view作為獨(dú)立的view運(yùn)行，在web view內(nèi)完成相關(guān)的展示操作。開(kāi)發(fā)難度與native app相當(dāng)跳昼。舉個(gè)栗子：Instagram的timeline使用的是web view般甲。

2. 單View混合型： 在同一個(gè)view內(nèi)，native view和web view為層疊關(guān)系鹅颊，同時(shí)出現(xiàn)敷存。開(kāi)發(fā)成本較高，難度較大堪伍，但是體驗(yàn)較好。舉個(gè)栗子：百度搜索同時(shí)實(shí)現(xiàn)充分的靈活性和較好的用戶體驗(yàn)杠娱。

3. Web主體型： 應(yīng)用主體是web view挽牢，穿插native功能，主要以網(wǎng)頁(yè)語(yǔ)言編寫摊求。整體開(kāi)發(fā)難度低禽拔，基本可以實(shí)現(xiàn)跨平臺(tái)；而用戶體驗(yàn)好壞室叉，主要取決于底層中間件的交互與跨平臺(tái)能力睹栖。舉個(gè)栗子：項(xiàng)目管理工具 Basecamp使用web view呈現(xiàn)內(nèi)容，調(diào)用系統(tǒng)原生API實(shí)現(xiàn)界面導(dǎo)航等功能來(lái)提高用戶體驗(yàn)茧痕。

• Hybrid app也并非是完美的解決方案野来。由于其使用HTML5，某些依賴于復(fù)雜的原生功能或者繁重的過(guò)渡動(dòng)畫的應(yīng)用會(huì)出現(xiàn)卡頓踪旷；同時(shí)曼氛，為了模擬native app的UI和感官，需要投入額外的時(shí)間和精力令野；盡管可以跨平臺(tái)舀患，但是并不能完全支持所有的設(shè)備和操作系統(tǒng)；最后气破，如果應(yīng)用的體驗(yàn)不夠原生化聊浅，如一個(gè)簡(jiǎn)單的網(wǎng)站，則還有被Apple App Store拒絕的風(fēng)險(xiǎn)现使。

二低匙、 什么時(shí)候選擇Hybrid App

在hybrid app備受追捧的今天，我們也許會(huì)隨大流優(yōu)先考慮開(kāi)發(fā)hybrid app碳锈。但是顽冶，每個(gè)產(chǎn)品各具特色，還沒(méi)有哪一種解決方案可以完美地應(yīng)萬(wàn)變售碳。hybrid app的中庸讓它大放異彩渗稍，也限制了它的應(yīng)用場(chǎng)景 佩迟。在決定采用一種開(kāi)發(fā)模式之前，有許多因素需要考慮竿屹，諸如：

• 你希望針對(duì)哪個(gè)平臺(tái)做開(kāi)發(fā)？
• 你希望通過(guò)應(yīng)用商店發(fā)布應(yīng)用么灸姊？
• 你希望利用手機(jī)特有的性能么拱燃？
• 你的團(tuán)隊(duì)技術(shù)能力如何？
• 你的項(xiàng)目周期和預(yù)算是多少力惯？

如果要設(shè)計(jì)Angry Birds一類對(duì)圖形要求很高的游戲碗誉，那么在暫不考慮技術(shù)團(tuán)隊(duì)能力的情況下，native app是最優(yōu)選擇父晶；如果要設(shè)計(jì)如Yelp一類內(nèi)容導(dǎo)向的應(yīng)用哮缺，那么hybrid app會(huì)是很好的選擇；如果項(xiàng)目時(shí)間緊張甲喝，沒(méi)有足夠的人手和資金尝苇，對(duì)圖形和系統(tǒng)原生特性沒(méi)有要求，那么web app將是性價(jià)比最高的解決方案埠胖。

表一對(duì)比了native app,hybrid app和web app在不同方面的表現(xiàn)糠溜，可以幫助你根據(jù)實(shí)際情況選擇最佳的解決方案。

• InfoQ上高嘉峻的一篇文章分享了幾個(gè)hybrid app開(kāi)發(fā)的誤區(qū)直撤，也是開(kāi)發(fā)過(guò)程中應(yīng)該盡量避免的：

• 為了HTML5而hybrid app： HTML5是HTML4.0.1和XHTML1.0的升級(jí)版非竿，有更強(qiáng)大的表現(xiàn)功能，并加入了local storage等技術(shù)谋竖，為web頁(yè)面提供了更大的想象空間和更多的可能性红柱。但是，作為發(fā)展中的技術(shù)蓖乘，HTML5收到瀏覽器兼容性和手機(jī)硬件水平的影響锤悄，能提供的功能和native app扔有一定的差距。開(kāi)發(fā)應(yīng)用時(shí)驱敲，首先是要滿足用戶需求铁蹈，而不是追趕技術(shù)革新的大潮。所以開(kāi)發(fā)應(yīng)用時(shí)众眨，應(yīng)從應(yīng)用本身功能和團(tuán)隊(duì)開(kāi)發(fā)資源綜合考量握牧，決定是否采用hybrid app開(kāi)發(fā)模式。

• 忽略關(guān)鍵因素： Web是基于PC的一種開(kāi)發(fā)模式娩梨，而mobile app運(yùn)行于移動(dòng)端沿腰。通常，web開(kāi)發(fā)者使用PC瀏覽器模擬app中的web view進(jìn)行調(diào)試狈定，而不是直接使用手機(jī)上的web view颂龙。 二者能支配的CPU資源习蓬，最大占有內(nèi)存，運(yùn)行網(wǎng)絡(luò)環(huán)境措嵌，和鼠標(biāo)/觸控操作躲叼，瀏覽器對(duì)CSS/JS的解析和對(duì)事件的處理有著巨大的差別。而這些差別常常是web頁(yè)面能否正常運(yùn)行于app中的關(guān)鍵因素企巢。

• 富交互導(dǎo)致體驗(yàn)差： 這主要體現(xiàn)在兩個(gè)方面：（1）web與手機(jī)平臺(tái)默認(rèn)交互習(xí)慣不一致：iOS和Android各有一套交互習(xí)慣枫慷，包括視覺(jué)風(fēng)格，界面切換浪规，操作習(xí)慣等或听。比如手機(jī)端系統(tǒng)風(fēng)格是左右滑屏來(lái)進(jìn)入或者退出界面，而舊界面保持狀態(tài)笋婿；web則是默認(rèn)無(wú)論加載還是后退誉裆，都會(huì)刷新舊界面，造成體驗(yàn)上的損失缸濒。如果模擬native的交互方式足丢，那么會(huì)提高開(kāi)發(fā)成本，卻也難以達(dá)到native的流暢性绍填。（2）與native相比同樣的功能在性能上存在差距：Web界面上JS對(duì)HTML Node的操作需要消耗大量的CPU資源霎桅。首先，手機(jī)的CPU性能普遍低于PC端讨永；其次滔驶，不同手機(jī)之間的硬件水平也參差不齊，比如在iPhone6s上可以流暢運(yùn)行的界面卿闹，在iPhone5揭糕、MX5上可能就無(wú)法達(dá)到同樣的流暢度。

• 跨平臺(tái)： Hybrid app的優(yōu)勢(shì)之一是繼承web跨平臺(tái)的特性锻霎。然而著角，在智能手機(jī)軟硬件版本眾多的今天，兼容性是個(gè)不容忽視的問(wèn)題旋恼。不同的安卓操作系統(tǒng)其瀏覽器內(nèi)核對(duì)JS和CSS的解析吏口、事件處理會(huì)有不同；iOS不同版本之間也存在較大差異冰更。所以产徊，在跨平臺(tái)開(kāi)發(fā)時(shí)，兼容性也是需要重點(diǎn)考慮的問(wèn)題蜀细。

• 交互一致性： 這里的一致性并非指同一應(yīng)用在不同平臺(tái)上的一致性體驗(yàn)舟铜，而是指在同一平臺(tái)上，hybrid app和native平臺(tái)的一致性奠衔。比如“返回”操作谆刨，在iOS平臺(tái)上頁(yè)面頂部留有一個(gè)44像素高的導(dǎo)航欄塘娶，左側(cè)的返回按鈕用于返回操作，可以通過(guò)絕對(duì)地址的方式鏈接到任何其它界面痊夭；而Android通常使用設(shè)備提供的返回鍵刁岸，返回上一個(gè)界面，如果自行配置平臺(tái)返回按鈕生兆，那么它會(huì)和設(shè)備提供的返回鍵指向不同的位置难捌。

<2>區(qū)分三者

• nativeapp是一個(gè)原生程序，一般運(yùn)行在機(jī)器操作系統(tǒng)上鸦难，有很強(qiáng)的交互，一般靜態(tài)資源都是在本地的员淫。瀏覽使用方便合蔽，體驗(yàn)度高。在實(shí)現(xiàn)上要么使用Objecttive-c和cocoaTouch Framework撰寫iOS程序介返，要么選擇java+Android Framework撰寫android應(yīng)用程序拴事。

• hybridapp是一個(gè)半原生程序，偽造了一個(gè)瀏覽器的apk/ipa原生程序圣蝎，把地址寫死了刃宵，然后里面運(yùn)行了一個(gè)webapp。里面是WebView UI 徘公。但是還是運(yùn)行在機(jī)器的操作系統(tǒng)上牲证，交互較弱，資源一般在本地或者網(wǎng)絡(luò)都可以关面。瀏覽體驗(yàn)度次之坦袍。

• webapp是生存在瀏覽器里的應(yīng)用，所以只能運(yùn)行在瀏覽器里等太，宿主是瀏覽器捂齐，不再是操作系統(tǒng)。資源一般都在網(wǎng)絡(luò)上缩抡。說(shuō)的根本點(diǎn)就是一個(gè)觸屏版的網(wǎng)站

什么叫做原生App?

原生App是專門針對(duì)某一類移動(dòng)設(shè)備而生的奠宜，它們都是被直接安裝到設(shè)備里，而用戶一般也是通過(guò)網(wǎng)絡(luò)商店或者賣場(chǎng)來(lái)獲取例如 The App Store 與Android Apps on Google Play 隨便說(shuō)幾個(gè)原生App的例子瞻想，比如iOS的Camera+以及Android的 KeePassDroid

什么叫做移動(dòng)Web App?

一般說(shuō)來(lái)压真，移動(dòng)Web App都是都是需要用到網(wǎng)絡(luò)的，它們利用設(shè)備上的瀏覽器(比如iPhone的Safari)來(lái)運(yùn)行内边，而且它們不需要在設(shè)備上下載后安裝榴都。

什么是混合app?

Hybrid App是指介于web-app、native-app這兩者之間的app,它雖然看上去是一個(gè)Native App漠其，但只有一個(gè)UI WebView嘴高，里面訪問(wèn)的是一個(gè)Web App竿音，比如街旁網(wǎng)最開(kāi)始的應(yīng)用就是包了個(gè)客戶端的殼，其實(shí)里面是HTML5的網(wǎng)頁(yè)拴驮，后來(lái)才推出真正的原生應(yīng)用春瞬。再?gòu)氐滓稽c(diǎn)的，如掌上百度和淘寶客戶端Android版套啤，走的也是Hybrid App的路線宽气，不過(guò)掌上百度里面封裝的不是WebView，而是自己的瀏覽內(nèi)核潜沦，所以體驗(yàn)上更像客戶端萄涯，更高效。

• 綜合一下就是：“Hybrid App同時(shí)使用網(wǎng)頁(yè)語(yǔ)言與程序語(yǔ)言開(kāi)發(fā)唆鸡，通過(guò)應(yīng)用商店區(qū)分移動(dòng)操作系統(tǒng)分發(fā)涝影，用戶需要安裝使用的移動(dòng)應(yīng)用”≌迹總體特性更接近Native App但是和Web App區(qū)別較大燃逻。只是因?yàn)橥瑫r(shí)使用了網(wǎng)頁(yè)語(yǔ)言編碼，所以開(kāi)發(fā)成本和難度比Native App要小很多臂痕。因此說(shuō)伯襟，Hybrid App兼具了Native App的所有優(yōu)勢(shì)，也兼具了Web App使用HTML5跨平臺(tái)開(kāi)發(fā)低成本的優(yōu)勢(shì)握童。

• Web App是指基于Web的系統(tǒng)和應(yīng)用姆怪，運(yùn)行在高端手機(jī)的網(wǎng)絡(luò)和瀏覽器上，用網(wǎng)頁(yè)技術(shù)開(kāi)發(fā)實(shí)現(xiàn)特定功能的應(yīng)用舆瘪，對(duì)手機(jī)性能要求比較高片效。

• Native App（原生開(kāi)發(fā)）:目前較為成熟，各大公司均采用此方式英古。但是其人工成本較高淀衣，同一個(gè)項(xiàng)目，至少需要Android端召调、iOS端膨桥、Web端三個(gè)開(kāi)發(fā)團(tuán)隊(duì)。

• Hybrid App（混合開(kāi)發(fā)）唠叛，基于第三方跨平臺(tái)移動(dòng)應(yīng)用引擎框架進(jìn)行開(kāi)發(fā)只嚣。使用HTML5和JS作為開(kāi)發(fā)，調(diào)用引擎封裝的底層功能如照相機(jī)艺沼、傳感器册舞、通訊錄等。

拿酒來(lái)形象化這三種模式的話：

• Web App就像白酒那樣渾厚甘醇障般，度數(shù)高调鲸，但不適合任何人的口味盛杰，制造成本低，

• Native App就是葡萄酒藐石，分紅白類型即供，對(duì)葡萄品質(zhì)要求高，口味大眾化于微，比較成熟逗嫡，

• Hybrid App就是雞尾酒，混合了多種酒的優(yōu)勢(shì)株依，非常適合跨平臺(tái)驱证，是以后的一個(gè)App開(kāi)發(fā)趨勢(shì)。

<3>區(qū)分native APP 恋腕，web APP雷滚，hybrid APP

1、Native App

Native App是一種基于智能手機(jī)本地操作系統(tǒng)如iOS吗坚、Android、WP并使用原生程式編寫運(yùn)行的第三方應(yīng)用程序,也叫本地app呆万。一般使用的開(kāi)發(fā)語(yǔ)言為JAVA商源、C++、Objective-C谋减。

想創(chuàng)建Native App牡彻，開(kāi)發(fā)者必須編寫源代碼，使用由操作系統(tǒng)開(kāi)發(fā)商提供的工具出爹，對(duì)源代碼進(jìn)行編譯庄吼。代碼編譯之后以2進(jìn)制或者字節(jié)碼的形式運(yùn)行在操作系統(tǒng)上，直接調(diào)用操作系統(tǒng)的Device API严就。

雖然不同操作系統(tǒng)上進(jìn)行的開(kāi)發(fā)過(guò)程常常很相似总寻，但是每一種移動(dòng)操作系統(tǒng)都隨帶各自的獨(dú)特工具。平臺(tái)之間的這些區(qū)別導(dǎo)致了Native開(kāi)發(fā)方法的最重大缺點(diǎn)之一：為一種移動(dòng)平臺(tái)編寫的代碼無(wú)法在另一種平臺(tái)上使用梢为。Native App的優(yōu)缺點(diǎn)總結(jié)如下：

優(yōu)點(diǎn)

• 提供最佳的用戶體驗(yàn)渐行，最優(yōu)質(zhì)的用戶界面，最華麗的交互
• 針對(duì)不同平臺(tái)提供不同體驗(yàn)
• 下載到本地铸董，可節(jié)省帶寬成本
• 可訪問(wèn)本地資源
• 直接訪問(wèn)系統(tǒng)級(jí)API
• 操作速度更快
• 用戶留存率高

缺點(diǎn)

• 移植到不同平臺(tái)上比較麻煩
• 需要維護(hù)多個(gè)版本
• 發(fā)布新版本需要通過(guò)store或market的確認(rèn)
• 盈利需要與第三方分成
• 開(kāi)發(fā)的成本比較大祟印，需要針對(duì)不同平臺(tái)開(kāi)發(fā)相應(yīng)的版本
• 更新體驗(yàn)較差、同時(shí)也比較麻煩（每一次發(fā)布新的版本粟害，都需要做版本打包蕴忆，且需要用戶手動(dòng)更新，或一個(gè)讓用戶反感的提示）悲幅。

2套鹅、Web App

Web App是運(yùn)行于網(wǎng)絡(luò)和標(biāo)準(zhǔn)瀏覽器上站蝠，以HTML+JS+CSS等WEB技術(shù)開(kāi)發(fā)實(shí)現(xiàn)特定功能的應(yīng)用。通過(guò)瀏覽器來(lái)調(diào)用Device API芋哭，但是只有數(shù)量有限的這些API向?yàn)g覽器里面運(yùn)行的Web App公開(kāi)沉衣。基于當(dāng)下開(kāi)始普及流行的HTML5减牺，Web App可以實(shí)現(xiàn)很多原本Native App才可以實(shí)現(xiàn)的功能豌习，，比如LBS的功能拔疚、本地?cái)?shù)據(jù)存儲(chǔ)肥隆、音視頻播放的功能，甚至還有調(diào)用照相機(jī)和結(jié)合GPU的硬件加速功能稚失。

由于它不依賴于操作系統(tǒng)栋艳，因此開(kāi)發(fā)了一款Web App后，基本能應(yīng)用于各種系統(tǒng)平臺(tái)句各。并且還有版本升級(jí)容易的優(yōu)勢(shì)（畢竟服務(wù)器是受自己控制的）吸占。但是這種方案的缺點(diǎn)也很明顯——無(wú)法使用系統(tǒng)級(jí)API，只能做為一個(gè)臨時(shí)的入口凿宾，用戶很難留存矾屯。Web App的優(yōu)缺點(diǎn)總結(jié)如下：

優(yōu)點(diǎn)

• 開(kāi)發(fā)成本低；
• 更新快初厚；
• 更新無(wú)需通知用戶件蚕，不需要手動(dòng)升級(jí)；
• 能夠跨多個(gè)平臺(tái)和終端产禾；
• 維護(hù)比較簡(jiǎn)單排作。

缺點(diǎn)

• 臨時(shí)性的入口；
• 無(wú)法獲取系統(tǒng)級(jí)別的通知亚情，提醒妄痪，動(dòng)效等等；
• 用戶留存率低势似；
• 需要依賴網(wǎng)絡(luò)拌夏，體驗(yàn)較差。

3履因、Hybrid App

Hybrid App是一種用Native技術(shù)來(lái)搭建App的外殼障簿，殼里的內(nèi)容由Web技術(shù)來(lái)提供的移動(dòng)應(yīng)用，兼具“Native App良好交互體驗(yàn)的優(yōu)勢(shì)”和“Web App跨平臺(tái)開(kāi)發(fā)的優(yōu)勢(shì)”。

根據(jù)實(shí)現(xiàn)的不同，可以細(xì)分為兩種實(shí)現(xiàn)方案：

（1）在Native App中使用WebView加載遠(yuǎn)端Web資源

這種方案的Web資源放置在服務(wù)器上所意，開(kāi)發(fā)者不必經(jīng)歷提交和批準(zhǔn)過(guò)程——有些App商店要求這個(gè)過(guò)程终议，就可以對(duì)App進(jìn)行小幅更新产弹。遺憾的是难衰，這個(gè)方法擯棄了任何離線可用性笆怠，因?yàn)樵O(shè)備與網(wǎng)絡(luò)沒(méi)有連接時(shí)堕虹，無(wú)法訪問(wèn)設(shè)備岂津。

（2）將一組HTML虱黄、JavaScript、CSS和媒體文件吮成，封裝到App代碼中橱乱，存儲(chǔ)在設(shè)備本地，使用Cordova/PhoneGap等框架通過(guò)WebView加載本地資源進(jìn)行頁(yè)面渲染
把Web代碼封裝到App里面在一定程度上緩解從遠(yuǎn)端加載靜態(tài)資源導(dǎo)致UI展示延遲的問(wèn)題粱甫，可以提高性能和可訪問(wèn)性泳叠，并且還可以通過(guò)橋接Native和Web來(lái)調(diào)用一些Device的API。
但是其劣勢(shì)也很明顯茶宵，一是不允許遠(yuǎn)程更新危纫；二是安裝包變大；三是如果想調(diào)用相關(guān)平臺(tái)的API乌庶，需要針對(duì)平臺(tái)單獨(dú)進(jìn)行開(kāi)發(fā)种蝶，如果在應(yīng)用中用到了大量的Device API，那么開(kāi)發(fā)的效率將大大降低瞒大。

• Hybrid App同時(shí)使用網(wǎng)頁(yè)語(yǔ)言與程序語(yǔ)言開(kāi)發(fā)蛤吓，但其總體特性更接近Native App。只是因?yàn)橥瑫r(shí)使用了web語(yǔ)言編碼糠赦，所以開(kāi)發(fā)成本和難度比Native App要小很多。因此锅棕，Hybrid App兼具了Native App的優(yōu)勢(shì)拙泽，也兼具了Web App使用HTML5跨平臺(tái)開(kāi)發(fā)低成本的優(yōu)勢(shì)。

三種App之間的比較

<4>選擇哪個(gè)做項(xiàng)目比較合適

當(dāng)前的APP開(kāi)發(fā)模式注意有以下四大類型:

Native App

• 即傳統(tǒng)的原生APP開(kāi)發(fā)模式,Android基于Java語(yǔ)言,底層調(diào)用Google的API;iOS基于OC或者Swift語(yǔ)言,底層調(diào)用App官方提供的API裸燎。體驗(yàn)最后顾瞻。

Web App

• 即移動(dòng)端的網(wǎng)站,將頁(yè)面部署在服務(wù)器上,然后用戶使用各大瀏覽器訪問(wèn)。一般泛指 SPA(Single Page Application)模式開(kāi)發(fā)出的網(wǎng)站德绿。體驗(yàn)最差荷荤。

Hybrid App

• 即混合開(kāi)發(fā),由Native通過(guò)JSBridge等方法提供統(tǒng)一的API,然后用Html5+JS來(lái)寫實(shí)際的邏輯,調(diào)用API,這種模式下,由于Android,iOS的API一般有一致性,而且最終的頁(yè)面也是在webview中顯示,所有有跨平臺(tái)效果

React Native App

• Facebook發(fā)起的開(kāi)源的一套新的APP開(kāi)發(fā)方案,使用JS+部分原生語(yǔ)法來(lái)實(shí)現(xiàn)功能。初次學(xué)習(xí)成本較高,但是在入門后,經(jīng)過(guò)良好的封裝也能夠?qū)崿F(xiàn)大部分的跨平臺(tái)移稳。而且體驗(yàn)很好蕴纳。

腦圖地址: http://naotu.baidu.com/file/1eb556f3380e8189be859348527ec518?token=a5a049eb4c618e70

Native App

即原生開(kāi)發(fā)模式,開(kāi)發(fā)出來(lái)的是原生程序,不同平臺(tái)上,Android和iOS的開(kāi)發(fā)方法不同,開(kāi)發(fā)出來(lái)的是一個(gè)獨(dú)立的APP,能發(fā)布應(yīng)用商店,有如下優(yōu)點(diǎn)和缺點(diǎn)。

優(yōu)點(diǎn)

• 直接依托于操作系統(tǒng),交互性最強(qiáng),性能最好
• 相比于其它模式的交互,原生APP體驗(yàn)是最優(yōu)的
• 功能最為強(qiáng)大,特別是在與系統(tǒng)交互中,幾乎所有功能都能實(shí)現(xiàn)
• 得益于原生是直接依托于系統(tǒng)的,所以可以直接調(diào)用官方提供的api,功能最為全面(比如本地資源操作,通知,動(dòng)畫等)

缺點(diǎn)

• 開(kāi)發(fā)成本高,無(wú)法跨平臺(tái),不同平臺(tái)Android和iOS上都要各自獨(dú)立開(kāi)發(fā)
• Android上基于Java開(kāi)發(fā),iOS上基于OC或Swift開(kāi)發(fā),相互之間獨(dú)立,必須要有各自的開(kāi)發(fā)人員
• 門檻較高,原生人員有一定的入門門檻,相比廣大的前端人員而言,較少
• 原生的一個(gè)很大特點(diǎn)就是獨(dú)立,所以不太容易入門,不像web前端一樣那么廣泛,而且Android,iOS都需要獨(dú)立學(xué)習(xí)
  更新緩慢,特別是發(fā)布應(yīng)用商店后,需要等到審核周期
• 原生應(yīng)用更新是一個(gè)很大的問(wèn)題,Android中還能直接下載整包APK進(jìn)行更新,但是iOS中,如果是發(fā)布AppStore,必須通過(guò)AppStore地址更新,而每次更新都需要審核,所以無(wú)法達(dá)到及時(shí)更新
• 維護(hù)成本高,同開(kāi)發(fā)一樣,項(xiàng)目上線后,維護(hù)起來(lái)也很為麻煩

Web App

即移動(dòng)端的網(wǎng)站,將頁(yè)面部署在服務(wù)器上,然后用戶使用各大瀏覽器訪問(wèn),不是獨(dú)立APP,無(wú)法安裝和發(fā)布Web網(wǎng)站一般分兩種,MPA(Multi-page Application)和SPA(Single-page Application)个粱。而Web App一般泛指后面的SPA形式開(kāi)發(fā)出的網(wǎng)站(因?yàn)榭梢阅７乱恍?code>APP的特性),有如下優(yōu)點(diǎn)和缺點(diǎn)古毛。

優(yōu)點(diǎn)

• 開(kāi)發(fā)成本低,可以跨平臺(tái),調(diào)試方便
• web app一般只需要一個(gè)前端人員開(kāi)發(fā)出一套代碼,然后即可應(yīng)用于各大主流瀏覽器(特殊情況可以代碼進(jìn)行下兼容),沒(méi)有新的學(xué)習(xí)成本,而且可以直接在瀏覽器中調(diào)試
• 維護(hù)成本低
• 同上,如果代碼合理,只需要一名前端就可以維護(hù)多個(gè)web app
• 更新最為快速
• 由于web app資源是直接部署在服務(wù)器端的,所以只需要替換服務(wù)器端的文件,用戶訪問(wèn)是就已經(jīng)更新了(當(dāng)然需要解決一些緩存問(wèn)題)
• 無(wú)需安裝App,不會(huì)占用手機(jī)內(nèi)存
• 通過(guò)瀏覽器即可訪問(wèn),無(wú)需安裝,用戶就會(huì)比較愿意去用

缺點(diǎn)

• 性能低,用戶體驗(yàn)差
• 由于是直接通過(guò)的瀏覽器訪問(wèn),所以無(wú)法使用原生的API,操作體驗(yàn)不好
• 依賴于網(wǎng)絡(luò),頁(yè)面訪問(wèn)速度慢,耗費(fèi)流量
• Web App每次訪問(wèn)都需要去服務(wù)端加載資源訪問(wèn),所以必須依賴于網(wǎng)絡(luò),而且網(wǎng)速慢時(shí)訪問(wèn)速度很不理想,特別是在移動(dòng)端,如果網(wǎng)站優(yōu)化不好會(huì)無(wú)故消耗大量流量
• 功能受限,大量功能無(wú)法實(shí)現(xiàn)
• 只能使用Html5的一些特殊api,無(wú)法調(diào)用原生API,所以很多功能存在無(wú)法實(shí)現(xiàn)情況
• 臨時(shí)性入口,用戶留存率低,這既是它的優(yōu)點(diǎn),也是缺點(diǎn),優(yōu)點(diǎn)是無(wú)需安裝,確定是用完后有時(shí)候很難再找到,或者說(shuō)很難專門為某個(gè)web app留存一個(gè)入口,導(dǎo)致用戶很難再次使用

Hybrid App

即混合開(kāi)發(fā),也就是半原生半Web的開(kāi)發(fā)模式,有跨平臺(tái)效果,當(dāng)然了,實(shí)質(zhì)最終發(fā)布的仍然是獨(dú)立的原生APP(各種的平臺(tái)有各種的SDK),有如下優(yōu)點(diǎn)和缺點(diǎn)。

優(yōu)點(diǎn)

• 開(kāi)發(fā)成本較低,可以跨平臺(tái),調(diào)試方便
• Hybrid模式下,由原生提供統(tǒng)一的API給JS調(diào)用,實(shí)際的主要邏輯有Html和JS來(lái)完成,而由于最終是放在webview中顯示的,所以只需要寫一套代碼即可,達(dá)到跨平臺(tái)效果,另外也可以直接在瀏覽器中調(diào)試,很為方便,最重要的是只需要一個(gè)前端人員稍微學(xué)習(xí)下JS api的調(diào)用即可,無(wú)需兩個(gè)獨(dú)立的原生人員
• 一般Hybrid中的跨平臺(tái)最少可以跨三個(gè)平臺(tái):Android App,iOS App,普通webkit瀏覽器
  維護(hù)成本低,功能可復(fù)用
• 同上,如果代碼合理,只需要一名前端就可以維護(hù)多個(gè)app,而且很多功能還可以互相復(fù)用
  更新較為自由
• 雖然沒(méi)有web app更新那么快速,但是Hybrid中也可以通過(guò)原生提供api,進(jìn)行資源主動(dòng)下載,達(dá)到只更新資源文件,不更新apk(ipa)的效果
• 針對(duì)新手友好,學(xué)習(xí)成本較低
• 這種開(kāi)發(fā)模式下,只需要前端人員關(guān)注一些原生提供的API,具體的實(shí)現(xiàn)無(wú)需關(guān)心,沒(méi)有新的學(xué)習(xí)內(nèi)容,只需要前端人員即可開(kāi)發(fā)
• 功能更加完善,性能和體驗(yàn)要比起web app好太多
• 因?yàn)榭梢哉{(diào)用原生api,所以很多功能只要原生提供出就可以實(shí)現(xiàn),另外性能也比較接近原生了
  部分性能要求的頁(yè)面可用原生實(shí)現(xiàn)
• 這應(yīng)該是Hybrid模式的最多一個(gè)好處了,因?yàn)檫@種模式是原生混合web,所以我們完全可以將交互強(qiáng),性能要求高的頁(yè)面用原生寫,然后一些其它頁(yè)面用JS寫,嵌入webview中,達(dá)到最佳體驗(yàn)

缺點(diǎn)

• 相比原生,性能仍然有較大損耗
• 這種模式受限于webview的性能桎梏,相比原生而言有不少損耗,體驗(yàn)無(wú)法和原生相比
  不適用于交互性較強(qiáng)的app
• 這種模式的主要應(yīng)用是:一些新聞閱讀類,信息展示類的app;但是不適用于一些交互較強(qiáng)或者性能要求較高的app(比如動(dòng)畫較多就不適合)

React Native App

Facebook發(fā)起的開(kāi)源的一套新的APP開(kāi)發(fā)方案,Facebook在當(dāng)初深入研究Hybrid開(kāi)發(fā)后,覺(jué)得這種模式有先天的缺陷,所以果斷放棄,轉(zhuǎn)而自行研究,后來(lái)推出了自己的“React Native”方案,不同于H5,也不同于原生,更像是用JS寫出原生應(yīng)用,有如下優(yōu)點(diǎn)和缺點(diǎn)，其實(shí)很多大公司都已經(jīng)轉(zhuǎn)React Native開(kāi)發(fā)了,已經(jīng)很成熟了稻薇。

優(yōu)點(diǎn)

• 雖然說(shuō)開(kāi)發(fā)成本大于Hybrid模式,但是小于原生模式,大部分代碼可復(fù)用
• 相比于原生模式,這種模式是統(tǒng)一用JS寫代碼,所以往往只需要一名成員投入學(xué)習(xí),即可完成跨平臺(tái)app的開(kāi)發(fā),而且后續(xù)代碼封裝的好,很多功能可復(fù)用
• 性能體驗(yàn)高于Hybrid,不遜色與原生
• 這種模式和Hybrid不一樣,Hybrid中的view層實(shí)際上還是dom,但是這種模式的view層是虛擬dom,所以性能要高于Hybrid,距離原生差距不大
• 這種模式可以認(rèn)為是用JS寫原生,即頁(yè)面用JS寫,然后原生通過(guò)Bridge技術(shù)分析JS,將JS內(nèi)容單獨(dú)渲染成原生Android和iOS,所以也就是為什么性能不遜色原生
• 開(kāi)發(fā)人員單一技術(shù)棧,一次學(xué)習(xí),跨平臺(tái)開(kāi)發(fā)
• 這種模式是統(tǒng)一由JS編寫,有著獨(dú)特的語(yǔ)法,所以只需要學(xué)習(xí)一次,即可同時(shí)開(kāi)發(fā)Android和iOS
  社區(qū)繁榮,遇到問(wèn)題容易解決
• 這應(yīng)該是React Native的很大一個(gè)優(yōu)勢(shì),不像Hybrid模式和原生模式一樣各自為營(yíng),這種模式是Facebook統(tǒng)一發(fā)起的,所以有一個(gè)統(tǒng)一的社區(qū),里面有大量資源和活躍的人員,對(duì)開(kāi)發(fā)者很友好

缺點(diǎn)

• 雖然可以部分跨平臺(tái),但并不是Hybrid中的一次編寫,兩次運(yùn)行那種,而是不同平臺(tái)代碼有所區(qū)別
• 這種模式實(shí)際上還是JS來(lái)寫原生,所以Android和iOS中的原生代碼會(huì)有所區(qū)別,如果需要跨平臺(tái),對(duì)開(kāi)發(fā)人員有一定要求
  當(dāng)然了,如果發(fā)展了有一定時(shí)間,組件庫(kù)夠豐富了,那么其實(shí)影響也就不大了,甚至?xí)菻ybrid更快
• 開(kāi)發(fā)人員學(xué)習(xí)有一定成本
• 雖然社區(qū)已經(jīng)比較成熟了,但是一個(gè)新的普通前端學(xué)習(xí)起來(lái)還是有一定學(xué)習(xí)成本的,無(wú)法像Hybrid模式一樣平滑

分析

各大開(kāi)發(fā)模式直觀對(duì)比

• 以下是各大模式的直觀對(duì)比分析

如何選擇開(kāi)發(fā)模式

目前有多種開(kāi)發(fā)模式,那么我們平時(shí)開(kāi)發(fā)時(shí)如何選擇用哪種模式呢嫂冻？如下

選擇純Native App模式的情況

• 性能要求極高,體驗(yàn)要求極好,不追求開(kāi)發(fā)效率
• 一般屬于吹毛求疵的那種級(jí)別了,因?yàn)檎?lái)說(shuō)如果要求不是特別高,會(huì)有Hybrid

選擇Web App模式的情況

• 不追求用戶體驗(yàn)和性能,對(duì)離線訪問(wèn)沒(méi)要求
• 正常來(lái)說(shuō),如果追求性能和體驗(yàn),都不會(huì)選用web app
• 沒(méi)有額外功能,只有一些信息展示
• 因?yàn)閣eb有限制,很多功能都無(wú)法實(shí)現(xiàn),所以有額外功能就只能棄用這種方案了

選擇Hybrid App模式的情況

• 大部分情況下的App都推薦采用這種模式
• 這種模式可以用原生來(lái)實(shí)現(xiàn)要求高的界面,對(duì)于一些比較通用型,展示型的頁(yè)面完全可以用web來(lái)實(shí)現(xiàn),達(dá)到跨平臺(tái)效果,提升效率
• 當(dāng)然了,一般好一點(diǎn)的Hybrid方案,都會(huì)把資源放在本地的,可以減少網(wǎng)絡(luò)流量消耗

選擇React Native App模式的情況

• 追求性能,體驗(yàn),同時(shí)追求開(kāi)發(fā)效率,而且有一定的技術(shù)資本,舍得前期投入
• React Native這種模式學(xué)習(xí)成本較高,所以需要前期投入不少時(shí)間才能達(dá)到較好水平,但是有了一定水準(zhǔn)后,開(kāi)發(fā)起來(lái)它的優(yōu)勢(shì)就體現(xiàn)出來(lái)了,性能不遜色原生,而且開(kāi)發(fā)速度也很快

另類的app方案

除了以上的幾種常見(jiàn)app開(kāi)發(fā)模式,其實(shí)還有一些其它的類似方案

微網(wǎng)頁(yè)

• 比如在進(jìn)行微信網(wǎng)頁(yè)開(kāi)發(fā)時(shí),可以調(diào)用一些微信的特殊api,這其實(shí)就是算是微信的Hybrid模式,實(shí)質(zhì)上仍然是在瀏覽器中(只不過(guò)是騰訊的X5內(nèi)核)

• 當(dāng)然了,微信在這方面做了很多限制,比如權(quán)限認(rèn)證等等,所以導(dǎo)致開(kāi)發(fā)起來(lái)效果不是很完美。這里不再贅述其功能

微信小程序

• 微信小程序是微信新推出的一種新的app方案,2016年9月開(kāi)始進(jìn)行內(nèi)測(cè),2016年11月準(zhǔn)備全面面向開(kāi)發(fā)者需要注意的是,這種模式是“反HTML5”的,相當(dāng)于是微信提供的一套封閉開(kāi)發(fā)模式,有自己的語(yǔ)法和IDE,有的類似于iOS開(kāi)發(fā)的感覺(jué)塞椎。具體也不贅述,請(qǐng)參考引用來(lái)源中的文章