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