记一次页面卡顿排查

tinybear

记一次页面卡顿排查

前述

前段时间上线的一个移动端的项目,由于开发时间仓促,一直被用户投诉页面卡顿。现在终于有时间来好好排查一下,看到底是什么原因。业务代码都不是自己写的,这是颇为头疼的问题。到了自己手上也只能努力的填坑了,伐开心。

chrome Timeline分析

首先当然是祭出开发神器--chrome,来看看页面的fps和js执行时间都是什么样子的。
本文不是介绍Timeline的知识,请还不了解的同学自行学习。传送门:https://developers.google.com/web/tools/chrome-devtools/profile/evaluate-performance/timeline-tool

图片描述

果然fps是锯齿状的,顶上伴随着红条(可能存在性能问题的地方)。从图中可以发现,出现fps较低的地方,大都伴随着过多的script执行耗时(黄色部分)。接着我们选取一段fps较低的时间段,来看下具体有哪些event。

图片描述

从图中可以看出,这个函数执行了118ms(当然页面卡顿还有别的地方引起,我就不一一描述出来了),而要确保页面不卡顿的时间是16.7ms。这显然要导致卡顿。这个函数内发生了很多事件。我发现了一个很糟糕的事,强制reflow,这可是前端性能的大忌了。而这个回流占用了大部分的函数执行时间。这个reflow是发生在“renderCommlist”函数内的,然后我点进这个函数看做了些什么操作。代码如下:

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
}

根据执行的顺序我可以断定这个reflow发生对应的是“ $("#toTop").show()”这句。这就让我诧异了,一个zepto的show()方法竟然会导致这么严重的后果。我是长姿势了。而“#toTop”对应的DOM是这样的:

图片描述

“toTop”是被一个fixed的标签包裹起来的。根据我的所学一个脱离文档流的dom不应该能造成这么严重的reflow啊。所以我们要来zepto的show到底做了一些什么事情。

接着我们来看Call Tree。看看show里面调用了哪些函数。

图片描述

我发现,show里面调用了n,t.fn.animate,t.fn.anim等函数。主要发时间都消耗在了t.fn.anim上了。从函数名上看,这应该是动画相关的函数。我只是想要个显示元素,竟然调用了动画函数,不知道为什么。从“Layout”后面的链接点进去可以定位到触发“Layout”的,代码如下:

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

这样我就明白了。就是这一句导致强制reflow。而我是要显示个元素,不要动画,这显然是没必要的。我翻看了下源代码,这里竟然还有注释。“为了新的元素能够执行动画,触发页面回流”。原来作者是故意的,不过显然低估了reflow的威力。其实也不是所有的场景会造成这么严重的回流耗时,只是我的场景比较“幸运”,在调用的这个函数的同时,程序往页面里append了DOM,放大了这个reflow。

对zepto的show函数的分析

至于show函数是怎么调用到animate的我还是比较好奇。在源码里查看了下。在zepto的核心模块“zepto.js”里其实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)
  })
},

并没有去调用anim的。所以我就全局搜索了下“$.fn.show”发现这个函数是在“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)
}

这样就明白了,这个函数把上面的show给覆盖掉了,添加了动画。而anim又调用了“fx.js”里的“$.fn.animate”,这样就看到了上面的执行效果。不够我还是觉得动画没必要。其实“fx.js”和“fx_methods.js“,其实是可以不用打包到zepto里的,zepto的默认模块里也没这两个。

总结

这只是页面卡顿的一个点,当然还有很多,我们的页面卡顿就是由这样一个一个的点造成的。所以自己以后日常多多注意页面的性能。多用chrome dev来分析页面存在的性能问题。然后不要迷信开源框架,也是有缺陷的。

阅读 5.8k

tinybear
偶尔牢骚~~

一只熊,浪啊浪

620 声望
21 粉丝
0 条评论

一只熊,浪啊浪

620 声望
21 粉丝
文章目录
宣传栏