使用Chrome DevTools的Timeline和Profiles提高Web应用程序的性能 已翻译 100%

MR-Feng 投递于 2013/06/07 15:21 (共 19 段, 翻译完成于 07-01)
阅读 60194
收藏 88
19
加载中

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

知道如何衡量和提高性能,是一个有用的技能,在这短短的文章中,我会带您简单回顾关于如何通过 Chrome DevTools的 Timeline Profiles做到这一点。

看!这是一个美丽的GIF动画。这标志着这篇文章这里开始展开:)

YuanyuanL
翻译于 2013/06/17 10:12
2

记录

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

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

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

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

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

御豪同学
翻译于 2013/06/17 14:09
1

检查

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

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

super0555
翻译于 2013/06/18 00:05
1

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

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

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

zicode
翻译于 2013/06/18 13:13
2

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

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

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

zicode
翻译于 2013/06/18 13:21
2

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

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

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

zicode
翻译于 2013/06/18 13:30
2

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

zicode
翻译于 2013/06/20 10:03
3

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

如果我们的目标是60fps, 那么最多有 16.66ms 去做所有的事情。这个时间并不多,所以尽可能从动画中挤出时间来提高性能还是很重要的。

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

zicode
翻译于 2013/06/20 10:12
3

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

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

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

这可以在程序的右上角显示一个仪表盘,像下面这样,这使得你可以在程序的帧率低于预期的时候看到直观的反馈。

zicode
翻译于 2013/06/22 22:45
2

移动端

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

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

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

zicode
翻译于 2013/06/22 23:08
2
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(11)

javadoc
javadoc
看了这边受益匪浅!!!
OSC-allen
OSC-allen
很有用,非常感谢
g8up
g8up
搞懂这个功能,还需要有实例。
IMU
IMU
深入性能分析第一步,如何发现性能问题,不错的开端,对了解底层实现很有帮助。
顺便挂个广告,百度新闻招聘靠谱前端,有意向的pm~
IMU
IMU
深入性能分析第一步,如何发现性能问题,不错的开端,对了解底层实现很有帮助。
顺便挂个广告,百度新闻招聘靠谱前端,有意向的pm~
小小流浪猫
小小流浪猫

蔺文龙
蔺文龙
这篇文章,绝对是前端宝典
tangguo168
tangguo168
一直想找中文版的看,谢谢楼主的贡献精神。
love-Teddy
love-Teddy
相当有用!
杨军军
杨军军
有用
返回顶部
顶部