spacewander
chrome devtool 技巧 之 杂项
这一次讲的是关于network、profile等内容。简而言之，就是讲各种杂项。既然讲的是杂项，说的也自然难以找到一个主题。而且对于这些面板，实际上自己也没怎么用过，所以恐怕会讲得枯燥无味些。
network面板
没什么好说的……左边是请求的各项资源，右边是请求、响应所花费的时间。右边这一栏中，浅色的为浏览器请求花费的时间，深色的为服务器响应花费的时间。蓝色线为DOMContented事件发生的时间（就是DOM tree中各个元素已经各就各位的时候），这时候会触发JQuery中的$(document).ready()。而红色线是真正的load事件发生的时间，这时候各项资源已经加载完毕了。
有一个小技巧：在请求图标上右键菜单，可以选择copy as cURL，则能复制出对应的curl请求。（curl党有福了）
timeline面板
可以录制某段时间内发生的浏览器事件，比如render、scroll之类。并显示其对应的开销。 在这里可以清晰地显示浏览器在进行解析html之类的操作所花费的时间和消耗的CPU资源等等。优化强迫症患者必备。
另附：用鼠标滚轮可以放大/缩小所在的区域。
profile面板
点击录制按钮，开始录制CPU开销，或者给heap上分配的内存来个快照。
CPU开销这个基本没有过。给heap上分配的内存拍快照，则有些用途，据说可以查明JS内存泄露的问题。
JS内存泄露
在V8中，除了普通的Number类型（4个byte）和某些特殊的存储在JS VM之外的对象，其他所有的对象都分配在heap上。 这些被分配的对象互相引用，构成了一个图。
假如我们把某个对象当做GC的根对象，那么就可以给其他对象设定一个距离。而所有的互相引用的对象也可以看做一棵树。
不过这里不需要懂得多少概念，因为我们很快就要进入主题 —— JS的内存泄露 —— 了。
如果我们定义内存泄露为“一定时间内存在无法访问但是占据了内存的对象”， 那么有GC的语言也是会发生内存泄露的。
当某些对象不再被其他对象引用时，那么在下一次GC来临之际，它们就会被回收。而如果本应该回收的对象（不再被之后的代码所访问），被某些对象隐式引用了，那么就会导致这个对象不能被回收。这样就导致了内存泄露的问题。
而在JS里，一般这可能会是DOM元素引用或者绑定事件函数到某个不能访问的DOM元素所造成的。
这里举个例子：
varselect=document.querySelector;
vartreeRef=select("#tree");
varleafRef=select("#leaf");
varbody=select("body");
body.removeChild(treeRef); //#tree can't be GC yet due to treeRef
treeRef = null; //#tree can't be GC yet due to indirect reference from leafRef
leafRef = null; //#NOW can be #tree GC
简而言之，不能长期持有对大对象的子节点的引用。因为只要持有这样一个引用，该引用涉及的子节点的parentNode会逐级指向该大对象的根节点，就无法回收整个大对象了。
毕竟这不是一篇讲JS内存泄露的文章，所以感兴趣的读者可以转到下面两个外部资源：
了解 JavaScript 应用程序中的内存泄漏 js的闭包和回调到底怎么才会造成真的内存泄漏呢？
生成报告
注意：profile面板生成的报告需要手动移除（比如点击那个__禁止__标记）。否则再次打开面板那个报告还是继续存在
报告有几种显示的选项，其中： summary是默认选项，显示heap上的内存分配情况。 comparison可以显示两个报告之间的变化。
我们主要看一下报告的格式：
从左到右各列为：
- Constructor 构造函数
- distance 距根节点的距离
- Objects Count 个数
- Shallow Size 占用内存
- Retained Size 自身加引用的节点总共占用的内存
其中背景为黄色的元素是被JS引用的DOM元素，红色背景的元素是已经被移除但还未被回收的，比如上面例子中的#tree。
具体怎么发掘出内存泄露的问题？这篇文章基本上把具体步骤给讲清楚了，我就不转译了。
