使用Chrome DevTools的Timeline和Profiles提升Web应用程序的性能

来源：

http://www.oschina.net/translate/performance-optimisation-with-timeline-profiles

咱们都但愿建立高性能的Web应用程序。因为咱们的应用程序变得愈来愈复杂，咱们可能想要支持丰富的画面以及理想的60帧/秒，这能保证咱们的应用程序响应灵敏且生动流畅。 知道如何衡量和提升性能，是一个有用的技能，在这短短的文章中，我会带您简单回顾关于如何经过 Chrome DevTools的  Timeline  和 Profiles作到这一点。  看！这是一个美丽的GIF动画。这标志着这篇文章这里开始展开:)

Holiday_ 翻译于 3年前 2人顶   顶 翻译的不错哦!

记录 Timeline工具栏提供了对于在装载你的Web应用的过程当中，时间花费状况的概览，这些应用包括处理DOM事件, 页面布局渲染或者向屏幕绘制元素。 它可让你深刻获得三个层面的数据，来帮助你明白问什么你的应用很缓慢：事件, 框架和实时的内存用量。开始，浏览你的应用，并在DevTools中切换到Timeline工具栏。 默认状况下Timeline不会显示任何数据，可是你能够这样开始一个记录会话，打开你的应用并点击灰色圆圈☻，它在工具栏的底部——使用Cmd/Ctrl+E 快捷键也能开始一个记录。 这个记录按钮会从灰色变成红色，而Timeline将开始从你的页面获取时间线（timeline）。在你的应用中完成一些操做，记录到一些数据以后，再一次点击按钮来中止记录。 请注意：会清除你现有的记录会话，以便开始一个新的会话。将会强迫V8完成一轮的垃圾回收，在调试中它颇有用。将会对显示的详细信息进行过滤，只显示那些完成耗时超过15ms的记录。

尚御博豪 翻译于 3年前 1人顶   顶 翻译的不错哦!

检查 接下来，咱们着手检查一下记录的数据。对影响性能的成本要素按优先级排序。是JavaScript吗？仍是渲染？咱们先看一看Timeline Events 模式,它能帮助回答这些问题。 在这个模式中，Summary视图(在Timeline的顶部)显示了一些水平的栅栏，分别表明页面中的网络和HTML解析(蓝色)，JavaScript(黄色)，样式重计算和布局(紫色)以及绘画和合成(绿色)事件。重绘是浏览器事件，是为响应诸如窗口大小改变或者滚动之类的视觉变化而调用的。

super0555 翻译于 3年前 1人顶   顶 翻译的不错哦!

CSS属性的修改会对样式从新进行计算，而布局事件（即重排）是由元素位置的改变引发的。别担忧记不住这些，在Timeline面板下方有图例告诉你。 在Summary视图下面是Details视图，包含了某个会话被记录后，相关类别的记录的详细内容。 每个记录在左侧有用于说明的标题，右侧是时间轴区域。鼠标移到一个记录之上，会显示更多的提示信息，其中包括从开始录制到结束的时间 - 这很是有用，有必要多关注一下，特别是其中的调用栈信息。

zicode 翻译于 3年前 2人顶   顶 翻译的不错哦!

点击调用栈（Call Stack）或者气泡提示中的超连接，会跳转到相应的Javascript代码行。若是你发现一个浏览器时间花费了过多的时间（能够从详细的气泡提示中的‘Duration’知道），你也许会进一步去研究其缘由。 回到记录列表，点击某个记录将其展开，能够看到更进一步的记录，描述了这个记录是由哪些事件组成的。 若是你只对某个特段的数据感兴趣，在Summary视图中经过点击和拖拽能够选择放大的区域。

zicode 翻译于 3年前 1人顶   顶 翻译的不错哦!

改善帧率、动画及响应性能 Chrome把你的应用展现到屏幕上须要生成每一幅帧，而帧模式 可让你能够深刻到每一帧生成的内部细节。 做为平滑的体验，你看到的帧率最好一直保持在30-60fps，若是过低了，你的应用就会由于丢帧看上去 混乱 或者抖动。

zicode 翻译于 3年前 1人顶   顶 翻译的不错哦!

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

zicode 翻译于 3年前 2人顶   顶 翻译的不错哦!

正如Andrey Kosyakov Chromium 的博客中提到的，即便你的程序没有不少动画，帧的概念也是有用的，由于浏览器在处理输入事件时会生成重复动做的序列。若是你在一帧中留有足够的时间处理这些事件，就会使你的程序看上去有更好的响应性，这意味着更好的用户体验。 若是咱们的目标是60fps, 那么最多有 16.66ms 去作全部的事情。这个时间并很少，因此尽量从动画中挤出时间来提升性能仍是很重要的。 让咱们再次放大Summary视图，看一下那些不知足帧率的帧，你就会发现浏览器（以及程序的行为）对此的影响了。

zicode 翻译于 3年前 1人顶   顶 翻译的不错哦!

举个例子，最近咱们使用帧视图（以及事件视图）发现咱们的程序有过多的图像解码，这是由于浏览器须要不断的实时的调整图片的大小。 做为替代方案，为图片预先准备好全部须要的尺寸，咱们就避免了这些开销，从而达到60fps的目标，对于最终用户来讲更为平滑。 相关提示：经过在Settings菜单打开Show FPS meter选项，你能够在DevTool中打开实时的FPS计数器。 这能够在程序的右上角显示一个仪表盘，像下面这样，这使得你能够在程序的帧率低于预期的时候看到直观的反馈。

zicode 翻译于 3年前 1人顶   顶 翻译的不错哦!

移动端 注意在移动端，如同Paul在Breakpoint Ep 4 演示 的那样，动画和帧率都与桌面上大不同，能够差几个数量级。要达到更高的帧率要更困难一些，而像Timeline的帧模式这样的工具（经过 远程调试 链接）能够帮你发现瓶颈所在。 检查耗时的绘制，是困难的 要想检查一段时间内的绘制（paint）是另外一个挑战。若是你打算知道为何某个特定的元素绘制的比较慢，你能够把DOM树中的部分元素设置成display:none将它们从布局/内容树中移除，而且设置visibility:hidden不让它们绘制。而后你能够用Timeline进行录制以便测量，看一下绘制时间，在强制重绘模式中能够观察（实验性的）绘制率（感谢Paul提供的窍门）。

zicode 翻译于 3年前 2人顶   顶 翻译的不错哦!

减小内存使用与避免锯齿形曲线 你的应用有可能会遭受内存泄露问题，Memory 模式对于侦测这种问题的初期症状很是有用。 为使用这个功能，再花几分钟记录你与应用之间的交互，以后中止记录并检查。在 Summary 视图中，你会看到随着你在应用不一样部分之间的跳转，这些动做引发的内存使用状况。其中既有内存使用的攀升，也有普通的垃圾回收发生。 浅蓝色的区域表明一个给定时间里，你的应用所使用的内存大小，而白色的区域是已经分配的内存总量。

super0555 翻译于 3年前 1人顶   顶 翻译的不错哦!

若是你观察到Summary视图中有一个锯齿图形 ，这即是表明了应用的成本费用。例如，一个无参的requestAnimationFrame 函数将带来垃圾，无论怎么说，你须要关注锯齿的陡峭度。若是它变得很是陡峭，说明你制造了太多的垃圾。 你能够进一步的在新的会话记录中,经过与应用之间的交互来测试这一点，空闲几分钟以后中止并再次查看结果。当应用处于空闲（或者你刚刚制造了许多垃圾），V8引擎会执行一系列的垃圾收集过程。若是在你空闲以后，内存彷佛从没有真正的降下来，那么说明你创造了太多的垃圾。

super0555 翻译于 3年前 1人顶   顶 翻译的不错哦!

经过几个周期的垃圾回收，理想状况下内存视图的轮廓应该是扁平的。若是在两个GC周期间隔中它持续不断的上升（你看到会说它是一个阶梯函数），那么你可能会发生内存泄漏。 在Memory模式Detail视图的左侧，你能发现三个选项：文档计数（Document count）,DOM节点计数 (DOM node count)以及事件侦听计数 （Event listener count）。

super0555 翻译于 3年前 2人顶   顶 翻译的不错哦!

DOM节点计数 图显示了保存在内存中的已建立DOM节点的数量（即尚有待垃圾回收的那些节点），而另外两个选项相似的显示了事件侦听与documents/iframe的实例数。要是你只想看特定的计数类型，能够在Details视图取消其它的选择以便将它们隐藏。 咱们如今知道了有潜在内存泄漏的可能，可是咱们应该定位它们的源头。咱们可使用另外的堆分析仪(Heap Profiler)功能，它就在Profiles面板中。

super0555 翻译于 3年前 1人顶   顶 翻译的不错哦!

修复 在肯定使用什么性能分析工具(profile)以前，你要知道是什么致使程序的瓶颈，这一点很重要。例如，若是你看到在Timeline上有不少黄色的部分，那多是脚本产生的问题，能够选择JavaScript CPU 分析工具。若是问题是CSS selector产生的，那就选择CSS Selector 分析工具。 对于咱们的例子，咱们打算使用堆的性能分析工具，由于咱们关心的是 堆的数据，可是正以下面列出的建议，也能够选择其余的性能分析工具。

zicode 翻译于 3年前 1人顶   顶 翻译的不错哦!

性能分析工具中，Take Heap Snapshot的选项可让咱们在怀疑点以前和以后获取内存的快照，获得当时程序中活动的Javascript对象（以及DOM节点）在内存中的分布。 要使用这个功能，点击‘Start’，重复你怀疑（出现你发现的那些信息的时刻）会引发内存泄露的动做，这时记录下第一个快照。 接下来点击record按钮 ☻ 来记录第二个快照，此次不须要与程序进行交互。 咱们如今‘Heap Snapshots’下至少能看到两个快照，让咱们比较一下它们。

zicode 翻译于 3年前 1人顶   顶 翻译的不错哦!

在DevTools窗口的下方，能够看到‘Summary’下拉框，可让你在可见的快照之间切换。Summary 视图适用于DOM泄漏，而Comparison 视图擅长于发现 内存泄漏的缘由。 选择Comparison ，而后点击‘Snapshot 2'。 如今你看到的信息是在profile之间建立的对象。信息的差集可让你对比垃圾收集所删除的内存是否匹配上对象的建立所花费的内存。点击特定的构造函数能够在面板下面的对象的retaining tree视图看到更多信息。

zicode 翻译于 3年前 1人顶   顶 翻译的不错哦!

我知道这可能看起来有点可怕，但请忍受一下。一个典型的应用场景是试图中发现一个你已经删除或者断开关联的一个DOM节点是否任然存在。一旦你发现了形成内存占用的代码，你就能够添加必要的代码来清除那么你不在须要的相关对象。 例如，在应用中咱们发现一个咱们已经卸载的HTMLImageElement元素任然存在。经过点击构造函数，同时一直向下分析，直到咱们发现了那个任然包含了这个图片引用的Window(高亮的) ，如今咱们知道了如何寻找那些不利于窗口对象的事件监听器。

姜鹏飞 翻译于 3年前 2人顶   顶 翻译的不错哦!

总结 衡量和提高你应用程序的性能会须要花费一点事件。不幸的是，到目前为止并无一颗银弹能解决掉全部的问题。可是，DevTools中的Timeline和Profiles能帮助减轻你在发现这些主要问题时的痛苦。你在你的优化工做流中你能够尝试用这些工具，看它是否能帮助到你。 咱们老是在寻找一些能提高他们易用性的一些方法，若是你有什么反馈的话，请在下面任意浏览，或者在 crbug.com上面创建bug投票. 进一步阅读 咱们刚刚在Breakpoint上面发现了关于这个主题的一些话题  - The Tour De Timeline. Patrick Dubroy’s 在OreDev 讨论有关于Timeline 、Heap profiler 和提供了一些如何使用它们的极好例子. Brandon Jones发布的关于如何使用Timeline的 JavaScript memory optimization Colin Snover 去年在 great depth 发布了关于 Timeline 和 Profiler (注意到目前为止有许多UI上的改变). Loreena Lee 有一些如何使用这些工具来修复GMail的内存溢出的一些 presentation .