Jioho 的博客

chrome Performance 使用

1/24/2021 工具

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/ (opens new window)

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

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

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

打开：https://ping.chinaz.com/googlechrome.github.io (opens new window)

根据几个指标

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

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

# 设置 demo

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

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

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

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

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

# 查看录制效果并分析

# 帧率，CPU，网络情况

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

  • FPS 百度百科 FPS (opens new window)
    FPS 就是 绿色的那条，越高越好。当然也会出现红色的情况

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

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

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

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

  • 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 - 等待时间
1
2
3
4
5
6

# 火焰图 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 (opens new window)

最后附上我的博客的截图

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

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

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

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

Last Updated: 5/9/2021, 10:45:03 PM