JavaScript功用故事：挑选可视化办法

　　不完美的堆造就完美的图形

　　我写的东西能供给多少价值，将由其快速确诊内存配置文件问题的才干的巨细决议。考虑到我能够运用直觉工程 来增强可视化的办法，我提出了三个成功的规范:

　　能够很简略创立基线。 这样用户就能够在不同的堆配置文件或时刻样本之间垂手可得的看出差异。

　　能够快速有效地传达问题。

　　能够有效地显现许多节点。 许多，许多，许多。

　　为了有效地创立基线，咱们需求一些能够一望而知就能表明许多相关数据的东西。 我用来表明节点的两种东西是巨细和色彩。 经过巨细制作节点，能够快速的将占用内存大的使用程序给高亮显现出来。 相似地，经过色彩会直接点也能够一望而知的剖析堆状况。

　　有了这个整体思路,怎样传达问题这个难题也就方便的处理了。结合Chrome堆配置文件的输出和我自己的经历，我知道节点本身巨细和保存巨细至关重要。 我也知道我需求找出一些代表保存者的办法，由于它们在处理内存问题方面发挥了关键作用。

　　第一个猜想？力导向图

　　需求寻找出一个能够既能够独自显现实体格局巨细的和色彩的，又能够指示出它们之间的联系，因而我想到了力导向图。

(图片来历：Martin Grandjean)

　　力导向图十分棒！为了表现通讯的重要性,它们会检查一切的box——有效地表明不同巨细的节点，色彩，它们显现节点之间的联系。D3乃至供给了一个强制布局模块，使得它能够很简略地完结其间一个sucker。

　　不幸的是，它们没有到达功用的要求。强制布局的核算成本很高。大多数阅览器需求几分钟的时刻来布局数千个节点。 此外，当它们变大时，看上去也会变得很拥堵。

　　带有20万个节点的力导向图(图片来历：graphmap.net)

　　假如我的东西需求花费很长时刻来安置堆，或许假如很难取得关于单个节点的相关确诊信息，那么它也不会比手艺解析数据更有用。 最终，我决议pass力导向图这个选项。

　　要不试试圆形图？

　　关于力导向图，它们运用了圆形来代表节点，这个做法我的确是很喜爱。从视觉的视点来说，仍是很有吸引力的，也比较简略了解。 当然，假如它画图的价值不是那么高就好了！

　　在烘托force layout的过程中，大多数的难题都是来自于需求制作出节点之间的相关性。假如我能找到一个相似的布局，但没有明确地制作边际，那么我就能够烘托一切需求的节点。

　　进入圆包。

　　看一下圆形图的作用：

　　(图片来历：Mike Bostock 和 Jeff Heer)

　　我在这里看到了一些潜在的优势 - 它具有力导向图的许多长处 - 圆形节点，五颜六色节点和相对巨细的一望而知 - 可是却不像力导向图那样需求去核算目标之间的相关。

　　当然我也看到了一些缺陷:

　　1.关于深度嵌套的层次结构，它的功率很低。

　　2.很难表现出节点之间的非层次联系。

　　为了处理第一个问题，我决议尽或许地把数据拉平。请记住，内存一般表明为图形，有时也会表明为分配树，默许状况下不分层，可是假如需求，它也能够按类型或其他约束进行分组。

　　接下来说一下第二个问题。我喜爱圆形布局，我以为需求展现给用户的仅有指示是文本列表，以及节点上的数字。往往只会在确认问题之后呈现，才干感受到保存者的价值，所以我决议简化开始的可视化，只包含那些有问题的元素。

　　荣誉奖：Treemap

　　您或许会想，已然大型数据集的功用要求如此之高，为什么不运用Treemap呢?

(图片来历：MDN)

　　我来讲一下为什么最初我没有挑选Treemap的实在原因吧:

　　Treemaps看起来并不像圆形布局那样具有视觉吸引力；

　　它太简略了！与其他图形类型比较，构建一个树形图所需求支付的核算价值太小了；

　　Firefox现已做到了。

　　我现已采用了圆形布局作为我的可视化办法，下面简述一下几个额定的原因。

　　我不关心超出节点类型的层次结构。 树图能够快速显现层次结构中的分量，但关于一个相对平整的树，要制作出概括就愈加困难了。

　　从某种意义上说，圆形布局一般以为比同等的树形图更简略耗费视觉作用。 我信任他们讲到了一个要点- 节点之间的空间使得它更简略被识别组之间的方式。

　　所以，问题就处理了！ 我决议运用圆形布局，并将其视为可视化内存堆的一个很好的挑选。