主要聚集在以下幾個(gè)方面： 1、動(dòng)畫(huà) 動(dòng)畫(huà)有很多種，比如側邊欄菜單的滑入滑出、元素的響應動(dòng)畫(huà)、頁(yè)面切換之間的過(guò)場(chǎng)等等，在H5之下的眾多實(shí)現方法都沒(méi)有辦法達到純原生的性能。一般這些的話(huà)有幾種不同的選擇：css3動(dòng)畫(huà)、javascript動(dòng)畫(huà)、原生動(dòng)畫(huà)?！ ss3動(dòng)畫(huà)非常的消耗性能，如果某一個(gè)元素用到css3動(dòng)畫(huà)可能還看不出來(lái)，但大面積或過(guò)場(chǎng)使用css3動(dòng)畫(huà)會(huì )讓app低端手機體驗非常差。最好的選擇一般是通過(guò)框架調用底層的動(dòng)畫(huà)，但不管怎么樣等于在原來(lái)的代碼上包上了一層，性能還是不可避免的受到影響?！ ”热缭谝粋€(gè)新頁(yè)面的載入上，如果調用底層動(dòng)畫(huà)要考慮的問(wèn)題有兩個(gè)，一個(gè)是本身資源頁(yè)面的渲染問(wèn)題，另一個(gè)是遠程數據的獲取。即便是這些動(dòng)畫(huà)能夠很快的響應，但大量的css頁(yè)面會(huì )導致渲染卡頓，滑入時(shí)可能會(huì )有白屏/機器卡頓的現象。為了解決這些性能問(wèn)題又必須要用到預加載或模擬動(dòng)畫(huà)。即便是這樣，滑入滑出的動(dòng)畫(huà)在低端的安卓機器上還是有很多問(wèn)題，如果獲取服務(wù)端數據處理的方式不合適，卡頓白屏的現象會(huì )更嚴重。具體看下面的數據獲取方式?！ ?、獲取服務(wù)端數據 首先要接受的是，這里的數據獲取都是在資源頁(yè)面上異步完成的，因為只有這樣才能讓這些資源頁(yè)面完成預加載或者渲染。但是異步拿到的數據在填入頁(yè)面中時(shí)可能會(huì )涉及DOM操作，眾所周知，DOM操作非常消耗性能，如果頁(yè)面小還好，頁(yè)面稍大數據稍微復雜一點(diǎn)，頻繁的DOM操作會(huì )導致明顯的閃白。而且最重要的一點(diǎn)是，如果頁(yè)面加載進(jìn)來(lái)之后數據更新的速度太慢，也會(huì )讓頁(yè)面模板等待很長(cháng)時(shí)間，對用戶(hù)體驗又不友好，總不能每次打開(kāi)都像瀏覽器一樣等待刷新是吧?！ ∵@個(gè)問(wèn)題如果沒(méi)有得到解決，H5APP是很難承擔大規模數據的頁(yè)面，在它們之中頻繁切換更是難上加難，那么肯定有人也會(huì )想到用MVVM的方式，其實(shí)我也寫(xiě)過(guò)一些基于MVVM的H5APP，相對來(lái)說(shuō)它們獲取數據和更新數據的方式更敏捷更科學(xué)，但寫(xiě)的過(guò)程中又要注意很多H5獨有的問(wèn)題，這些問(wèn)題在下面的頁(yè)面切換里來(lái)講?！ ?、頁(yè)面切換 上面我們看到了幾種不錯的實(shí)現方式，比如預加載和模擬動(dòng)畫(huà)，甚至有批量的預加載，批量的截圖模擬動(dòng)畫(huà)等等，雖然看起來(lái)很友好解決了不少問(wèn)題，但事實(shí)上如果頁(yè)面足夠多就會(huì )引發(fā)另一個(gè)問(wèn)題——頁(yè)面的生存周期?！ ≡囅胍幌?，如果引導頁(yè)或者主頁(yè)面緩存了5個(gè)子頁(yè)面的資源，在跳轉到響應的子頁(yè)面時(shí)又會(huì )緩存這些子頁(yè)面的下級頁(yè)面資源，如此反復肯定會(huì )占據大量?jì)却媸笰PP的體驗下降。那么怎么知道那些頁(yè)面是需要的，最多緩存多少頁(yè)面，什么時(shí)候結束哪些頁(yè)面的生存周期呢？在我用過(guò)的很多H5APP的框架里都沒(méi)有對這些問(wèn)題有一個(gè)完美的解答，因此在頁(yè)面較多內容較多的APP中可能會(huì )因這些資源分配的問(wèn)題降低性能?！ ∵@時(shí)候我們回過(guò)頭來(lái)再看看MVVM的數據加載問(wèn)題，實(shí)際上不管哪個(gè)MVVM框架，寫(xiě)過(guò)的人都知道管理這種新型的前端代碼最重要的問(wèn)題是內存的問(wèn)題，你既要保證代碼寫(xiě)的足夠優(yōu)雅沒(méi)有任何內存泄露問(wèn)題，也要考慮到在頁(yè)面生存周期結束時(shí)它們的控制器/頁(yè)面資源是否得到釋放，這對全局有沒(méi)有什么影響，在多個(gè)請求時(shí)也要合理的分配資源，甚至是復用這些父級頁(yè)面傳過(guò)來(lái)的緩存資源等等。較小的APP可能并不會(huì )有這些問(wèn)題，如果你想用純H5來(lái)開(kāi)發(fā)大型APP，這很可能會(huì )浪費你很多時(shí)間——而且結果還不會(huì )讓你滿(mǎn)意?！ ?、Android/iOS的區別 很多人都說(shuō)純H5APP一次編寫(xiě)就能編譯Android/iOS兩種不同的APP，大大降低了成本。實(shí)際上這個(gè)觀(guān)點(diǎn)本身就是值得懷疑的，如果你寫(xiě)過(guò)這類(lèi)APP就能明白我在說(shuō)什么，它們既不省事，又存在很多BUG，調試時(shí)尤其繁瑣。舉一個(gè)很簡(jiǎn)單的例子，Android和iOS在返回上一頁(yè)的處理方式上就有明顯的區別，iOS的頂部bar在全屏下怎樣處理，Android機器出現smart bar怎樣處理頁(yè)面的布局，調用底層硬件時(shí)怎樣區分不同的場(chǎng)景等等，你需要寫(xiě)一個(gè)又一個(gè)機型和系統的判斷，然后分別在A(yíng)ndroid和iOS下調試，最后你卻發(fā)現這并沒(méi)有卵用，累的要死卻什么沒(méi)學(xué)到，只有一堆不知道什么時(shí)候會(huì )過(guò)時(shí)的經(jīng)驗?！ ‖F在做H5混合APP開(kāi)發(fā)的人很多，但是純H5卻很年輕，很多問(wèn)題都沒(méi)有很好的解決，這幾個(gè)是我在做這些APP時(shí)考慮最多的問(wèn)題。最后說(shuō)一個(gè)很少人注意到的H5優(yōu)勢，大家大談H5APP時(shí)都是快速開(kāi)發(fā)、低成本、多平臺等等，但我卻覺(jué)得它和很多APP開(kāi)發(fā)方式相比有一個(gè)不同之處——圖文混合的排版。正是這些復雜多變的CSS樣式消耗了性能，但是它帶來(lái)了排版的多樣性，能夠細致到每一個(gè)字寬行高和風(fēng)格的像素級處理，才是H5的優(yōu)異之處。
