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

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

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

原生頁面和H5頁面的優劣勢分析

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

原生頁面

優勢：

（1）運行速度比較快

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

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

（4）節省流量

劣勢：

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

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

（3）開發成本比較高，尤其需要適配各種機型時（如Android應用，需要適配各種Android手機）

H5頁面

優勢：

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

（2）迭代版本時，不需要打包便可以發布（實時更新、快速迭代），與云端實現實時數據交互

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

劣勢：

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

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

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

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

如何區分Hybrid APP中的原生頁面和H5頁面

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

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

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

由上圖得知，是否有懸浮圓圈/標識無法區別出H5頁面

由上圖得知，是否有底部tab導航欄也無法區別出H5頁面。

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

設置-開發者選項-顯示布局邊界

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

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

原生頁面還是H5頁面？

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

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

1.使用定位功能

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

2.使用攝像頭

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

3.使用感應器（方向傳感器、重力傳感器等）

4.訪問文件系統

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

訪問文件系統時至關重要的一點就是在沒有獲得用戶授權的情況下，不要訪問任何用戶的私人數據。而這一點，往往被大多數應用忽略了。W3C正在為移動開發商開發相關的標準API，但目前該工作尚未完成。

5.提供離線服務

使用原生頁面可以將數據保存在本地并進行讀取，可以實現離線服務，在無網或弱網情況下，更深得用戶喜愛。

選擇H5頁面的幾點理由：

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

2.應用須適應多個操作系統，且資源/預算有限制

3.技術強，能夠極力解決由網速引起的頁面不順暢問題

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

5.非核心需求，在功能調整或內容的運營上很靈活

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

總結

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

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

H5頁面的幾個動效設計優化點：

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

2.頂部標題欄盡量使用原生的（這樣在網速渣，內容沒刷出來的情況下，也可以快速返回，不流量）

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

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

H5頁面的幾個技術優化點：

1.優先顯示框架，內容可以緩慢加載顯示出來

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

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

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

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

怎么破？請看第3點—

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

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

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

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

（2）、H5 應用再次啟動時，所有的靜態資源都是通過 Device API 讀取本地緩存，無需再走網絡。

（3）、H5 應用出現靜態資源更新時，在應用啟動時首先通過 Device API 加載需要更新的文件，并更新本地緩存，其它未變更文件繼續走緩存。

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

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

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

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

（2）、何時需要進行靜態資源的更新？

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

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

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

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

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

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

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

4.啟用 spdy 協議

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

還是那句話，因為我們是 hybrid 應用，可以發揮native的優勢！ native 層完全可以實現基于 spdy 協議請求的 device API，供 H5 應用（JS）來調用。這樣就不需要 https 域名服務器也能使用 spdy了。

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

SPDY 與 HTTP 協議速度對比：

參考Hybrid 架構下的 H5 應用加速方案

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

擴展鏈接：

再次對比：原生APP和Web APP的區別

web app與app的區別，即html5與app的區別

Web APP與Native APP原生開發模式的區別

超贊！聊聊WEB APP、HYBRID APP與NATIVE APP的設計差異

Hybrid 架構下的 H5 應用加速方案

作者：小圣

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