【转载】DevTools性能分析文档

https://gist.github.com/the1sky/7887088#file-devtools

DevTools性能分析文档

本文只谈性能，其它请参见devTool官方文档

[email protected]

---

Timeline解读

可以理解为接收webkit渲染过程中产生的事件，并可进行分析的平台，请按Ctrl + Shift + I，选择timeline

每一个事件在timeline中被称为一个record

查看模式

分为三个模式：事件、帧和内存，其中帧模式是最常用也是最有效的模式。

事件模式

直观查看页面在渲染过程中的事件流

一目了然的发现耗时长的事件

发现有超过16.7ms的事件，开始兴奋吧，少年！
为什么是16.7ms? 请仔细阅读帧模式

enter image description here

帧模式

无以伦比的强大，多个事件的组合

直观获取页面性能概况

30fps & 60fps线很有爱

enter image description here

什么是帧？

可以理解为一次完整的呈现，包括硬件帧和软件帧

硬件帧

想想屏幕的刷新频率，60hz/s, 其实就是1s时间内产生了60个屏幕画面

软件帧

想象下经常玩的游戏，遇到过15fps的情况？

15fps就是指在1s时间内产生了15个游戏画面

见下图：

enter image description here

为什么是16.7ms?

理想情况下:1000ms / 60 = 16.7ms

正常情况下：1000ms / 24 = 41.7ms

目标-------------------------------->16.7ms

超过41.7ms的帧肯定是无法容忍的

[google devtools大会上的演示]

timeline帧的组成？

在一帧内，浏览器必需要把帧的内容渲染到屏幕上，包含如下操作：

运行JS

事件处理

更新DOM

更改样式

布局(layout)

绘制(paint)

webkit内核中的帧的组合逻辑？

跟踪源代码中...

内存模式

能直观的看到性能的拐点，就是内存空间大起大落的地方

下部有对应的recording

由于内存优化暂时不是重点方向，没有进行深入的思考

enter image description here

timeline record

一个record对应一个事件，按类型划分包括loading、scripting、rendering和painting

loading

加载相关的事件，主要包括：

Send Request

Receieve Response

Receieve Data

Finish Loading

Parse HTML

scripting

js相关的事件，主要包括：

Evaluate Script

Function Call

Event

Timer Fired

Install Timer

Remove TImer

DOMContentLoaded

Request Anination Frame

Animation Frame Fired

Cancel Anination Frame

rendering

布局相关的事件，主要包含：

Invalidate layout

Layout

REcalculate style

scroll

painting

绘制相关的事件，主要包含：

paint

快捷键

开始记录

Ctrl + E

重新加载页面

Ctrl + R

停止记录

Ctrl + E

辅助工具

show paint rectangles

显示绘制区域

show composited layer border

显示组合层中每个层的边框

什么是composited layer会下文中详谈

Enable continuous page repainting

对调试很有帮助

show FPS meter

帧率显示，粗略看动态性能

Show potential scroll bottlenecks

[在演示性能瓶颈问题时会用到这些辅助工具]

页面渲染过程

总体是这个样子的

Html -> Dom Tree

Dom Tree -> RenderObject Tree

RenderObject Tree -> RenderLayout Tree

分支出现：

software path

hardware path

enter image description here

software path

传统的渲染流程

RenderLayout进行层控制

RenderObject.paint()，直接把自己绘制到一个Bitmap

这个Bitmap是在在内容中开辟的一块空间，通过Webkit/Skia的GraphicsContext

这个Bitmap就是将要用来进行呈现的屏幕内容

so, 你看到了你想看的

enter image description here

harewar path

也就是所谓的硬件加速

会进行 RednerLayout Tree -> GraphicsLayer Tree

引入Compositor的概念，产生能供GPU使用的指令，调用GPU的GL/D3D，传递指令及相关的Bitmap及顶点信息

不像software path只有个一个GraphicsCotext, 这里是每个GaphicsLayout对应一个GraphicsContext

因为每个假如每个RenderLayout都需要要给GraphicsLayout会造成内存的大量浪费，故只有符合特定条件的renderLayout才能有自己的GraphicsLayout, 否则只能使用其父级对象的GraphicsLayout,所谓的特定条件如下（copy自官方）：

1、Layer has 3D or perspective transform CSS properties

2、Layer is used by video element using accelerated video decoding

3、Layer is used by a canvas element with a 3D context or accelerated 2D context

4、Layer is used for a composited plugin

5、Layer uses a CSS animation for its opacity or uses an animated webkit transform

6、Layer uses accelerated CSS filters

7、Layer with a composited descendant has information that needs to be in the composited layer tree, such as a clip or reflection

8、Layer has a sibling with a lower z-index which has a compositing layer (in other words the layer is rendered on top of a composited layer)

符合上述条件的RednerLay，会被称作Composited layer

Compositor所做的工作就是组合Composited layer，对应DevTools Timeline中出现的Composite Layout记录

之后，Composited layer及顶点信息和处理指令会被传递到GPU

so, 你看到了你想看的，只是相较于software_path,内部流程变了

enter image description here

layers

如上述渲染流程

页面渲染分层渲染的

包括普通的layout和composited layout

普通的layout直接通过browser process，并最终展示在屏幕上

composited layout通过GPU Process，直接显示在屏幕上

使用compostied的优势是很明显的，在进行repaint的时候，只需要重绘独立的一个composited layout并提交给GPU处理

其实绘制过程（即格栅化过程）都是由Skia完成，这个是有必要而且是正在进行的改进，引入了Accelerated Painting的概念，用到了Ganesh技术

Ganesh，简单讲就是能够根据render layer，记录SKPicture指令，后续通过回放这些SkPicture命令就可以来格栅化图层，这些SkPicture可以通过Ganesh产生对应的GL指令

paint和composite

这两个概念容易混淆，通过以上的内容，应该有一定的区分了

paint

就是renderLayer绘制到Bitmap

composite

当使用GPU加速时的概念

分层处理，并最终通过GPU合成处理

格栅化（插播）

上文略有提到，刚提到paint，在这里插播下

paint干的活就是格栅化的过程

矢量 ---------> 位图(Bitmap)

enter image description here

reflow和repaint

先看下正常的渲染绘制图：

enter image description here

reflow指元素style的变更引起的render tree的重构，这里的style指代的是引起元素几何属性变更的样式

width、height、margin、border和left/top等

repaint一般由reflow引起，但不一定

比如更改一个div的background-color，由于元素的几何属性没发生变化，不会发生reflow，但会repaint

切记：reflow和repaint的代价很昂贵！

聪明的浏览器

假如针对每次style的变更都进行reflow和repaint，可以想象下将会发生什么。

浏览器会进行所谓的‘批处理’

创建一个队列

保存样式变更的请求

批量执行队列内容，统一进行reflow和repaint

达到一定的时间或一定的样式变更请求次数

但是呢？

总有一些样式的请求需要立马知道元素当前的最新样式

这样就会打断浏览器处理的节奏

浏览器就这么很不情愿的进行强制reflow和repaint，这也是下面将要谈的‘强制同步布局’，绝对的性能瓶颈

什么拖慢了你的页面

强制同步布局

forced

耗时的CSS

耗时的onscroll()

耗时的event handlers

Image resize/decode

settimeout/requestAnimationFrame()

银弹

timeline指标说明

参考：
1、http://www.phpied.com/rendering-repaint-reflowrelayout-restyle/

2、