Hybrid App中原生頁面 VS H5頁面

Hybrid App中原生頁面 VS H5頁面

 

      現有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頁面的幾種方式。然而如今愈來愈多的應用開始弱化這些表象。【Hybrid App裏面通常（1）、（2）、（4）點已經被弱化，除了微信（等..），用的仍是加載進度條（微信的加載進度條簡直要逼瘋個人節奏，特別是網速特別慢的狀況下，就眼睜睜看着他到不了盡頭）】

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

微信：加載進度條

下面，以淘寶爲例，給你們看看...真的是怎麼都識別不出來啊！！

淘寶：原生 vs H5

淘寶-聚划算：雙入口

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

底部H5tab導航欄

由上圖得知，是否有底部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提供的應用緩存功能，開發者只要把需被緩存的靜態資源文件名羅列在這個列表中便可保證二次訪問時無需從新加載。看起來不錯！這樣前面說的模塊化開發形成的請求數量過多的問題，至少在二次訪問時不會再發生了。嗯，這樣的方案能夠給到 70 分吧。其實，Html5 提供的 mainfest 緩存機制有個比較大的問題（兼容性就先不提了）：若是 mainfest 列表中的一個資源文件須要更新，那麼整個 mainfest 中的其它文件也都須要被從新下載一遍。 也便是說二次訪問沒有問題了，可是 Html5 應用更新時仍是會出現全量下載的問題。

別忘了，咱們是 Hybrid App，還能夠充分利用 原生層的強大能力，因此拋棄mainfest吧，讓原生來幫助 Html5 應用緩存靜態資源文件。整體思路是：

（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 協議速度對比：