純 HTML5 APP與原生APP的差距在哪？

寫過一些純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的優異之處。