Chrome开发工具 JavaScript 内存分析

（比如 window 和 document 对象）或者通过保留对本地渲染内存中某些部分的引用而隐式地保留在内存中（就像 DOM 对象）。后者会导致相关的对象无法被内存回收器自动回收，最终造成泄漏。而对象本身含有的内存大小则是 shallow size（一般来说数组和字符串有着比较大的 shallow size）。如果某个对象阻止了其他对象被回收，那么不管这个对象有多大，它所占用的内存都将是巨大的。当一个对象被删除时可以回收的内存大小则被称为保留量。Q:在构建器以及保留视图中有大量的数据。如果我发现存在泄漏的时候，应该从哪里开始找起？一般来说从你的树中保留的第一个对象开始找起是个好办法，因为被保留的内容是按照距离排序的（也就是到 window 的距离）。一般来说，保留的对象中，有着最短距离的通常是最有可能造成内存泄漏的。Q:总结，比较，主导和包含视图都有哪些不同？屏幕的底端可以选择不同的数据视图以实现不同的作用。总结视图可以帮助你在基于构造器名称分组的状态下寻找对象（它们的内存使用状况）。这个视图对于追踪 DOM 泄漏非常有用。比较视图通过显示对象是否被垃圾回收器清理了来帮助你追踪内存泄露。一般用于记录并比较某个操作前后的两个（或更多）内存快照。具体的做法就是，检查释放内存以及引用计数的增量来让你确认内存泄露是否存在并找出其原因。包含视图提供了关于对象结构的一个良好的视角，让我们可以分析在全局命名空间（比如 window）下的对象引用情况，以此来找出是什么让它们保留下来了。这样就可以从比较低的层次来分析闭包并深入对象内部。主导视图帮助我们确认是否有意料外的对象引用依旧存在（它们应该是有序地包含着的）以及垃圾回收确实处于运行状态。Q:在堆分析器中不同的构建器入口对应什么功能？(global property) - 在全局对象（就像是 window）和其引用的对象之间的中间对象。如果一个对象是用名为 Person 的构造器创建的并且被一个全局对象持有，那么保留路径看起来就是这样的：[global] > (global property) > Person。这和对象直接引用其他对象的情况相反，但是我们引入中间对象是有着原因的。全局对象会周期性修改并且对于非全局对象访问的优化是个好方法，并且这个优化不会对全局对象生效。(roots) - 保留树视图中的根节点入口是指含有对选中对象的引用的入口。这些也可以是引擎处于其自身目的而创建的。引擎缓存了引用对象，但是这些引用全部都是弱类型的，因此它们不会阻止其他对象被回收。(closure) - 通过函数闭包引用的一组对象的总数。(array,string,number,regexp) - 引用了数组，字符串，数字或者常规表达式的对象属性列表。(compiled code) - 简单点说，所有事情都和编译后的代码相关。脚本类似于一个函数但是要和 <script> 标签对应。SharedFunctionInfos（SFI）是在函数和编译后的代码之间的对象。函数通常会有上下文，而 SFI 则没有。HTMLDivElement,HTMLAnchorElement,DocumentFragment - 被你的代码引用的特定类型的元素或者文档对象的引用。其他的很多对象在你看来就像是在你代码的生存期内产生的，这些对象可能包含了事件监听器以及特定对象，就像是下面这样：Q:在 Chrome 中为了不影响到我的图表有什么功能是应该关闭的吗？在 Chrome DevTools 中使用设置的时候，推荐在化名模式下并关闭所有扩展功能或者直接通过特定用户数据目录来启动 Chrome（--user-data-dir=""）。如果希望图表尽可能的精确的话，那么应用，扩展插件甚至是控制台日志都可能隐式地影响到你的图表。结束语今天的 JavaScript 引擎在多种情况下都可以自动清理代码中产生的垃圾。也就是说，它们只能做到这里了，而我们的代码中仍然会由于逻辑问题出现内存泄露。请运用这些工具来找出你的瓶颈，并记住，不要去猜测它，而是去测试。