現(xiàn)在越來越多的APP里面會加入很多的H5的頁面，這種Hybrid App(混合模式移動應用)的開發(fā)模式越來越受歡迎。甚至還有一些純H5的APP，這樣的APP開發(fā)效率快很多，一套代碼可以安卓IOS共用。在H5技術越來越成熟的背景下，H5會取代原生的APP開發(fā)嗎？

現(xiàn)在看來，一些純H5的APP，雖然開發(fā)起來的確很快很舒服，但和原生比起來純H5APP還是有很多問題，主要聚集在以下幾個方面：

 

1、動畫效果方面

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

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

 

2、獲取服務端數(shù)據(jù)

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

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

 

3、頁面切換

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

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

 

4、Android/iOS的區(qū)別

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

舉一個很簡單的例子，Android和iOS在返回上一頁的處理方式上就有明顯的區(qū)別，iOS的頂部bar在全屏下怎樣處理，Android機器出現(xiàn)smart bar怎樣處理頁面的布局，調(diào)用底層硬件時怎樣區(qū)分不同的場景等等，你需要寫一個又一個機型和系統(tǒng)的判斷，然后分別在Android和iOS下調(diào)試，最后你卻發(fā)現(xiàn)這并沒有卵用，累的要死卻什么沒學到，只有一堆不知道什么時候會過時的經(jīng)驗。

 

現(xiàn)在做H5混合APP開發(fā)的人很多，但是純H5卻很年輕，很多問題都沒有很好的解決。當然大家也不必擔心，硬件發(fā)展越來越快，純H5APP未必沒有一席之地。最后說一個很少人注意到的H5優(yōu)勢，大家大談H5APP時都是快速開發(fā)、低成本、多平臺等等，但我卻覺得它和很多APP開發(fā)方式相比有一個不同之處——圖文混合的排版。

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