Chrome运行时性能瓶颈分析

一，初探，根据现象发现问题

chrome的performance知道好久了，但老是没有特别权威且跟上时代的学习资料，此次痛定思痛，直接看英文文档，一点点把这块啃掉，本笔记基于Chrome 59

---

step 1: 隐身模式打开chrome

目的是避免缓存以及没必要要的问题

---

step 2: 打开测试地址

谷歌性能测试地址googlechrome.github.io/devtools-sa…
能够看到以下的页面：

页面中有一些蓝色小方块在运动

---

step 3: 限制cpu速度

因为有些用户的设备cpu性能很高，没法很好的分析移动端，或者发现低级设备的性能问题，因此咱们要降速
找到控制台中的performance项，找到CPU选项，选择下降4倍性能或6倍性能

---

step 4：添加运动小块，找到性能瓶颈

前面限制了cpu的性能，接下来就要找到性能瓶颈了
连续点击Add 10按钮，向页面中添加小块，直到本身都感受页面上小块运动出现明显卡顿

相似下面这种状况，就已经明显卡顿了

---

step 5：先看看优化后的效果会怎样？

点击一下Optimize优化，观察一下效果

能够看到页面瞬间变的贼流畅

---

step 6：体验过优化，再体验一次不优化

再点击一次Un-Optimize（不优化）按钮，能够看到又卡的要死

ok，到这里，你们已经可以经过现象发现性能的差别了，接下来就是要分析现象了

---

二，了解performance各模块

如何分析现象，确定要依赖数据，这里就要用到chrome的performance功能了
先将页面切到非优化的状态，点击“录制”按钮

录制4s-5s便可：

而后就能够看到录制的效果了：

上面这些数据看不懂不要紧，如今来一步步了解各个部分都有哪些内容

---

step 1：了解Fps

fps：是指页面每秒帧数
fps = 60 性能极佳
fps < 24 会让用户感受到卡顿，由于人眼的识别主要是24帧

图中蓝色标注出来的区域，就是FPS记录的信息
放大点看，FPS由两部分组成：
1，红色的条
2，绿色的半透明条

---

action :1  切换至“已优化”状态

此时切换优化状态，到已优化的状态，再次进行性能录制：

获得Fps数据以下：

能够看到此时：
1，没有了红色条
2，绿色半透明条的高度，明显要比未优化的场景高度要高很多

总结：

• 红色：意味着帧数已经降低到影响用户体验的程度，chrome已经帮你标注了，这块有问题

• 绿色：其实就是Fps指数，全部绿色柱体高度越高，性能越好

---

step 2：了解Cpu

上图中Fps下面的位置，便是Cpu信息
咱们再采集一个真实业务的cpu数据，以下图：

对比能够发现，cpu数据的一些特性：

• 1，cpu包括两种状态：

  • （1）充满颜色

  • （2）不充满颜色

• 2，cpu是否充满颜色和fps存在联系

---

step 3：了解Net

Net部分能够将屏幕逐帧录制下来，能够帮助观察页面的状态，主要用处，能够帮助分析首屏渲染速度

---

step 4：了解Frames

1，查看特定帧的fps

Frames部分，主要用于查看特定帧的fps，能够查看特定的帧状况。

2，悬停其上，能够查看数据

能够看到：

• 这一帧的时间间隔是129.1ms

• 当前的fps是1000ms/129.1ms = 7.75fps，约等于8fps

这里主要体现的是页面两次刷新之间间隔了129.1ms

3，点击Frames块，获得更详细的数据

点击Frames能够显示当前关键帧的详细信息：

• 1，duration是当前帧从796.31ms开始等待，796.31ms+127.73ms后进行了一次渲染

• 2，fps仍是老算法，1000ms/127.73ms约等于7fps

• 3，最下面是关键帧的视图画像

---

step 5：了解FPS快捷工具

1，在chrome中，还有格more tools选项，选中rendering选项

2，开启fps meter开关

3，直接在页面上，出现了一个fps统计器

这个东西，暂时先关闭，不利于系统性的学习

三，找到瓶颈

前面已经知道咱们的测试页面有性能问题，那么接下来就要想为何了？

---

step 1：了解Summary

对性能进行录制完成的时候，会默认在底部展现一个Summary摘要，显示全局的信息

上面展现了0～5.52s录制时间的具体耗时：

• 1，script执行耗时1952.8ms

• 2，render渲染耗时2986.8ms

• 3，Painting重绘耗时472.1ms

主要就是这3个耗时，知道了这三部分耗时，只是知道了，哪有问题，但具体问题在哪呢？

---

step 2：了解Main

---

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

---

目前这样看不出来什么，脑袋疼，为了方便咱们观看，咱们能够在fps、cpu、net模块，点击一下，缩小时间区间

如上图，能够经过缩小时间区间，从而放大Main中的内容
如今已经可以看到，Main中展现的是火焰图，也就是函数调用的堆栈

火焰图，能够简单理解，x轴表示时间，y轴表示调用的函数，函数中还包含依次调用的函数，y轴只占用x轴的一个时间维度

---

step 3：识别问题，红色三角号

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

上图能够看到提示了Warning : 重复处理程序耗时287.77毫秒

---

step 4：追溯问题，定位代码位置

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

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

---

step 5：进一步分析问题位置

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

能够看到，每一个小紫条上，都有一个红色三角
前面提到：红色三角就是chrome帮助自动识别有问题的地方
查看提示信息： 强制回流多是性能瓶颈
点击查看摘要：

能够看到问题定位在了，app.js的71行，点击查看，可以看到是对每个元素进行样式修改

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

避免这种状况的出现，能够参考developers.google.com/web/fundame…

---

step 6：对比优化的效果

demo中存在两种状态，优化和非优化
能够看到优化的状态，script和render的时间都大大减小了
因此fps明显提升

step 7：性能优化的知识储备

使用rail模型测量性能developers.google.com/web/fundame…
基础储备：

• 渲染性能概述developers.google.com/web/fundame…

• A Frame 的剖析aerotwist.com/blog/the-an…