本文部分轉自 ?http://www.jianshu.com/p/00ff5664e000

?

現有3類主流APP，分別為：Web App、Hybrid App（混合模式移動應用，Hybrid有“混合的”意思）、 Native App（原生app，后面都用“原生app”來描述）。

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

現在不少app已經使用H5頁面來代替原生頁面（Hybrid APP），兩種方式具有不同的用戶體驗。

原生頁面

優勢：

（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和H5頁面分享時的不同

原生頁面是通過deeplink技術找到對應的app并打開；而h5分享是通過http、https網頁鏈接（webview技術）（用瀏覽器或微信打開）

? ? 注：webview：Android內置webkit內核的高性能瀏覽器,而WebView則是在這個基礎上進行封裝后的一個 控件,WebView直譯網頁視圖,我們可以簡單的看作一個可以嵌套到界面上的一個瀏覽器控件！

?

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

---

一直在想一個問題，原生頁面和H5頁面到底是憑啥區分的？看了網上很多大牛是從頁面的設計上來區分的。如：（1）頂部顯示網頁鏈接；（2）有加載的進度條；（3）沒有底部tab導航欄；（4）頂部顯示兩個導航條；（5）有懸浮圓圈/標識；等可以區別出H5頁面的幾種方式。然而現在越來越多的應用開始弱化這些表象?！綡ybrid 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 應用緩存靜態資源文件?？傮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）

下面轉自 ?http://ask.seowhy.com/article/2541 簡而言之

開發方面

原生App

• 每一種移動操作系統都需要獨立的開發項目
• 每種平臺都需要獨立的開發語言。Java(Android), Objective-C(iOS)以及Visual C++(Windows Mobile)等等
• 需要使用各自的軟件開發包，開發工具以及各自的控件

** 移動Web App**

• 因為運行在移動設備的瀏覽器上，所以只需要一個開發項目
• 這種應用可以使用HTML5,CSS3以及JavaScript以及服務器端語言來完成（PHP,Ruby on Rails,Python）
• 這里可沒有標準的SDK，基本任意選擇別忘了有一些跨平臺的開發工具，比如PhoneGap, Sencha Touch 2，APPcan以及Appcelerator Titanium等等。

?

能力方面

原生App

• 能夠與移動硬件設備的底層功能，比如個人信息，攝像頭以及重力加速器等等

  移動Web App

• 只能使用有限的移動硬件設備功能。

?

獲取方法

原生App
- 直接下載到設備
- 以獨立的應用程序運行(并不需要瀏覽器)
- 用戶必須手動去下載并安裝這些原生App
- 有一些商店與賣場來幫助用戶尋找你的App，目前app市場不計其數，在這里不一一列舉了。

移動Web App

• 從移動設備上的瀏覽器訪問
• 不需要安裝額外的軟件
• 軟件更新只需要服務器就夠了
• 因為現在沒有什么商品或賣場提供這種App，所以如何搜索這些移動Web App相當不簡單

?

版本控制

原生App

• 用戶可以自由地選擇是否更新軟件版本，所以會出現不同用戶同時使用不同版本的情況?
  移動Web App
• 所有的用戶都是用同樣的版本

?

優勢

原生App

• 比移動Web App運行快
• 一些商店與賣場會幫助用戶尋找原生App
• 官方賣場的應用審核流程會保證讓用戶得到高質量以及安全的App
• 官方會發布很多開發工具或者人工支持來幫助你的開發

移動Web App
跨平臺開發
- 用戶不需要去賣場來下載安裝App
- 任何時候都可以發布App，因為根本不需要官方賣場的審核
- 如果你已經有了一個Web App，你可以使用 responsive web design來輔助改進(這也是優勢？)

### 缺陷
原生App
- 開發成本高，尤其是當需要多種移動設備來測試時
- 因為是不同的開發語言，所以開發，維護成本也高
- 因為用戶使用的App版本不同，所以你維護起來很困難
- 官方賣場審核流程復雜且慢，會嚴重影響你的發布進程 、

移動Web App
- 無法使用很多移動硬件設備的獨特功能
- 要同時支持多種移動設備的瀏覽器讓開發維護的成本也不低
- 如果用戶使用更多的新型瀏覽器，那問題就更不好處理了
- 對于用戶來說，這種App很難被用戶發現

原生App 與 移動Web App:您如何選擇？

所以在你準備做移動App時，你應該先問問自己以下幾個問題：、
1. 你的應用是否需要使用某些設備的特殊功能，比如攝像頭，攝像頭閃光燈或者重力加速器
2. 你的開發預算是多少？
3. 你的應用是否一定需要網絡
4. 你的應用的目標硬件設備是所有的移動設備還是僅僅只是一部分而已
5. 你自己已經熟悉的開發語言
6. 這個應用對于性能要求是否苛刻
7. 如何靠這個應用贏利我想這幾個問題應該能讓你做出明智的選擇。?

結論：

是原生App還是移動Web App，主要受商業目標，目標用戶，以及技術需要這些因素影響的。其實更多時候你也不要為選擇那種App模式煩惱，正如本文提到，類似Facebook這樣的公司就為用戶提供了兩種選擇。然而對于大部分人來說，預算，資源限制將會逼迫我們只能選擇其中一種（或者只能以其中一種為重點）。

作者：小圣
鏈接：http://www.jianshu.com/p/00ff5664e000
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。

轉載于:https://www.cnblogs.com/xhliang/p/7654636.html

總結

以上是生活随笔為你收集整理的Hybrid App中原生页面 VS H5页面（分享）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。