一个Chrome 运行时性能瓶颈分析案例

初诊

打开Chrome隐身模式

主要是为了确保有一个干净的测试环境, 不被其它因素所影响.

打开测试地址

谷歌性能测试地址 googlechrome.github.io/devtools-sa…

国内性能测试地址: gitee.com/hellojamesz…

能够看到以下画面:

能够看到页面蓝色小方块在运动

限制CPU速度

有些用户电脑的CPU性能很好, 可能没法较好的分析问题(难以发现低端配置设备的性能问题), 因此须要降速.

在Chrome浏览器控制台中找到"Performance" => "CPU"选项, 选择下降4/6倍性能

添加更多小方块, 找到性能瓶颈

上面已经限制了CPU的性能, 接下来须要寻找性能瓶颈了.

屡次点击"Add 10", 向页面中添加小块, 直到感受页面上小块运动时出现明显卡顿便可.

此时, 已经能够明显感受到页面很卡顿了.

优化先后的效果对比

经过点击"Optimize"按钮, 能够提早感觉下优化先后的效果对比

能够明显感觉到优化先后页面的流畅度明显不同.

了解Performance各模块

如何分析问题, 确定是要依赖数据, 这里须要使用到Chrome的Performance功能.

将页面切换至非优化的状态, 点击"Record".

录制的结果以下图所示:

以上数据初学者可能看不明白, 不要紧, 咱们来一步步了解各部分的含义

FPS

fps, 指页面每秒帧数

• fps = 60性能最佳
• fps < 24会让用户感受到卡顿, 由于人眼的识别主要是24帧

图中蓝色标记出的区域, 即FPS记录的信息 放大某一区域, 能够看到, FPS由两部分组成:

• 红色的条
• 绿色的半透明条

切换至优化状态

切换至已优化状态, 再进行录制后, 获得FPS数据以下:

能够看出:

• 没有了红色条
• 绿色半透明条的高度, 明显比没有优化时高很多

小结

• 红色, 即帧数已经降低到影响用户体验的程度, Chrome已经标注出来, 这块有问题
• 绿色, 即FPS指数, 全部绿色柱体高度越高, 性能越好

了解CPU

上图中FPS下的位置, 即CPU信息 咱们采集些一个真实业务的CPU数据, 这里我抓取的是我的简书的performance, 以下图所示:

对比能够发现, CPU数据的一些特性:

• CPU包括两种状态
  • 充满颜色
  • 不充满颜色
• CPU是否充满颜色和FPS存在联系

了解NET

NET部分能够将屏幕逐帧录制下来, 能帮忙观察页面的状态, 分析首屏渲染速度

了解Frames

查看特定帧的FPS

Frames部分, 主要用于查看特定帧的FPS, 能够查看特定的帧状况, 悬停其上, 能够查看数据.

能够看到:

• 这一帧的时间间隔是: 327ms
• 当前FPS是1000ms/327ms = 3fps 这里主要体现的是页面两次刷新之间间隔了327ms

查看某个Frames块更详细的信息

点击某个Frames块, 能够查看到更加详细的数据

点击某个Frames块, 能够查看到更加详细的数据

• Duration, 是当前帧从1.02s开始等待, 1.02s+326.97ms后进行了一次渲染
• fps, 1000ms/326.97ms = 3fps
• 最下面的是当前帧的视图画像

了解FPS快捷工具

在Chrome中, 还有一个More Tools选项, 选中"Rendering"选项

接着, 开启"FPS meter"选项

勾选后, 在页面上会出现一个FPS统计器, 如上图左上角.

暂时先不勾选"FPS meter", 不利于系统性学习

找到瓶颈

经过前面的内容, 咱们已经知道页面有性能问题, 那接下来就要开始寻找缘由了.

了解 Summary

对性能进行录制完成时, 会默认在底部显示一个 Summary摘要, 显示全局信息.

上面展现了0~4.90s录制时间的具体耗时:

• script, 耗时1534ms
• rendering, 耗时2557ms
• Painting, 耗时281ms

主要了解这3个耗时, 但了解这3个耗时, 对于哪有问题, 还须要进一步的排查.

了解 Main

上图红色框出部分, 就是Main, 其中每一块是每一帧中所作的事情

目前仍看不出什么. 为了方便观看, 咱们可在fps, cpu, net模块, 点击一下, 缩小时间区间:

如上图所示, 经过缩小时间区间, 来实现放大Main中的内容. 如今已经可以看到, Main中展现的"火焰图", 即函数调用的堆栈. 其中:

• x轴表示时间
• y轴表示调用函数, 函数中还包含依次调用的函数, y轴只占用x轴的一个时间维度

识别问题, 红色三角号

上图中, 能够看到Animation Frame Fired右上角有一个红色三角号, 这是Chrome自动帮助识别出有问题的部分, 就像FPS中的红色同样, 用来识别问题

上图能够到提示"Warning: Recurring handler took 318.21 ms", 即重复处理程序耗时318.21ms

追溯问题, 定位代码问题

点击Animation Frame Fired下面的"Function Call"

如上图, 能够看到函数调用代码中的位置, 能够点击进行查看:

虽然定位到了, 是方法 update形成的问题, 但不够明确, 因此须要进一步探索.

进一步分析问题位置

继续查看Main, 能够看到app.update下面有不少"紫色"的条, 紫色条自己表示渲染. 但请 注意!!!的是紫色条上还有更小的, 运用前面学过的放大功能, 调整时间区间.

能够看到, 每一个紫色条都有一个红色的小三角, 前面提到"红色三角是Chrome帮助自动识别有问题的地方", 查看提示信息: "Forced reflow is a likely performance bottleneck.", 即强制回流多是性能瓶颈

点击查看摘要.

能够看到, 问题定位在了 performanceTest.html的第136行, 点击查看, 可以看到是对每个元素进行样式修改.

这段代码的问题在于, 在每一个动画帧中, 它会更改每一个方块的样式, 而后查询页面上每一个方块的位置. 因为样式发生了变化, 浏览器不知道每一个方块的位置是否发生了变化, 所以必须从新布局方块以计算其位置.

避免这种状况的出现, 能够参考: 避免大型、复杂的布局和布局抖动

对比优化的效果

能够看到, 优化后的状态, script, render的时间都大大减小了, 所以fps明显提升.

性能优化知识储备

• 使用 rail 模型测量性能
• 基础储备
  • 渲染性能概述
  • A Frame的剖析

相关连接

• Chrome性能测试demo
• Chrome性能测试demo-国内
• 避免大型、复杂的布局和布局抖动
• 性能优化知识储备
  • 使用 rail 模型测量性能
  • 基础储备
    • 渲染性能概述
    • A Frame的剖析

掘金: 一个Chrome 运行时性能瓶颈分析案例