HTML5實現APP和原生方式有多大差距，多少坑？

01-14

寫過一些純H5的APP，雖然開發起來的確很快很舒服，但和原生比起來純H5APP還是有很多問題，主要聚集在以下幾個方面：

1、動畫

動畫有很多種，比如側邊欄菜單的滑入滑出、元素的響應動畫、頁面切換之間的過場等等，在H5之下的眾多實現方法都沒有辦法達到純原生的性能。一般這些的話有幾種不同的選擇：css3動畫，javascript動畫，原生動畫。

css3動畫非常的消耗性能，如果某一個元素用到css3動畫可能還看不出來，但大面積或過場使用css3動畫會讓app低端手機體驗非常差。最好的選擇一般是通過框架調用底層的動畫，但不管怎麼樣等於在原來的代碼上包上了一層，性能還是不可避免的受到影響。

比如在一個新頁面的載入上，如果調用底層動畫要考慮的問題有兩個，一個是本身資源頁面的渲染問題，另一個是遠程數據的獲取。即便是這些動畫能夠很快的響應，但大量的css頁面會導致渲染卡頓，滑入時可能會有白屏/機器卡頓的現象。為了解決這些性能問題又必須要用到預載入或模擬動畫。即便是這樣，滑入滑出的動畫在低端的安卓機器上還是有很多問題，如果獲取服務端數據處理的方式不合適，卡頓白屏的現象會更嚴重。具體看下面的數據獲取方式。

2、獲取服務端數據

首先要接受的是，這裡的數據獲取都是在資源頁面上非同步完成的，因為只有這樣才能讓這些資源頁面完成預載入或者渲染。但是非同步拿到的數據在填入頁面中時可能會涉及DOM操作，眾所周知，DOM操作非常消耗性能，如果頁面小還好，頁面稍大數據稍微複雜一點，頻繁的DOM操作會導致明顯的閃白。

而且最重要的一點是，如果頁面載入進來之後數據更新的速度太慢，也會讓頁面模板等待很長時間，對用戶體驗又不友好，總不能每次打開都像瀏覽器一樣等待刷新是吧。

這個問題如果沒有得到解決，H5APP是很難承擔大規模數據的頁面，在它們之中頻繁切換更是難上加難，那麼肯定有人也會想到用MVVM的方式，其實我也寫過一些基於MVVM的H5APP，相對來說它們獲取數據和更新數據的方式更敏捷更科學，但寫的過程中又要注意很多H5獨有的問題，這些問題在下面的頁面切換里來講。

3、頁面切換

上面我們看到了幾種不錯的實現方式，比如預載入和模擬動畫，甚至有批量的預載入，批量的截圖模擬動畫等等，雖然看起來很友好解決了不少問題，但事實上如果頁面足夠多就會引發另一個問題：頁面的生存周期。

試想一下，如果引導頁或者主頁面緩存了5個子頁面的資源，在跳轉到響應的子頁面時又會緩存這些子頁面的下級頁面資源，如此反覆肯定會佔據大量內存使APP的體驗下降。那麼怎麼知道那些頁面是需要的，最多緩存多少頁面，什麼時候結束哪些頁面的生存周期呢？在我用過的很多H5APP的框架里都沒有對這些問題有一個完美的解答，因此在頁面較多內容較多的APP中可能會因這些資源分配的問題降低性能。

這時候我們回過頭來再看看MVVM的數據載入問題，實際上不管哪個MVVM框架，寫過的人都知道管理這種新型的前端代碼最重要的問題是內存的問題，你既要保證代碼寫的足夠優雅沒有任何內存泄露問題，也要考慮到在頁面生存周期結束時它們的控制器/頁面資源是否得到釋放，這對全局有沒有什麼影響，在多個請求時也要合理的分配資源，甚至是復用這些父級頁面傳過來的緩存資源等等。較小的APP可能並不會有這些問題，如果你想用純H5來開發大型APP，這很可能會浪費你很多時間——而且結果還不會讓你滿意。

4、Android/iOS的區別

很多人都說純H5APP一次編寫就能編譯Android/iOS兩種不同的APP，大大降低了成本。實際上這個觀點本身就是值得懷疑的，如果你寫過這類APP就能明白我在說什麼，它們既不省事，又存在很多BUG，調試時尤其繁瑣。

舉一個很簡單的例子，Android和iOS在返回上一頁的處理方式上就有明顯的區別，iOS的頂部bar在全屏下怎樣處理，Android機器出現smart bar怎樣處理頁面的布局，調用底層硬體時怎樣區分不同的場景等等，你需要寫一個又一個機型和系統的判斷，然後分別在Android和iOS下調試，最後你卻發現這並沒有卵用，累的要死卻什麼沒學到，只有一堆不知道什麼時候會過時的經驗。

現在做H5混合APP開發的人很多，但是純H5卻很年輕，很多問題都沒有很好的解決，這幾個是我在做這些APP時考慮最多的問題。當然大家也不必擔心，隨著ES6的推行，硬體發展越來越快，純H5APP未必沒有一席之地。最後說一個很少人注意到的H5優勢，大家大談H5APP時都是快速開發、低成本、多平台等等，但我卻覺得它和很多APP開發方式相比有一個不同之處——圖文混合的排版。

正是這些複雜多變的CSS樣式消耗了性能，但是它帶來了排版的多樣性，能夠細緻到每一個字寬行高和風格的像素級處理，才是H5的優異之處。

我試過用國內的 HBuilder + MUI 框架開發，也試過 Cordova + React for Web 開發。現在手上的某App，正在同步使用 Cordova + React 和 React Native 分別開發 UI 層（邏輯層代碼公用）。當然，都是小型應用，還不需要像 @李維特寫的一樣考慮頁面切換等問題……

我的結論是：坑、好大的坑、虎紋大坑。

才疏學淺，只總結出以下問題：

1. 性能問題

先是動畫。

無論是 CSS3 動畫、還是 Canvas 動畫，還是 JavaScript 操作 DOM 的動畫，都卡；後者尤甚。高端機尚可，低端機是可以卡成幻燈片的。我錄過 GIF，使用的設備是台電P88，全志 CPU 。大概就是這樣：http://zsxsoft.qiniudn.com/upload_images/2015/08/201508158461_695.gif

其次，是 DOM 性能問題。

感謝 React 帶來了 Virtual DOM，部分解決了局部區域 DOM 刷新時的性能問題。不過，一旦涉及到較大區域 DOM 更新，反倒有更大的性能損耗（最終計算出來的結果還是要全部替換掉，多做了一步 Diff ）。

因為性能問題，Facebook 2012年離開了 HTML5 App 陣營（Facebook: 「Betting on HTML5 Was a Mistake」）。但時至今日，還是沒有什麼改善。也分享一篇文章，可以看看坑：移動端HTML5遊戲性能優化。

這裡有個例子：微眾銀行 App 是 Cordova + Ionic + Angular。微眾很行app十分卡頓，大家覺得么？

2. 兼容問題

先只算官方系統。Android系統的 WebView 一般隨 Android 版本更新（當然，也可以自己去 Play Store 更新），每個版本所支持的功能均不同。坑的是，在國內的環境下，基本不會再更新了。有的功能，在 PC 上對應版本的Chrome 是有的，到該版本 WebView 就沒有了。

比如說，XMLHttpRequest 的 onprogress 在 Android 4.0.4 上不被支持。於是，針對這類系統，只能採用像之前對 IE 的 Hack 一樣，用 iframe 來替代進度條。

再比如說，ECMAScript 6 被高版本 WebView 支持。如果開發者寫慣了後，引入了 Symbol 等，又忘記了 polyfill 。在低版本 WebView 就會出錯。就像我這樣：& doesn"t support old browsers. · Issue #1685 · callemall/material-ui · GitHub

接著呢，感謝 ROM 廠商亂改系統自帶的 WebView ，從而導致在各種小細節上不同手機的顯示效果或運算結果不同。更倒霉的是，有的甚至還會全頁面混亂。

怎麼解決？個人認為，像微信那樣自帶一個 X5，也許算是一個解決方案吧。

至於兼容問題的例子，還是微眾銀行好了：https://www.v2ex.com/t/215728 （與新版 iOS 9 的 WebView 不兼容）

3. 調試問題

先吐槽：Android 5.0+ 的系統內的 WebView ，可以用 Chrome for PC 來調試。但需要翻牆。

調試分調試 JavaScript 和界面兩方面。

JavaScript 方面，如果 throw 出一個錯誤，很可能剩下的事情你都幹不了了。手機端的表現就是什麼操作都沒用，也不會崩潰退出之類。在開發時，對於 JavaScript 報錯，MUI 和 Cordova 均可以通過 adb logcat 來檢查報錯；Release 後可就沒辦法找用戶連 USB 了。weinre 等工具對於 JavaScript Debug 沒啥用。

那 weinre 幹啥用？只是讓你看 DOM 層級或動態執行代碼罷了。這就是 UI 方面的調試了。這部分的話，考慮到兼容問題，自求多福吧……

Cordova 提供了 Ripple，倒的確是一個很不錯的解決方案。但是並不能涵蓋所有的手機……

4. 代碼安全性問題

正如.apk -&> .dex -&> .jar -&> .class -&> .java一下就能把代碼全部拿出來看一樣，.apk -&> .js 更為方便，解壓一下就好了。於是，在 Release 前，必須 gulp / grunt 構建工作流，把 uglify 之類全部一股腦塞進去。這部分和做網頁前端沒啥區別，差別大概只有不需要考慮代碼切分等（畢竟沒有網路，全在本地）。

然而，這樣的代碼，修改成本非常低。比如我做一個付費的本地遊戲，只要簡單地修改一下.js，輕輕鬆鬆破解驗證等後重新打包回去，破解版遊戲就做好了，比 Java 的簡單多了。就算有 C++，我 js 不調用你，你又奈我何？沒有伺服器驗證的話，玩蛋去吧。

5. 功能問題

如果沒有 Native Code，一切HTML5 App都是空架子。所以，Java / Objective-C / C#仍然是必須學習的語言；Native App 如何開發也仍然是必修。比如以下代碼，就是在 MUI 里用原生瀏覽器打開一個鏈接。

function openInBrowser(originalUri) { var Intent = plus.android.importClass("android.content.Intent"); var main = plus.android.runtimeMainActivity(); var Uri = plus.android.importClass("android.net.Uri"); var uri = Uri.parse(originalUri); var intent = new Intent(Intent.ACTION_VIEW, uri); main.startActivity(intent); }

當然，Cordova 就得寫 plugin 了，更為繁雜。

大概就是這樣 _(:з」∠)_ 求輕噴。

（話說我tm在複習呢寫答案合適么？！）

我們看一個栗子吧：

早在2010年的時候，喬布斯就預言HTML5將會成為取代Flash的下一波技術浪潮。從那時候開始，

其後很多大公司都在推動HTML5的發展，其中以Facebook的小扎最為瘋狂，作為技術極客的他誓要利用HTML5的Web App來打破iOS和Android的壟斷，

可憐的小扎，

為什麼叫小扎呢，

因為小扎近些年最大的失誤便是押注於HTML5，浪費了長達2年的研發投入和精力，而才轉向原生應用。

直到2012年因為該公司對市場上所有 JavaScript MVC 框架，都不滿意，就決定自己寫一套，用來架設Instagram 的網站。做出來以後，發現這套東西很好用，這就是現在耳熟能詳的React JS
當時還有一個小插曲，時至2010年左右移動應用的浪潮已經席捲了整個互聯網界，因為小扎選擇了HTML5技術作為底層，其App因其HTML5自身技術的問題導致經常出現Bug，對Facebook這麼大體量的產品而言，必然會受到重創，期間因此而差點引發被雅虎收購的命運，整個事件要告記廣大創業者，選擇底層架構需謹慎！

既然樓主著重提到「HTML5實現APP和原生方式有多大差距，多少坑？」

1.過分依賴網路

2.渲染性能較弱

3.頁面過多

4.標籤太多，代碼量也不少

5.不支持離線模式;

6.消息推送不夠及時

要說有坑，最大的坑還是bug可以線上fix了，於是經常會被半夜喊起來改bug……

雖然有坑，跳進去，總比站在坑外等死強！隨著各類APP 框架的出現，已經越來越完美的解決了HTML5開發APP的短處，至少說不會JAVA、不會OBJECT-C的人，也能搭上一條船，誰也不知道船能走多遠，走多快，覺得這個是方向就勇敢的去嘗試

贊同樓上幾位的看法，h5的優勢是圖文混排，開發的便利性，以及豐富活躍的前端社區，最起碼對於前段來說不同的屏幕，用css布局極其方便。我用過hbuilder，cordova，apicloud之類的，覺得目前最成熟可靠的方案是cordova，無論是插件的質量，還是社區的活躍度，都是其他無法比擬的，最起碼你要踩的坑google一下，別人都踩過了，有了解決方案。

至於框架組合，我推薦vue+framework7，用的很順手。android統一推薦搭配crosswalk，性能有明顯提升，這也是用cordova的一大優勢。樓上說的兼容性，我這倒是沒啥問題，android，ios都成功上架了。

這個坑還挺大的，如果業務邏輯、界面渲染比較複雜，對動畫有要求的話，H5會遇到很多問題。

前面也有答主說了，webview的性能問題，高端機和低端機差異很大，安卓5之後和安卓5之前差異也大。這裡補充一點，安卓的微信用的QQ瀏覽器X5內核也是一個巨坑，如果應用要求用微信訪問的話，簡直痛苦。

相對來說IOS就好很多，除了i4和以下的性能不夠以外。

目前我們用framework7的ui框架+react開發，phonegap打包，輕量級應用沒什麼問題。

額外說說framework7框架，有IOS和Meterial兩種風格，我們只用了IOS的，因為Meterial動畫元素太多，低端機卡成狗了要…

用快站直接封裝。

混合開發的，我們ui設計切圖可就有點麻煩了？

HTML5 屬於萬維網聯盟 (W3C), 這個組織為整個網路界提供了標準，如此形成的協議可在全世界通行。在 2016 年 11 月， W3C 對長期行使的 HTML 5 標準進行了更新，它是2年內的第一次小更新。許多最開始提出的 HTML 5.1 功能特性都因為設計上的缺陷和缺乏瀏覽器廠商的支持而去掉了。W3C 以及開始著手發展 HTML 5.2 草案，有望於 2017 年底發布。而我們在這裡所要呈現的是在版本 5.1 中被引入的新的功能特性和功能提升。你不需要動 JavaScript 就可以利用上這些功能特性。並非所有的瀏覽器都支持這些功能特性，因此你最好是在將它們應用於生產環境之前先檢查一下瀏覽器的支持情況。看薦-黑板報

最近也算晚的比較多了，碰到幾個神奇的坑

1、軟鍵盤

彈出來回不去，blur事件時有時沒有，額，簡直想砸手機

2、動畫點不到

animation中的元素點不到，媽蛋，怎麼點都不容易點中，ios尤其悲劇

3、內存

用angularjs一下，不控制內存就搞崩了

4、css

各種css的不兼容的坑，響應式也要根據不同機型來做適配，簡直生不如死

H5 APP 最大的兩個坑，一個是 CSS，一個是DOM。

DOM 的設計初衷是跟交互體驗相駁斥的。

我們直接用 canvas / webgl 渲染引擎做 H5 APP，在 ios 和安卓5 以上的設備體驗跟原生APP基本無差，在交互體驗上能夠好過原生APP。但是缺點是控制項太少，很多需要自己寫。可以用的渲染框架有很多，比如: cocos2d-html5, pixijs, two.js

我疑惑的是h5的我們設計該以哪個尺寸的設計稿來設計，切圖又如何？做設計需不需要考慮系統的差異？

平台標準不統一，性能差異性過大，等等等等，反正各種神坑坑的連骨頭渣都不剩