成人无码视频,亚洲精品久久久久av无码,午夜精品久久久久久毛片,亚洲 中文字幕 日韩 无码

資訊專欄INFORMATION COLUMN

記一次頁面卡頓排查

Lin_YT / 2838人閱讀

摘要：記一次頁面卡頓排查前述前段時(shí)間上線的一個(gè)移動(dòng)端的項(xiàng)目，由于開發(fā)時(shí)間倉促，一直被用戶投訴頁面卡頓。這顯然要導(dǎo)致卡頓?？偨Y(jié)這只是頁面卡頓的一個(gè)點(diǎn)，當(dāng)然還有很多，我們的頁面卡頓就是由這樣一個(gè)一個(gè)的點(diǎn)造成的。

記一次頁面卡頓排查 前述

前段時(shí)間上線的一個(gè)移動(dòng)端的項(xiàng)目，由于開發(fā)時(shí)間倉促，一直被用戶投訴頁面卡頓?，F(xiàn)在終于有時(shí)間來好好排查一下，看到底是什么原因。業(yè)務(wù)代碼都不是自己寫的，這是頗為頭疼的問題。到了自己手上也只能努力的填坑了，伐開心。

chrome Timeline分析

首先當(dāng)然是祭出開發(fā)神器--chrome，來看看頁面的fps和js執(zhí)行時(shí)間都是什么樣子的。
本文不是介紹Timeline的知識(shí)，請(qǐng)還不了解的同學(xué)自行學(xué)習(xí)。傳送門：https://developers.google.com/web/tools/chrome-devtools/profile/evaluate-performance/timeline-tool

果然fps是鋸齒狀的，頂上伴隨著紅條（可能存在性能問題的地方）。從圖中可以發(fā)現(xiàn)，出現(xiàn)fps較低的地方，大都伴隨著過多的script執(zhí)行耗時(shí)（黃色部分）。接著我們選取一段fps較低的時(shí)間段，來看下具體有哪些event。

從圖中可以看出，這個(gè)函數(shù)執(zhí)行了118ms（當(dāng)然頁面卡頓還有別的地方引起，我就不一一描述出來了），而要確保頁面不卡頓的時(shí)間是16.7ms。這顯然要導(dǎo)致卡頓。這個(gè)函數(shù)內(nèi)發(fā)生了很多事件。我發(fā)現(xiàn)了一個(gè)很糟糕的事，強(qiáng)制reflow，這可是前端性能的大忌了。而這個(gè)回流占用了大部分的函數(shù)執(zhí)行時(shí)間。這個(gè)reflow是發(fā)生在“renderCommlist”函數(shù)內(nèi)的，然后我點(diǎn)進(jìn)這個(gè)函數(shù)看做了些什么操作。代碼如下：

function renderCommlist(data, $dom) {
    var prex = getMaidianPre();
    totalCount = data.cnt - 0;
    if (totalCount != 0) {
        $("#palmrobtimes").show();
        indexComm = fillCommListData(data, prex, indexComm);
        var render = template.compile(document.getElementById("tmpl_pro_item").innerHTML);
        var html = render(data);
        renderCommlistAsyc(html, $dom);
        $("#toTop").show()
    } else {
        commListEmpty($dom);
        $("#toTop").hide()
    }
    dataLoading = false
}

根據(jù)執(zhí)行的順序我可以斷定這個(gè)reflow發(fā)生對(duì)應(yīng)的是“ $("#toTop").show()”這句。這就讓我詫異了，一個(gè)zepto的show()方法竟然會(huì)導(dǎo)致這么嚴(yán)重的后果。我是長姿勢(shì)了。而“#toTop”對(duì)應(yīng)的DOM是這樣的：

“toTop”是被一個(gè)fixed的標(biāo)簽包裹起來的。根據(jù)我的所學(xué)一個(gè)脫離文檔流的dom不應(yīng)該能造成這么嚴(yán)重的reflow啊。所以我們要來zepto的show到底做了一些什么事情。

接著我們來看Call Tree?？纯磗how里面調(diào)用了哪些函數(shù)。

我發(fā)現(xiàn)，show里面調(diào)用了n,t.fn.animate,t.fn.anim等函數(shù)。主要發(fā)時(shí)間都消耗在了t.fn.anim上了。從函數(shù)名上看，這應(yīng)該是動(dòng)畫相關(guān)的函數(shù)。我只是想要個(gè)顯示元素，竟然調(diào)用了動(dòng)畫函數(shù)，不知道為什么。從“Layout”后面的鏈接點(diǎn)進(jìn)去可以定位到觸發(fā)“Layout”的，代碼如下:

// trigger page reflow so new elements can animate
this.size() && this.get(0).clientLeft

這樣我就明白了。就是這一句導(dǎo)致強(qiáng)制reflow。而我是要顯示個(gè)元素，不要?jiǎng)赢?，這顯然是沒必要的。我翻看了下源代碼，這里竟然還有注釋?！盀榱诵碌脑啬軌驁?zhí)行動(dòng)畫，觸發(fā)頁面回流”。原來作者是故意的，不過顯然低估了reflow的威力。其實(shí)也不是所有的場(chǎng)景會(huì)造成這么嚴(yán)重的回流耗時(shí)，只是我的場(chǎng)景比較“幸運(yùn)”,在調(diào)用的這個(gè)函數(shù)的同時(shí)，程序往頁面里append了DOM，放大了這個(gè)reflow。

對(duì)zepto的show函數(shù)的分析

至于show函數(shù)是怎么調(diào)用到animate的我還是比較好奇。在源碼里查看了下。在zepto的核心模塊“zepto.js”里其實(shí)show是這樣的：

show: function(){
  return this.each(function(){
    this.style.display == "none" && (this.style.display = "")
    if (getComputedStyle(this, "").getPropertyValue("display") == "none")
      this.style.display = defaultDisplay(this.nodeName)
  })
},

并沒有去調(diào)用anim的。所以我就全局搜索了下“$.fn.show”發(fā)現(xiàn)這個(gè)函數(shù)是在“fx_methods.js”模塊里的。

$.fn.show = function(speed, callback) {
    origShow.call(this)
    if (speed === undefined) speed = 0
    else this.css("opacity", 0)
    return anim(this, speed, 1, "1,1", callback)
}

這樣就明白了，這個(gè)函數(shù)把上面的show給覆蓋掉了，添加了動(dòng)畫。而anim又調(diào)用了“fx.js”里的“$.fn.animate”，這樣就看到了上面的執(zhí)行效果。不夠我還是覺得動(dòng)畫沒必要。其實(shí)“fx.js”和“fx_methods.js“，其實(shí)是可以不用打包到zepto里的，zepto的默認(rèn)模塊里也沒這兩個(gè)。

總結(jié)

這只是頁面卡頓的一個(gè)點(diǎn)，當(dāng)然還有很多，我們的頁面卡頓就是由這樣一個(gè)一個(gè)的點(diǎn)造成的。所以自己以后日常多多注意頁面的性能。多用chrome dev來分析頁面存在的性能問題。然后不要迷信開源框架，也是有缺陷的。

文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請(qǐng)注明本文地址：http://m.hztianpu.com/yun/86343.html

相關(guān)文章

  • 記一次驚心動(dòng)魄的前端性能優(yōu)化之旅

    摘要：方案未引起重視，并沒有做出相應(yīng)處理。頁面中元素的布局是相對(duì)的，因此一個(gè)元素的布局發(fā)生變化，會(huì)聯(lián)動(dòng)地引發(fā)其他元素的布局發(fā)生變化。這里可以使用的和來分析的性能。寫在最后性能優(yōu)化是一門做減法的藝術(shù)。 歡迎一起交流 歡迎關(guān)注我的個(gè)人公眾號(hào)，不定期更新自己的工作心得。showImg(https://segmentfault.com/img/bVEk23?w=258&h=258); 正文從這里開始...

    Bryan 評(píng)論0 收藏0

  • 記一次驚心動(dòng)魄的前端性能優(yōu)化之旅

    摘要：方案未引起重視，并沒有做出相應(yīng)處理。頁面中元素的布局是相對(duì)的，因此一個(gè)元素的布局發(fā)生變化，會(huì)聯(lián)動(dòng)地引發(fā)其他元素的布局發(fā)生變化。這里可以使用的和來分析的性能。寫在最后性能優(yōu)化是一門做減法的藝術(shù)。 歡迎一起交流 歡迎關(guān)注我的個(gè)人公眾號(hào)，不定期更新自己的工作心得。showImg(https://segmentfault.com/img/bVEk23?w=258&h=258); 正文從這里開始...

    leejan97 評(píng)論0 收藏0

  • 記一次驚心動(dòng)魄的前端性能優(yōu)化之旅

    摘要：方案未引起重視，并沒有做出相應(yīng)處理。頁面中元素的布局是相對(duì)的，因此一個(gè)元素的布局發(fā)生變化，會(huì)聯(lián)動(dòng)地引發(fā)其他元素的布局發(fā)生變化。這里可以使用的和來分析的性能。寫在最后性能優(yōu)化是一門做減法的藝術(shù)。 歡迎一起交流 歡迎關(guān)注我的個(gè)人公眾號(hào)，不定期更新自己的工作心得。showImg(https://segmentfault.com/img/bVEk23?w=258&h=258); 正文從這里開始...

    Anshiii 評(píng)論0 收藏0

  • 記一次MongoDB高負(fù)載的性能優(yōu)化

    摘要：年月日本文是關(guān)于記錄某次游戲服務(wù)端的性能優(yōu)化此處涉及的技術(shù)包括引擎隨著游戲?qū)肴藬?shù)逐漸增加單個(gè)集合的文檔數(shù)已經(jīng)超過經(jīng)常有玩家反饋說卡特別是在服務(wù)器遷移后從核降到核卡頓更嚴(yán)重了遂開始排查問題確認(rèn)服務(wù)器壓力首先使用命令查看總體情況此時(shí)占用不高 Last-Modified: 2019年6月13日11:08:19 本文是關(guān)于記錄某次游戲服務(wù)端的性能優(yōu)化, 此處涉及的技術(shù)包括: MongoDB...

    huhud 評(píng)論0 收藏0

發(fā)表評(píng)論

0條評(píng)論

Lin_YT

男|高級(jí)講師

TA的文章

閱讀更多
最新活動(dòng)
閱讀需要支付1元查看
<