Java的Swing真的是“记忆力”吗?

时间:2011-05-02 23:21:12

标签: java swing user-interface memory-management

我经常听说Java的Swing工具包被认为是“内存耗尽”(例如this answer)。

这是......

    由于Swing的架构,
  • A ;

  • Java内存管理中固有的
  • B ;或

  • C 这是一个毫无根据的主张,原因是缺乏对内存分配如何工作的理解(例如,因为任务管理器说应用程序已经分配了x MB,它实际上并不意味着它实际上正在全部使用它)

与类似的GUI工具包(不一定是Java)相比,我试图找到关于Swing真正的内存需求的具体客观分析。

3 个答案:

答案 0 :(得分:4)

我经常在Swing中使用“膨胀”这个词来表示略有不同的东西:

Swing将自己需要的东西捆绑在一起,而不是使用已经提供的东西。

这是什么意思?这意味着您使用/浏览Swing的任何内容都会被Swing绘制并完全处理。相比之下,SWT实际上使用了操作系统的窗口,因此它自然会减少内存使用量并减少自己的工作量。 Swing中的“窗口”并不是真正的“窗口”,它们只是像一样看起来像。相比之下,SWT使用“真实”窗口,并让操作系统进行大量管理。

答案 1 :(得分:2)

请参阅附件测试显示它在很多情况下都是平局:

  1. 结论 很难给出SWT优于Swing的经验法则,反之亦然。 在某些环境(例如Windows)中,SWT是赢家。在其他人(Linux,VMware 托管Windows),Swing及其重绘优化显着优于SWT。 性能差异很大:2和更多的因素是常见的 无论方向。 Swing抑制连续重绘的能力是多么令人怀疑 有效。很可能在实践中这不是经常出现的,如重复的那样 在短时间内更新请求可能并不常见。在这种情况下,结果 Swing文本字段(sync)测试应该被认为具有更高的可信度 那些Swing文本字段测试,因为它们更接近资源使用 密切。 在执行此基准之前的初步预期是发现SWT表现优于大市 摇摆。这种期望源于基于SWT的Java的更高响应性 与基于Swing的应用程序相比,应用程序(例如,Eclipse IDE)。但是,这个 期望无法定量确认。感知有可能 响应性是响应用户所需时间较短的结果 交互,不仅涉及绘图,还涉及检测和响应 用户的动作。此外,确定性(较小的标准偏差)可能导致 更高的感知响应能力。
  2. http://public.cosylab.com/CSS/DOC-SWT_Vs._Swing_Performance_Comparison.pdf

答案 2 :(得分:2)

Swing使用相当多的内存是真的,但我不认为它是“记忆猪”。

正如一篇回复所说,在Swing中,每个组件都是自己绘制的(不使用操作系统原始小部件),这就是使Swing可以在platforn上移植的原因。

从我的观点来看,Look'n'Feel概念非常好,但它当然有一些缺点(内存消耗)。但我发现这个缺点在很大程度上是因为只用一行代码就可以立即改变应用程序的外观和感觉。有一些第三方look'n'feels(一些商业,一些开源),可以给你的应用程序一些“友好”的外观。

此外,内存使用也起源于JDK(至少6个)在内存中加载(或预加载)类的方式:据我所见,第二个你在代码中运行一些Swing API,即使您可能不需要所有小部件,整个Swing库也会完全加载。这可能会在JDK7(我没有测试过)和“Jigsaw”中发生变化。