Chrome开发工具 JavaScript 内存分析

以及如何找到它们。你也可以继续尝试后面这个例子DOM 泄露斌想象的要更多。想要了解更多关于 DOM 泄露以及内存分析的基础内容，请参阅 Gonzalo Ruiz de Villa 编写的 Finding and debugging memory leaks with the Chrome DevTools。总结视图和包含视图更加容易找到本地对象 - 在视图中有对应本地对象的入口节点：示例：尝试这个示例（在新选项卡中打开）来体验分离的 DOM 树。主导视图主导视图显示了堆图的主导树，从形式上来看，主导视图有点像是包含视图，但是缺少了某些属性。这是因为主导者对象可能会缺少对它的直接引用，也就是说，主导树不是生成树。注意：在 Chrome Canary 中，主导视图可以在 Settings > Show advance snapshots properties 中启用，重启浏览器之后就可以选择主导视图了。示例：尝试这个例子（在新选项卡中打开）来看看你能不能找到积累点。随后可以尝试运行 retainning paths and dominators。对象分配追踪器对象追踪器结合了堆分析器中快照的详细信息以及时间轴的增量更新以及追踪信息。跟这些工具相似，追踪对象堆的分配过程包括开始记录，执行一系列操作，以及停止记录并分析。对象分析器在记录中周期性生成快照（大概每 50 毫秒就会生成一次），并且在记录最后停止时也会生成一份快照。堆分配配置文件显示了对象在哪里创建并且标识出了保留路径。开启并使用对象追踪器要开始使用对象追踪器：确认你安装了最新的 Chrome Canary。打开 DevTools 并点击右边下面的齿轮图标。现在，在配置面板中，你可以看见一项名为 "Record Heap Allocations" 的配置。顶栏的条形图表示对象什么时候在堆中被找到。每个条形图的高度对应最近分配的对象的大小，而其颜色则说明这些对象在最后的快照中是否还处于生存周期：蓝色表示在时间轴的最后该对象依旧存在，灰色则说明对象在时间轴内被分配，但是已经被垃圾回收器回收了。在上面的例子中，一个操作被执行了10次。这个简单的程序加载了五个对象，所以显示了五个蓝色的条形图案。但是最左边的条形图表明了一个潜在的问题。接下来你可以使用时间轴中的滑动条来放大这一特定的快照，然后查看最近被分配到这一点上的对象。点击堆中的某个特定对象会在堆快照的顶部显示其保留树。检查对象的保留路径会让你明白为什么对象没有被回收，并且你可以在代码中做出变动来一出不需要的引用。内存分析的问题Q:我并没有看到对象的所有属性，我也没看到那些非字符串 的值，为什么？不是所有的属性都储存在 JavaScript 堆中。其中有些是通过执行了本地代码的获取器来实现的。这样的属性不会在堆快照中被捕获，因为要避免调用获取器的消耗并且要避免程序声明的变化（当获取器不是“纯”方法的时候）。同样的，非字符串值，像是数字等为了缩小快照的大小也没有捕获。Q:在 *@* 字符后面的数字意味着什么 - 这是一个地址或者 ID 吗？ID 的值是不是唯一的？这是对象 ID。显示对象的地址毫无意义，因为对象的地址在垃圾回收期间会发生偏移。这些对象 ID 是真正的 ID - 也就是说，他们在生存的多个快照都会存在，并且其值是唯一的。这就使得你可以精确地比较两个不同时期的堆状态。维护这些 ID 增加了垃圾回收周期的开销，但是这只在第一份堆快照生成后才初始化 - 如果堆配置文件没有使用到的话，就没有开销。Q:“死亡”的（无法到达）对象是否会包含在快照中？不会，只有可到达的对象才会在快照中出现。并且，生成一份快照的时候总是会先开始进行垃圾回收。注意：在编写代码的时候，我们希望避免这种垃圾回收方式以减少在生成堆快照时，已使用的堆大小的变动。这个还在实现中，但是垃圾回收依旧会在快照之外执行。Q:GC 根节点是由什么组成的？许多东西：内置的对象映射符号表虚拟机线程栈编译缓存处理范围全局句柄Q:教程中说使用堆分析器以及时间轴内存视图来查找内存泄露。首先应该使用什么工具呢？时间轴，使用该工具可以在你意识到页面开始变慢的时候检测出过高的内存使用量。速度变慢是典型的内存泄露症状，当然也有可能是由其他情况造成的 - 也许你的页面中有一些图片或者是网络存在瓶颈，所以要确认你是否修复了实际的问题。要诊断内存是不是造成问题的原因，打开时间轴面板的内存视图。点击纪录按钮然后开始与程序交互，重复你觉得出现问题的操作。停止记录，显示出来的图片表示分配给应用程序的内存状态。如果图片显示消耗的内存总量一直在增长（继续没有下落）则说明很有可能出现了内存泄露。一个正常的应用，其内存状态图应该是一个锯齿形的曲线图，因为内存分配后会被垃圾回收器回收。这一点是毋庸置疑的 - 在 JavaScript 中的操作总会有所消耗，即使是一个空的 requestAnimationFrame 也会出现锯齿形的图案，这是无法避免的。只要确保没有尖锐的图形，就像是大量分配这样的情况就好，因为这意味着在另一侧会产生大量的垃圾。你需要在意的是，这条曲线陡度的增加速率。在内存视图中，还有DOM 节点计数器，文档计数器以及事件监听计数器，这些在诊断中都是非常有用的。DOM 节点使用原生内存，并且不会直接影响到 JavaScript 内存图表。如果你感觉程序中出现了内存泄露，堆分析器可以帮助你找到内存泄露的来源。Q:我注意到在堆快照中有一些 DOM 节点，其中有些是红色的并且表明是 “分离的 DOM 树” 而其他的是黄色的，这意味着什么？你会注意到这些节点有着不同的颜色，红色的节点（其背景较暗）没有 JavaScript 对其的直接引用，但是依旧处于生存期，因为他们是分离的 DOM 树的一部分。可能会有一些节点在 JavaScript 引用的树中（可能是闭包或者变量）但是却刚好阻止了整棵 DOM 树被回收。黄色的节点（其背景也是黄色的）则是有 JavaScript 对象直接引用的。在同一个分离 DOM 树中查找黄色节点来锁定 JavaScript 中的引用。从 DOM 窗口到达相关元素应该是一条属性链（比如，window.foo.bar[2].baz）下面是关于独立节点在整幅图中位置的一个动画：例子：尝试这个关于独立节点例子，通过这个例子你可以看到节点在时间轴中的变化过程，并且你可以生成堆快照来找到独立节点。Q:Shallow 以及 Retained Size 表示什么？它们之间有什么区别？实际上，对象在内存中的停留是有两种方式的 - 通过一个其他处于生存期的对象直接保留在内存中