現(xiàn)有3類主流APP，分別為：Web App、Hybrid App（混合模式移動應(yīng)用，Hybrid有“混合的”意思）、 Native App（原生app，后面都用“原生app”來描述）。Web App和原生app有很多大牛們都做過比較詳細的比較以及優(yōu)劣勢分析，我主要對Hybrid App來簡要分析下，談?wù)凥ybrid App里原生頁面和H5頁面的比較和分析。

Hybrid APP指的是半原生半Web的混合類App。需要下載安裝，看上去類似Native App，但只有很少的UI Web View，訪問的內(nèi)容是 Web 。

現(xiàn)在不少app已經(jīng)使用H5頁面來代替原生頁面（即Hybrid APP），兩種方式具有不同的用戶體驗。剛好最近遇到公司想用H5頁面來代替原生頁面，了解了下，并把所有的問題以及知識點都記錄下來。

原生頁面和H5頁面的優(yōu)劣勢分析

其各自的優(yōu)劣勢也有很多前輩都已經(jīng)總結(jié)過了，我稍微記錄并歸納下（本文中的相對/相比較都是針對這兩種方式而言的）。

原生頁面

優(yōu)勢：

（1）運行速度比較快

（2）能使用設(shè)備的底層功能，如攝像頭、方向傳感器、重力傳感器、撥號、GPS、語音、短信、藍牙等

（3）在界面設(shè)計、功能模塊、操作邏輯等層面相較web更易做到App的便捷性和舒適性，功能更加強大

（4）節(jié)省流量

劣勢：

（1）不同的操作系統(tǒng)（如Android和iOS）需要獨立的進行開發(fā)，使用其各自的開發(fā)包、開發(fā)工具和控件

（2）每次有更新，都需要重新打包一次發(fā)布到應(yīng)用平臺上，且每次要向各個應(yīng)用商店進行提交審核。之后用戶需要手動進行點擊更新安裝（安裝成本較高）

（3）開發(fā)成本比較高，尤其需要適配各種機型時（如Android應(yīng)用，需要適配各種Android手機）

H5頁面

優(yōu)勢：

（1）由于是運行在瀏覽器上，所以只需要開發(fā)一次便可以在不同的操作系統(tǒng)上顯示

（2）迭代版本時，不需要打包便可以發(fā)布（實時更新、快速迭代），與云端實現(xiàn)實時數(shù)據(jù)交互

（3）開發(fā)成本相對較低，對瀏覽器的適配較簡單，且發(fā)布門檻相對較低

劣勢：

（1）每次打開頁面，都得重新加載，獲取數(shù)據(jù)…

（2）過于依賴網(wǎng)絡(luò)，速度無法保證。特別在弱網(wǎng)環(huán)境下，不僅耗費流量而且加載緩慢，就算是WiFi情況下也不容樂觀

（3）只能使用有限的設(shè)備底層功能（無法使用攝像頭、方向傳感器、重力傳感器、撥號、GPS、語音、短信、藍牙等功能）

（4）仍處于發(fā)展階段，部分功能無法在基于現(xiàn)有技術(shù)的瀏覽器基礎(chǔ)上實現(xiàn)，且無法全面的顯示最完美的用戶體驗，只能用現(xiàn)有技術(shù)去彌去找最佳解決方案

如何區(qū)分Hybrid APP中的原生頁面和H5頁面

一直在想一個問題，原生頁面和H5頁面到底是憑啥區(qū)分的？看了網(wǎng)上很多大牛是從頁面的設(shè)計上來區(qū)分的。如：（1）頂部顯示網(wǎng)頁鏈接；（2）有加載的進度條；（3）沒有底部tab導(dǎo)航欄；（4）頂部顯示兩個導(dǎo)航條；（5）有懸浮圓圈/標(biāo)識；等可以區(qū)別出H5頁面的幾種方式。然而現(xiàn)在越來越多的應(yīng)用開始弱化這些表象。【Hybrid App里面一般（1）、（2）、（4）點已經(jīng)被弱化，除了微信（等..），用的還是加載進度條（微信的加載進度條簡直要逼瘋我的節(jié)奏，特別是網(wǎng)速特別慢的情況下，就眼睜睜看著他到不了盡頭）】

附上微信的進度條….（已醉）

下面，以淘寶為例，給大家看看…真的是怎么都識別不出來?。?！

由上圖得知，是否有懸浮圓圈/標(biāo)識無法區(qū)別出H5頁面

由上圖得知，是否有底部tab導(dǎo)航欄也無法區(qū)別出H5頁面。

問了公司的程序員，結(jié)果還是一頭霧水，只有灰溜溜的去尋求度娘的幫助，果然找到了。

設(shè)置-開發(fā)者選項-顯示布局邊界

H5中使用了webview控件，其作為一個控件，只有一個邊界框，所以通過這一點，就比較容易區(qū)分出一個界面是webview實現(xiàn)的還是原生布局控件實現(xiàn)的，當(dāng)然也不排除用一堆webview來拼成一個界面的實現(xiàn)方法。

如下圖是一個原生與webview混排的界面，紅色線框是各控件的繪制邊界，中間那一大塊布局豐富的界面沒有顯示出很多邊界紅色，就是H5實現(xiàn)的。

原生頁面還是H5頁面？

對這兩種開發(fā)模式分別進行比較，分別得出幾種各自適用的場景

選擇原生頁面的幾點理由：

1.使用定位功能

如果需要用到GPS定位功能，以前只能使用原生的API來查看用戶的位置信息，但現(xiàn)在大多數(shù)的主流瀏覽器上都嵌入了W3C Geolocation API。安裝了WebKit的設(shè)備或是配置了Opera或Mozilla瀏覽器的設(shè)備，均可以獲取用戶的位置信息。這在技術(shù)上已經(jīng)沒有太大的困難，然而卻受到隱私保護條例的限制。加入定位功能，意味著給網(wǎng)站引入了一些敏感信息，可能會導(dǎo)致嚴重的后果。而原生app的位置信息必須經(jīng)過用戶授權(quán)，排除了隱患。

2.使用攝像頭

如果需要用到攝像頭功能，原生開發(fā)者能夠簡化拍照的過程，直接在客戶端對照片做一些處理，只有需要的時候才上傳服務(wù)器。W3C正在開發(fā)一個訪問攝像頭的API，但現(xiàn)在還沒有將這部分工作正式整合到瀏覽器中。

3.使用感應(yīng)器（方向傳感器、重力傳感器等）

4.訪問文件系統(tǒng)

訪問文件系統(tǒng)常會涉及到安全和用戶隱私保護的問題。惡意應(yīng)用程序可能會修改或刪除你的數(shù)據(jù)。移動設(shè)備越來越私人化，在移動設(shè)備上保存了大量用戶的個人信息、朋友信息及商業(yè)信息，保存在本地的數(shù)據(jù)更加安全且可以為用戶提供更加有針對性的服務(wù)，這要求開發(fā)者須獲得用戶的授權(quán)后才能訪問用戶的私人數(shù)據(jù)。則原生app更容易做到這點

訪問文件系統(tǒng)時至關(guān)重要的一點就是在沒有獲得用戶授權(quán)的情況下，不要訪問任何用戶的私人數(shù)據(jù)。而這一點，往往被大多數(shù)應(yīng)用忽略了。W3C正在為移動開發(fā)商開發(fā)相關(guān)的標(biāo)準(zhǔn)API，但目前該工作尚未完成。

5.提供離線服務(wù)

使用原生頁面可以將數(shù)據(jù)保存在本地并進行讀取，可以實現(xiàn)離線服務(wù)，在無網(wǎng)或弱網(wǎng)情況下，更深得用戶喜愛。

選擇H5頁面的幾點理由：

1.功能開發(fā)不完善，試運營階段（試錯成本低），快速收集用戶反饋信息及時更新

2.應(yīng)用須適應(yīng)多個操作系統(tǒng)，且資源/預(yù)算有限制

3.技術(shù)強，能夠極力解決由網(wǎng)速引起的頁面不順暢問題

4.不滿足原生app條件之一，且能做到第三點的完善，并隨著越來越豐富的功能接口可供開發(fā)者調(diào)用，web app比原生app更合適

5.非核心需求，在功能調(diào)整或內(nèi)容的運營上很靈活

6.階段性的營銷活動，希望被分享出去

總結(jié)

我覺得混搭使用這兩種開發(fā)模式是最符合當(dāng)下web技術(shù)發(fā)展以及app的發(fā)展背景的，像淘寶就把原生頁面和H5頁面融合的天衣無縫，也盡可能的用技術(shù)解決了H5頁面的劣勢問題。當(dāng)然，各企業(yè)需要根據(jù)自身的條件以及戰(zhàn)略來選擇適合自己的開發(fā)模式，合理配置資源。

對于Hybrid APP，對H5頁面有幾個注意點

H5頁面的幾個動效設(shè)計優(yōu)化點：

1.盡量使用比較簡單的動效，不要求做到酷炫，但求做到好用就行

2.頂部標(biāo)題欄盡量使用原生的（這樣在網(wǎng)速渣，內(nèi)容沒刷出來的情況下，也可以快速返回，不流量）

3.不要使用瀏覽器進度條加載方式，用下拉刷新的方式（和原生保持一致，不讓用戶有瀏覽網(wǎng)頁的感覺，而是在使用app）

4.少用手勢，以防與瀏覽器手勢沖突

H5頁面的幾個技術(shù)優(yōu)化點：

1.優(yōu)先顯示框架，內(nèi)容可以緩慢加載顯示出來

2.模塊化你的 H5 頁面/應(yīng)用，引入模塊加載器（可選）

模塊加載器如SeaJS、requireJS、kissy loader 等。使用模塊化的方式來開發(fā)你的應(yīng)用，不僅僅將有利于后期的代碼維護，在 Hrbrid 的架構(gòu)中，還將會有利于性能的提升。

疑問：模塊開發(fā)粒度越細化，加載時請求的JS、CSS等靜態(tài)資源的數(shù)量越多，頁面的性能不會越差嗎？

答：如果你僅僅是使用了模塊加載器并異步加載各個模塊，那么加載的性能一定很差，因為請求的數(shù)量太多。當(dāng)然你肯定會想到在發(fā)布前打包合并靜態(tài)資源，那么對這樣的解決方案我只能給到 50 分，因為被打包合并的文件中只要有一個子文件發(fā)生變化，那么整個文件（JS或CSS）都要被重新下載，對移動帶寬而言還是個負擔(dān)。

怎么破？請看第3點—

3.啟用 AppCache ，并引入增量更新機制

做過 WebApp 的同學(xué)應(yīng)該會了解mainfest文件，Html5提供的應(yīng)用緩存功能，開發(fā)者只要把需被緩存的靜態(tài)資源文件名羅列在這個列表中即可保證二次訪問時無需重新加載?？雌饋聿诲e！這樣前面說的模塊化開發(fā)造成的請求數(shù)量過多的問題，至少在二次訪問時不會再發(fā)生了。嗯，這樣的方案可以給到 70 分吧。其實，Html5 提供的 mainfest 緩存機制有個比較大的問題（兼容性就先不提了）：如果 mainfest 列表中的一個資源文件需要更新，那么整個 mainfest 中的其它文件也都需要被重新下載一遍。 也即是說二次訪問沒有問題了，但是 Html5 應(yīng)用更新時還是會出現(xiàn)全量下載的問題。

別忘了，我們是 Hybrid App，還可以充分利用 原生層的強大能力，所以拋棄mainfest吧，讓原生來幫助 Html5 應(yīng)用緩存靜態(tài)資源文件?？傮w思路是：

（1）、Html5 應(yīng)用首次啟動時，調(diào)用 原生提供的加載資源文件專用的 Device API 來請求所需的資源文件，由原生層發(fā)出真正的資源請求，并將請求結(jié)果緩存在手機的SD卡上。當(dāng)然，這里完全可以優(yōu)化為一次 zip 包請求，因為原生能夠提供強大的解壓能力。

（2）、H5 應(yīng)用再次啟動時，所有的靜態(tài)資源都是通過 Device API 讀取本地緩存，無需再走網(wǎng)絡(luò)。

（3）、H5 應(yīng)用出現(xiàn)靜態(tài)資源更新時，在應(yīng)用啟動時首先通過 Device API 加載需要更新的文件，并更新本地緩存，其它未變更文件繼續(xù)走緩存。

流程看起來挺順，其中有幾個關(guān)鍵問題需要解決：

（1）、如何通過 Device API 加載資源文件？

這里使用模塊加載器的優(yōu)勢就體現(xiàn)出來了，只需要在加載器中做點小修改，不直接走Http請求了，而直接調(diào)用原生提供的文件加載 DeviceAPI 即可。?如果你沒有模塊加載器，就需要寫統(tǒng)一的函數(shù)來做加載資源的功能了。

其實原生也提供了攔截機制，能夠攔截到 H5 應(yīng)用發(fā)出的所有 Http 請求并進行自定義處理，可惜這樣好的功能在 Andorid 4.0 以下版本不支持。?故現(xiàn)階段還是主動調(diào)用 Device API 更靠譜。

（2）、何時需要進行靜態(tài)資源的更新？

每次靜態(tài)資源發(fā)布都會產(chǎn)生一個唯一的發(fā)布時間戳（或是所有資源內(nèi)容的MD5編碼），H5應(yīng)用啟動后，可將當(dāng)前時間戳保存下來，等應(yīng)用下次啟動時，請求最新的發(fā)布時間戳并與本地時間戳進行對比，若不同，則首先進行靜態(tài)資源的增量更新。

（3）、如何判斷哪些是需要被增量更新替代的靜態(tài)資源文件？

這個問題的回答會比較復(fù)雜些，核心思路是通過對前后兩次資源文件（js、css、image等）發(fā)布的內(nèi)容對比完成：

如此，H5 應(yīng)用借助原生應(yīng)用的能力完成了資源的緩存與增量更新，可以保證 H5 應(yīng)用在啟動與更新時的加載速度。當(dāng)然也有方案借助 HTML5 的 localstorage 來替代 Native 的緩存更新策略，但是可能會受到兩處限制：

1）、若 Hybrid App 比較復(fù)雜，涉及多個子域甚至主域間的靜態(tài)資源共享，則 localstorage 的方案首先要解決跨域訪問的問題，并且在每個子域存儲空間上存在上限，是 5M。

2）、原生能夠支持更新包的 zip 打包下載，一次請求，然后解壓并更新本地緩存。而 localstorage 無法實現(xiàn)。

若應(yīng)用中以上兩點不是問題，則使用 localstorage 緩存的策略完全 OK。

4.啟用 spdy 協(xié)議

spdy協(xié)議在移動開發(fā)上大有可為，它是HTTP協(xié)議的增強版本，能夠通過一次TCP鏈接同時請求到多個資源文件，請求速度上的提升那是自然的了，非常強大！chrome 等 webkit 內(nèi)核瀏覽器都已經(jīng)支持。 可惜若是借助瀏覽器自身使用 spdy 協(xié)議則要求靜態(tài)資源服務(wù)（js、css、image）必須是 https 的域名服務(wù)，且后臺server能支持spdy協(xié)議。相信大多數(shù)靜態(tài)服務(wù)器都還是http 服務(wù)，是無法通過瀏覽器來直接支持的。

還是那句話，因為我們是 hybrid 應(yīng)用，可以發(fā)揮native的優(yōu)勢！ native 層完全可以實現(xiàn)基于 spdy 協(xié)議請求的 device API，供 H5 應(yīng)用（JS）來調(diào)用。這樣就不需要 https 域名服務(wù)器也能使用 spdy了。

如果你的 Hybrid 應(yīng)用已經(jīng)支持了 spdy 協(xié)議，那么你可以考慮不再需要把增量更新的資源文件打包成 zip 下載了，直接 spdy 協(xié)議并行下載即可！

SPDY 與 HTTP 協(xié)議速度對比：

參考Hybrid 架構(gòu)下的 H5 應(yīng)用加速方案

最后提供一個工具：百度Site App（簡而言之就是將網(wǎng)站變成webapp）

擴展鏈接：

再次對比：原生APP和Web APP的區(qū)別

web app與app的區(qū)別，即html5與app的區(qū)別

Web APP與Native APP原生開發(fā)模式的區(qū)別

超贊！聊聊WEB APP、HYBRID APP與NATIVE APP的設(shè)計差異

Hybrid 架構(gòu)下的 H5 應(yīng)用加速方案

作者：小圣

來源：http://www.jianshu.com/p/00ff5664e000