Timeline可以解决：你的程序为什么很缓慢
其中标注数字分别表示：1：获取样本的调用栈；2：获取每次时间线事件的内存信息；3：获取图层位置和绘制的图片（有性能开销）；4：获取记录过程中的截屏（有性能开销）
对于view按钮，默认情况下就是事件模式，点击后，颜色变为蓝色，也表示着转换为了帧模式。今天我们这里主要分析事件模式，所以view按钮无需点亮。
事件模式可以方便我们把异步事件和他们的原因关联起来
DOMContentLoaded和load 事件：
分别以蓝色和红色的短竖线标注，当页面中所有的DOM内容被下载和被分析后出发 DOMContentLoaded 事件，当整个文档的所有资源（包括图片、css等等）后就会触发load事件。
定位强制同步布局:
（一）、布局是浏览器计算元素的位置和大小的过程，一般情况,chrome对于css或者dom的更新都是延迟响应的，这样就可以使chrome对这些更改批处理。但是，当这个应用请求一个布局上要依赖的元素的属性，比如：document.offsetWidth,这就会强制chrome立即同步的对布局作出响应。在一个大的DOM🌲中如果频繁的重复或者响应就会带来巨大的性能瓶颈。（https://developer.chrome.com/devtools/docs/timeline文中有时forced synchronous layouts有时forced asynchronous layout，不是很清楚。。。）
（二）、Timeline工具可以鉴别出应用中哪些地方被强制同步布局，并使用黄色的叹号来警告。如果有warning标注在一套事件之后，说明其子事件中有警告，点击其则展开面板，可以看到详细事件面临的警告。此时点击warning标记，譬如下图蓝色背景的那条记录，则在MEMORY面板的summary中会有详细的原因提示,并且能提示可能产生问题的代码段，这样我们就可以点击进入代码再行分析了。
布局（在firefox中也称reflow），就是浏览器计算元素的大小和位置的过程，那么对于元素的几何属性的使用我们都要慎重。https://developers.google.com/web/fundamentals/performance/rendering/avoid-large-complex-layouts-and-layout-thrashing?hl=zh-cn这里有更透彻的讲解。
关于一套事件：
又是一些事件掩盖在某个事件之下，看起来像是parent/child event,可能有两个原因：1、这些事件同步发生在上个事件处理过程中。每个事件内在的会产生两个原子事件，分别是开始和结束,然后他们会转换成一个“连续”的事件。所有发生在这两个原子过程中的事件也就都成了给事件的“子事件”。如下图所示：在XHR Ready State Change事件执行过程中，发现需要解析相关的Html,所以这个html的解析过程就当做了它的子事件来展示。
一套事件的颜色：
如下图所示，对于“父”事件，一整条的颜色是有变化的，第一段：颜色最深，这个父事件与其所有的同步子事件所用的时间；第二段：颜色略浅，父和所有异步子事件使用cpu的时间；第三段：颜色最浅，表示第一个异步事件到最后一个异步子事件所用的时间。
然而如今的版本，试了几个样本都是只有两个颜色，不知是否我的样本量太小还是这儿改版了。个人感觉是去掉了CPU时间。
聚焦选区：
如上图，在图表区点击一下，即可以定位，如果想扩大选区，可以选中想查看的区域，然后松手会自动聚焦到自己的选区。
参考：https://developer.chrome.com/devtools/docs/timeline
DEMO:分析强制同步布局
http://www.jianshu.com/p/883f8b023251
