[[151272]]

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

1、動(dòng)畫

動(dòng)畫有很多種，比如側(cè)邊欄菜單的滑入滑出、元素的響應(yīng)動(dòng)畫、頁面切換之間的過場(chǎng)等等，在H5之下的眾多實(shí)現(xiàn)方法都沒有辦法達(dá)到純?cè)男阅堋Ｒ话氵@些的話有幾種不同的選擇：

• css3動(dòng)畫

• javascript動(dòng)畫

• 原生動(dòng)畫

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

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

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

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

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

這個(gè)問題如果沒有得到解決，H5APP是很難承擔(dān)大規(guī)模數(shù)據(jù)的頁面，在它們之中頻繁切換更是難上加難，那么肯定有人也會(huì)想到用MVVM的方式，其實(shí)我也寫過一些基于MVVM的H5APP，相對(duì)來說它們獲取數(shù)據(jù)和更新數(shù)據(jù)的方式更敏捷更科學(xué)，但寫的過程中又要注意很多H5獨(dú)有的問題，這些問題在下面的頁面切換里來講。

3、頁面切換

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

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

這時(shí)候我們回過頭來再看看MVVM的數(shù)據(jù)加載問題，實(shí)際上不管哪個(gè)MVVM框架，寫過的人都知道管理這種新型的前端代碼最重要的問題是內(nèi)存的問題，你既要保證代碼寫的足夠優(yōu)雅沒有任何內(nèi)存泄露問題，也要考慮到在頁面生存周期結(jié)束時(shí)它們的控制器/頁面資源是否得到釋放，這對(duì)全局有沒有什么影響，在多個(gè)請(qǐng)求時(shí)也要合理的分配資源，甚至是復(fù)用這些父級(jí)頁面?zhèn)鬟^來的緩存資源等等。較小的APP可能并不會(huì)有這些問題，如果你想用純H5來開發(fā)大型APP，這很可能會(huì)浪費(fèi)你很多時(shí)間——而且結(jié)果還不會(huì)讓你滿意。

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

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

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

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

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