chrome Performance 使用

本文详细介绍了如何使用Chrome的隐身模式和特定参数启动,以隔离插件影响,便于性能调试。通过一个实际的jank demo项目,展示了如何分析fps、cpu占用和网络情况,以及如何利用火焰图定位代码性能瓶颈。
摘要由CSDN通过智能技术生成

chrome 大法好

chrome Performance 应该都不陌生,但是不陌生代表会用~
今天就来记录一下 chrome Performance 的冰山一角

开始

既然是性能调试,那就不要掺杂其他的因素影响。很多教程第一步就是打开隐身模式。但是插件咋办?我就是个十足的插件迷

总不能都卸载了把,手动隐藏?那也太累了把,就没别的办法了吗?

准备干净的 chrome

  1. 找到 chrome 的快捷方式,90% 都是在这里了,C:\Program Files (x86)\Google\Chrome\Application

为了不影响之前的 chrome 数据,我们先 右键 - 发送到桌面快捷方式。这样就新建了一个 chrome 的入口

重点来了:在桌面的快捷方式右键打开属性。记得是新的 chrome 快捷方式打开属性。在目标一栏最后面填入:
--incognito --user-data-dir=E:\tmp\chrome\debugger

简单说一下这些参数是什么意思,顺便在普及几个参数:

参数效果
–user-data-dir=”[PATH]”指定缓存 Cache 路径(这里也会存放你的 chrome 数据)。所以只要指定了这个参数,该快捷方式打开的就相当于是复制了一套 chrome 出来
–disk-cache-size=指定 Cache 大小,单位 Byte
–Firstrun重置到初始状态
–incognito隐身模式启动
–disable-javascript禁用 Javascript

PS:记得–前面是有空格的。然后我的临时目录是放到了 E:\tmp\chrome\debugger。这个看个人喜欢了

然后通过新的快捷方式打开 chrome,可以看到一个完全干净,并且直接进入了隐身模式的浏览器。通过你之前打开浏览器的方式,又能回到那个正常模式 N 多插件的 chrome。这样就方便多了,所以我把新的快捷方式命名为 debugger-chrome

最后打开的就是一个隐身模式下啥都没有的 chrome 浏览器。

调试的 demo

浏览器是准备好了,总得来个项目才能实战把。google 非常贴心的准备了一个 demo https://googlechrome.github.io/devtools-samples/jank/

项目名称起的也是非常有意思 jank

何为jank?
根据 《web 性能实战》2.4 章:jank 是指交互和动画效果卡顿、或未能顺利渲染。如果使用的编程技术欠佳,那么即使是从网络快速加载的页面,也会受到 jank 的影响。
…(省略一堆文字) 当单一的帧中占据了太多 CPU 时间,就会发现这种情况。

如果网络不好的同学可能打不开这个网页,毕竟托管在 github 上。通常遇到这种情况可以考虑另外一个方法:找到最快的节点IP

打开:https://ping.chinaz.com/googlechrome.github.io

根据几个指标

  1. 优先选择响应时间最短的
  2. 通过 ping 命令,找到可以 ping 通的 IP
  3. 把该 IP 写入 host 文件中
185.199.108.153 googlechrome.github.io
  1. 在 cmd 下运行 ipconfig /flushdns (刷新 dns 缓存)

如果还是不能访问~,那就随便找个项目看着办把。

设置 demo

打开 demo 后(如果是自己的项目那就可以直接开始了)。

先添加几十个元素。然后开始记录

在记录过程中,可以切换一下 optimize 按钮,感受一下优化和未优化的效果。

由于点击的是录制按钮,所以他不会自动停止录制,如果点的是隔壁的圈圈。在页面加载完成后就会自动停止录制

录制的差不多就 stop 了。我们要看的其实也就是其中的几秒。

查看录制效果并分析

帧率,CPU,网络情况

这个 demo 中没有网络请求,所以NET部分是空的一条

  • FPS 百度百科 FPS
    FPS 就是 绿色的那条,越高越好。当然也会出现红色的情况

    如果出现红色了,说明这一帧的页面已经卡住了

  • CPU 占用
    CPU 占用这个,也不能说越低越好,能在 CPU 处理范围内,那就完美了。

    其中 CPU 里面还有多种颜色,也对应下面的 Summary面板

    蓝色 - loading - 请求和解析HTML
    黄色 - script - JS执行时间
    紫色 - Rendering - 重排(计算尺寸和几何变化)
    绿色 - Painting - 重绘时间(色彩填充等)
    灰色 - System - 系统占用的时间
    白色 - Idle - 等待时间
    
  • net 网络请求
    这里不涉及网络请求,那就不多说了

综上的一些小普及,在中间某一段 FPS 可以达到 60(顶峰)。其余多数是一半。在 FPS 达到顶峰的时候,CPU 占用明显降了下来(因为就在那一会我点了优化,可以看到 CPU 的颜色图,黄色(JS 脚本)明显少了紫色(重排)也少了许多绿色(页面重绘)代替了一部分工作

如果想看 FPS 是红色的情况,可以在录制的时候在去点添加元素的按钮

第一部分并不能很好的定位问题,只能说明哪个区域的问题值得我们重点排查

选取片段查看

鼠标在进度条上拖动选择,或者滚轮进行选择

鼠标放在 Frames 上,可以看到某一帧的 FPS 值

另外一个好用的小工具就是实时 FPS 面板,它可以实时展示页面的 FPS 指标

按下 Command+Shift+P(Mac)或者 Control+Shift+P>(Windows, Linux) 打开命令菜单
输入 Rendering,点选 Show Rendering
Rendering 面板里,激活 FPS Meter。FPS 实时面板就出现在页面的右上方。

记得选择 Frame Rendering Stats 这样实时记录面板才会显示在页面上。

FPS 下面就是某一帧的截图了。

Experience 下面才会说到,可以先放着。

Summary 面板 与 Main 、Experience

前面那么多的图形,只能告诉你发生了卡顿,并不能告诉你,到底为什么卡顿了,具体到代码体现在哪里。

想要找到真凶,就看 Summary 面板

查看总览

通常刚分析完的的那会/点击 Main 所在的那一整条。就可以看到总览了

  • 如果选择了某一段时间的,那就是这段时间内的总览

颜色在上面也说过了,这里也从在说一下

蓝色 - loading - 请求和解析HTML
黄色 - script - JS执行时间
紫色 - Rendering - 重排(计算尺寸和几何变化)
绿色 - Painting - 重绘时间(色彩填充等)
灰色 - System - 系统占用的时间
白色 - Idle - 等待时间

火焰图 Main

火焰图看着好像眼花缭乱,其实火焰图还是个看源码的利器!稍后会介绍到

我们选中其中一段 Task(任务) 来细看

火焰图需要从左开始,往下看,然后看到右,也就是按照框住的区域一块块看

  1. 执行了 2 段 JS 脚本
  2. 计算很多元素的重排位置(发生了小范围重排)
  3. 单第一个红色框内容执行完成后,到第二个红色框,进行计算重排的位置
  4. 最后到绿色的部分,重绘页面
  5. 结束了一个任务

如果执行一个 task 时间过长,那就会延迟了后面一个 task 的执行,那就会造成页面的卡顿了。这也是很多文章所提及的,尽量减少 重排和重绘

目前看来重排和重绘只是占了一小部分,更多的是 JS 的运行

chrome 面板通常都是 想看哪里点哪里的。看下 JS 运行了什么

可以看到,已经定位到了某一个具体的 JS 文件,而且这段脚本运行了 20ms。重排占据了20ms。看来还是要减少重排的问题啊!

点击 app.js 去看看

如果想看到具体代码,要有 sourceMap。这里就不多展开了,通常开发环境都有 sourceMap 需要的 .map 文件的。

这么一看一目了然,他们果然没骗我 操作DOM的成本是很高的!

然后这个 demo 优化的部分是从65行开始的:app.optimize 为 true 代表执行优化后的代码。

可以看到 66-78 行中的代码,加起来运行了 6054.5毫秒
而优化的代码:273.7毫秒
好家伙,性能提升了 22 倍(绩效知道咋写了把,优化了项目代码,性能提升 22 倍)

在 JS 下面的紫色小色块,也具体到了某一行代码的运行。也就是我们操作 DOM 的时候的行数了

如此优化下来
可以看到 JS 执行占的 Task 比例明显下降了

Bottom-Up 、CallTree 和 EventLog

这 3 个面板记录了运行时的 调用堆栈

小结

如果坚持看到这里,应该能动每个模块对应什么功能了把。

当然还有 Raster 和 GPU、Chrome_ChildOthread、Compostirot 没说,不过那些貌似影响不大了~。如果还想深究推荐一篇文章:详解谷歌浏览器 performance 选项卡@杏子_1024

最后附上我的博客的截图

细看火焰图,是不是源码执行流程图就出来了?!很多时候源码一大堆入口的时候,并不知道源码执行顺序,配合 Main 的火焰图,就能理清楚执行顺序了

当然了,一定要留意面板上的红色。通常他们的出现都不是什么好东西

这里提示我出现了一个运行了很久的 Long task took 243.79 ms. 这时候就能配合执行的堆栈,定位到具体的 JS 进行优化了。

都去玩起来把,chrome 大法好~

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值