H5實現APP和原生方式有多大差距，多少坑？JS才是王道！
阿新 • • 發佈：2018-12-31
純H5的APP，雖然開發起來要比純原生開發暢快的多，但最終效果和效能還是和原生比起來還是有很多問題，主要聚集在以下幾個方面：
1、動畫
動畫有很多種，比如側邊欄選單的滑入滑出、元素的響應動畫、頁面切換之間的過場等等，在H5之下的眾多實現方法都沒有辦法達到純原生的效能。一般有這幾種不同的選擇：css3動畫，javascript動畫，原生動畫。
css3動畫非常的消耗效能，如果某一個元素用到css3動畫可能還看不出來，但大面積或過場使用css3動畫會讓app低端手機體驗非常差。最好的選擇是通過框架呼叫底層的動畫，但不管怎麼樣等於在原來的程式碼上包上了一層，效能還是不可避免的受到影響。
比如在一個新頁面的載入上，如果呼叫底層動畫要考慮的問題有兩個，一個是本身資源頁面的渲染問題，另一個是遠端資料的獲取。即便是這些動畫能夠很快的響應，但大量的css頁面會導致渲染卡頓，滑入時可能會有白屏/機器卡頓的現象。為了解決這些效能問題又必須要用到預載入或模擬動畫。即便是這樣，滑入滑出的動畫在低端的安卓機器上還是有很多問題，如果獲取服務端資料處理的方式不合適，卡頓白屏的現象會更嚴重。具體看下面的資料獲取方式。
2、獲取服務端資料
首先要接受的是，這裡的資料獲取都是在資源頁面上非同步完成的，因為只有這樣才能讓這些資源頁面完成預載入或者渲染。但是非同步拿到的資料在填入頁面中時可能會涉及DOM操作，眾所周知，DOM操作非常消耗效能，如果頁面小還好，頁面稍大資料稍微複雜一點，頻繁的DOM操作會導致明顯的閃白。
而且最重要的一點是，如果頁面載入進來之後資料更新的速度太慢，也會讓頁面模板等待很長時間，對使用者體驗又不友好，總不能每次開啟都像瀏覽器一樣等待重新整理是吧。
這個問題如果沒有得到解決，H5APP是很難承擔大規模資料的頁面，在它們之中頻繁切換更是難上加難，那麼肯定有人也會想到用MVVM的方式，相對來說它們獲取資料和更新資料的方式更敏捷更科學，但寫的過程中又要注意很多H5獨有的問題，這些問題在下面的頁面切換裡來講。
3、頁面切換
上面幾種不錯的實現方式，比如預載入和模擬動畫，甚至有批量的預載入，批量的截圖模擬動畫等等，雖然看起來很友好解決了不少問題，但事實上如果頁面足夠多就會引發另一個問題：頁面的生存週期。
試想一下，如果引導頁或者主頁面快取了5個子頁面的資源，在跳轉到響應的子頁面時又會快取這些子頁面的下級頁面資源，如此反覆肯定會佔據大量記憶體使APP的體驗下降。那麼怎麼知道哪些頁面是需要的，最多快取多少頁面，什麼時候結束哪些頁面的生存週期呢？在很多H5APP的框架裡都沒有對這些問題有一個完美的解答，因此在頁面較多、內容較多的APP中可能會因這些資源分配的問題降低效能。
這時再看看MVVM的資料載入問題，實際上不管哪個MVVM框架，寫過的人都知道管理這種新型的前端程式碼最重要的問題是記憶體的問題，你既要保證程式碼寫的足夠優雅沒有任何記憶體洩露問題，也要考慮到在頁面生存週期結束時它們的控制器/頁面資源是否得到釋放，這對全域性有沒有什麼影響，在多個請求時也要合理的分配資源，甚至是複用這些父級頁面傳過來的快取資源等等。較小的APP可能並不會有這些問題，如果你想用純H5來開發大型APP，這很可能會浪費你很多時間——而且結果還不會讓你滿意。
HTML5有多少坑可以分為3大點和7小點，3大點上文有詳細的介紹了，下面說說7小點。
1.過分依賴網路
2.渲染效能較弱
3.頁面過多
4.標籤太多，程式碼量也不少
5.不能呼叫移動硬體裝置的功能
6.不支援離線模式
7.訊息推送不夠及時
雖然H5 APP有很多缺點，但不得不承認，存在必然有其作用，正如前幾年流行的混合開發模式，通過原生和H5結合也是不錯的方案，比如淘寶、京東等電商類App，
HTML5 的優勢在於他的排版，要做出相同效果的 Native 介面排版成本又太大，
JavaScript由於其複雜的文件物件模型（DOM）、糟糕的實現和除錯工具、不一致的瀏覽器實現而不受開發者的待見。而隨著技術的發展， JavaScript變得越來越強大、完善，比如， Ajax技術可以建立更加迷人的Web應用，Angular JS提供web應用的架構支援整個開發程序，Node.js將JavaScript的應用範圍擴充套件到了伺服器端，imag.js將JavaScript延伸到移動端，各種層出不窮的框架使得JavaScript的開發更加簡捷。尤其是近幾年node.js和imag.js以及react.js的發展，將 JavaScript提升到了前所未有的高度。
我們也可以看看用imag.js開發的微信頁面（支援Android和iOS）
[url=http://blog.csdn.net/mojingxuan/article/details/51444812]點選連結[/url]
1、動畫
動畫有很多種，比如側邊欄選單的滑入滑出、元素的響應動畫、頁面切換之間的過場等等，在H5之下的眾多實現方法都沒有辦法達到純原生的效能。一般有這幾種不同的選擇：css3動畫，javascript動畫，原生動畫。
css3動畫非常的消耗效能，如果某一個元素用到css3動畫可能還看不出來，但大面積或過場使用css3動畫會讓app低端手機體驗非常差。最好的選擇是通過框架呼叫底層的動畫，但不管怎麼樣等於在原來的程式碼上包上了一層，效能還是不可避免的受到影響。
比如在一個新頁面的載入上，如果呼叫底層動畫要考慮的問題有兩個，一個是本身資源頁面的渲染問題，另一個是遠端資料的獲取。即便是這些動畫能夠很快的響應，但大量的css頁面會導致渲染卡頓，滑入時可能會有白屏/機器卡頓的現象。為了解決這些效能問題又必須要用到預載入或模擬動畫。即便是這樣，滑入滑出的動畫在低端的安卓機器上還是有很多問題，如果獲取服務端資料處理的方式不合適，卡頓白屏的現象會更嚴重。具體看下面的資料獲取方式。
2、獲取服務端資料
首先要接受的是，這裡的資料獲取都是在資源頁面上非同步完成的，因為只有這樣才能讓這些資源頁面完成預載入或者渲染。但是非同步拿到的資料在填入頁面中時可能會涉及DOM操作，眾所周知，DOM操作非常消耗效能，如果頁面小還好，頁面稍大資料稍微複雜一點，頻繁的DOM操作會導致明顯的閃白。
而且最重要的一點是，如果頁面載入進來之後資料更新的速度太慢，也會讓頁面模板等待很長時間，對使用者體驗又不友好，總不能每次開啟都像瀏覽器一樣等待重新整理是吧。
這個問題如果沒有得到解決，H5APP是很難承擔大規模資料的頁面，在它們之中頻繁切換更是難上加難，那麼肯定有人也會想到用MVVM的方式，相對來說它們獲取資料和更新資料的方式更敏捷更科學，但寫的過程中又要注意很多H5獨有的問題，這些問題在下面的頁面切換裡來講。
3、頁面切換
上面幾種不錯的實現方式，比如預載入和模擬動畫，甚至有批量的預載入，批量的截圖模擬動畫等等，雖然看起來很友好解決了不少問題，但事實上如果頁面足夠多就會引發另一個問題：頁面的生存週期。
試想一下，如果引導頁或者主頁面快取了5個子頁面的資源，在跳轉到響應的子頁面時又會快取這些子頁面的下級頁面資源，如此反覆肯定會佔據大量記憶體使APP的體驗下降。那麼怎麼知道哪些頁面是需要的，最多快取多少頁面，什麼時候結束哪些頁面的生存週期呢？在很多H5APP的框架裡都沒有對這些問題有一個完美的解答，因此在頁面較多、內容較多的APP中可能會因這些資源分配的問題降低效能。
這時再看看MVVM的資料載入問題，實際上不管哪個MVVM框架，寫過的人都知道管理這種新型的前端程式碼最重要的問題是記憶體的問題，你既要保證程式碼寫的足夠優雅沒有任何記憶體洩露問題，也要考慮到在頁面生存週期結束時它們的控制器/頁面資源是否得到釋放，這對全域性有沒有什麼影響，在多個請求時也要合理的分配資源，甚至是複用這些父級頁面傳過來的快取資源等等。較小的APP可能並不會有這些問題，如果你想用純H5來開發大型APP，這很可能會浪費你很多時間——而且結果還不會讓你滿意。
HTML5有多少坑可以分為3大點和7小點，3大點上文有詳細的介紹了，下面說說7小點。
1.過分依賴網路
2.渲染效能較弱
3.頁面過多
4.標籤太多，程式碼量也不少
5.不能呼叫移動硬體裝置的功能
6.不支援離線模式
7.訊息推送不夠及時
雖然H5 APP有很多缺點，但不得不承認，存在必然有其作用，正如前幾年流行的混合開發模式，通過原生和H5結合也是不錯的方案，比如淘寶、京東等電商類App，
HTML5 的優勢在於他的排版，要做出相同效果的 Native 介面排版成本又太大，
JavaScript由於其複雜的文件物件模型（DOM）、糟糕的實現和除錯工具、不一致的瀏覽器實現而不受開發者的待見。而隨著技術的發展， JavaScript變得越來越強大、完善，比如， Ajax技術可以建立更加迷人的Web應用，Angular JS提供web應用的架構支援整個開發程序，Node.js將JavaScript的應用範圍擴充套件到了伺服器端，imag.js將JavaScript延伸到移動端，各種層出不窮的框架使得JavaScript的開發更加簡捷。尤其是近幾年node.js和imag.js以及react.js的發展，將 JavaScript提升到了前所未有的高度。
我們也可以看看用imag.js開發的微信頁面（支援Android和iOS）
[url=http://blog.csdn.net/mojingxuan/article/details/51444812]點選連結[/url]