使用Chrome DevTools的Timeline进行性能优化

我们都希望创建高性能的Web应用程序。由于我们的应用程序变得越来越复杂,我们可能想要支持丰富的画面以及理想的60帧/秒,这能保证我们的应用程序响应灵敏且生动流畅。

知道如何衡量和提高性能,是一个有用的技能,在这短短的文章中,我会带您简单回顾关于如何通过 Chrome DevTools的 Timeline 和Profiles做到这一点。
看!这是一个美丽的GIF动画。这标志着这篇文章这里开始展开:)

记录

Timeline工具栏提供了对于在装载你的Web应用的过程中,时间花费情况的概览,这些应用包括处理DOM事件页面布局渲染或者向屏幕绘制元素

Timeline工具栏

它可以让你深入得到三个模式的数据,来帮助你明白问什么你的应用很缓慢:事件框架实时的内存用量。开始浏览你的应用,并在DevTools中切换到Timeline工具栏。

模式

默认情况下Timeline不会显示任何数据,但是你可以这样开始一个记录会话,打开你的应用并点击灰色圆圈☻,它在工具栏的底部——使用Cmd/Ctrl+E快捷键也能开始一个记录。

图标

这个记录按钮会从灰色变成红色,而Timeline将开始从你的页面获取时间线(timeline)。在你的应用中完成一些操作,记录到一些数据之后,再一次点击按钮来停止记录。

请注意:清除会清除你现有的记录会话,以便开始一个新的会话。垃圾回收将会强迫V8完成一轮的垃圾回收。过滤在调试中它很有用。将会对显示的详细信息进行过滤,只显示那些完成耗时超过15ms的记录。

检查

接下来,我们着手检查一下记录的数据。对影响性能的成本要素按优先级排序。是JavaScript吗?还是渲染?我们先看一看Timeline Events模式,它能帮助回答这些问题。

Timeline Events

在这个模式中,Summary视图(在Timeline的顶部)显示了一些水平的栅栏,分别代表页面中的网络和HTML解析(蓝色),JavaScript(黄色),样式重计算和布局(紫色)以及绘画和合成(绿色)事件。重绘是浏览器事件,是为响应诸如窗口大小改变或者滚动之类的视觉变化而调用的。

CSS属性的修改会对样式重新进行计算,而布局事件(即重排)是由元素位置的改变引起的。别担心记不住这些,在Timeline面板下方有图例告诉你。

面板图例

在Summary视图下面是详情视图,包含了某个会话被记录后,相关类别的记录的详细内容。

详情视图

每一个记录在左侧有用于说明的标题,右侧是时间轴区域。鼠标移到一个记录之上,会显示更多的提示信息,其中包括从开始录制到结束的时间 – 这非常有用,有必要多关注一下,特别是其中的调用栈信息。

详情视图

点击调用栈(Call Stack)或者气泡提示中的超链接,会跳转到相应的Javascript代码行。如果你发现一个浏览器时间花费了过多的时间(可以从详细的气泡提示中的‘Duration’知道),你也许会进一步去研究其原因。

跳转

回到记录列表,点击某个记录将其展开,可以看到更进一步的记录,描述了这个记录是由哪些事件组成的。

事件

如果你只对某个特段的数据感兴趣,在Summary视图中通过点击和拖拽可以选择放大的区域。

放大

改善帧率、动画及响应性能

Chrome把你的应用展示到屏幕上需要生成每一幅帧,而帧模式可以让你可以深入到每一帧生成的内部细节。

帧模式

作为平滑的体验,你看到的帧率最好一直保持在30-60fps,如果太低了,你的应用就会因为丢帧看上去混乱或者抖动。

在帧模式下,带阴影的竖条对应正在重计算样式、正在组合等等情况。每个竖条的透明区域对应于空闲时间,至少对于你的页面是空闲的。例如,假设第一帧用了15ms,下一帧用了30ms。通常每一帧都会按刷新率进行同步,这个例子中第二帧的渲染多花了15ms,导致第三帧错失了”真正“的硬件帧的时间,直接跳到下一帧的渲染。这样,第二帧的实际生效时间就加倍了。

帧

正如Andrey Kosyakov的博文中提到的,即使你的程序没有很多动画,帧的概念也是有用的,因为浏览器在处理输入事件时会生成重复动作的序列。如果你在一帧中留有足够的时间处理这些事件,就会使你的程序看上去有更好的响应性,这意味着更好的用户体验。

FPS

让我们再次放大Summary视图,看一下那些不满足帧率的帧,你就会发现浏览器(以及程序的行为)对此的影响了。

放大

举个例子,最近我们使用帧视图(以及事件视图)发现我们的程序有过多的图像解码,这是因为浏览器需要不断的实时的调整图片的大小。

图像解码

作为替代方案,为图片预先准备好所有需要的尺寸,我们就避免了这些开销,从而达到60fps的目标,对于最终用户来说更为平滑。

相关提示:通过在Settings菜单打开Show FPS meter选项,你可以在DevTool中打开实时的FPS计数器。

FPS计数器

移动端

注意在移动端,如同Paul在Breakpoint Ep 4演示的那样,动画和帧率都与桌面上大不一样,可以差几个数量级。要达到更高的帧率要更困难一些,而像Timeline的帧模式这样的工具(通过远程调试连接)可以帮你发现瓶颈所在。

检查耗时的绘制,是困难的

要想检查一段时间内的绘制(paint)是另一个挑战。如果你打算知道为什么某个特定的元素绘制的比较慢,你可以把DOM树中的部分元素设置成display:none将它们从布局/内容树中移除,并且设置visibility:hidden不让它们绘制。然后你可以用Timeline进行录制以便测量,看一下绘制时间,在强制重绘模式中可以观察(实验性的)绘制率。

减少内存使用与避免锯齿形曲线

你的应用有可能会遭受内存泄露问题,Memory模式对于侦测这种问题的初期症状非常有用。

Memory模式

为使用这个功能,再花几分钟记录你与应用之间的交互,之后停止记录并检查。在 Summary 视图中,你会看到随着你在应用不同部分之间的跳转,这些动作引起的内存使用情况。其中既有内存使用的攀升,也有普通的垃圾回收发生。

浅蓝色的区域代表一个给定时间里,你的应用所使用的内存大小,而白色的区域是已经分配的内存总量。

如果你观察到Summary视图中有一个锯齿图形 ,这便是代表了应用的成本费用。例如,一个无参的requestAnimationFrame 函数将带来垃圾,不管怎么说,你需要关注锯齿的陡峭度。如果它变得非常陡峭,说明你制造了太多的垃圾。

锯齿图形

你可以进一步的在新的会话记录中,通过与应用之间的交互来测试这一点,空闲几分钟之后停止并再次查看结果。当应用处于空闲(或者你刚刚制造了许多垃圾),V8引擎会执行一系列的垃圾收集过程。如果在你空闲之后,内存似乎从没有真正的降下来,那么说明你创造了太多的垃圾。

通过几个周期的垃圾回收,理想情况下内存视图的轮廓应该是扁平的。如果在两个GC周期间隔中它持续不断的上升(你看到会说它是一个阶梯函数),那么你可能会发生内存泄漏。

内存泄漏

在Memory模式Detail视图的左侧,你能发现三个选项:文档计数(Document count),DOM节点计数 (DOM node count)以及事件侦听计数 (Event listener count)。

计数

DOM节点计数图显示了保存在内存中的已创建DOM节点的数量(即尚有待垃圾回收的那些节点),而另外两个选项类似的显示了事件侦听documents/iframe的实例数。要是你只想看特定的计数类型,可以在Details视图取消其它的选择以便将它们隐藏。

我们现在知道了有潜在内存泄漏的可能,但是我们应该定位它们的源头。我们可以使用另外的堆分析仪(Heap Profiler)功能,它就在Profiles面板中。

发表评论

电子邮件地址不会被公开。 必填项已用*标注