Является ли Java Swing действительно "боровом памяти"?

Question

Я часто слышу, что Java-инструментарий Swing считается "боровом памяти" (например, этот ответ ).

Это ...

• A из-за архитектуры Swing;

• B присущ Java-управлению памятью; или

• C необоснованное утверждение, вытекающее из непонимания того, как работает распределение памяти (например, только потому, что диспетчер задач говорит, что приложение выделило х МБ, это на самом деле не означает, что оно фактически используя все это)

Я пытаюсь найти конкретный, объективный анализ истинных требований Swing к памяти по сравнению с аналогичными инструментами GUI (не обязательно Java).

Answer 1

Я часто использую слово «раздутый» для Swing, чтобы обозначить что-то немного другое:

Swing объединяет в себе все, что ему нужно, вместо того, чтобы использовать то, что уже предоставлено.

Что это значит? Это означает, что все, что вы используете / видите в Swing, нарисовано и полностью обработано Swing. В отличие от этого, SWT на самом деле использует окна операционной системы, поэтому, естественно, он использует меньше памяти и выполняет меньше работы самостоятельно. «Окна» в Swing на самом деле не являются «окнами», они просто сделаны, чтобы выглядели как окна. В отличие от этого, SWT использует «настоящие» окна и позволяет ОС много управлять ими.

Answer 2

Swing использует довольно много памяти, это правда, но я бы не назвал ее «похитителем памяти».

Как говорится в одном ответе, в Swing каждый компонент окрашивается сам по себе (без использования оригинальных виджетов ОС), что делает Swing переносимым через платформу.

Концепция Look'n'Feel, с моей точки зрения, очень хороша, но, конечно, имеет некоторые недостатки (потребление памяти).Но я считаю, что этот недостаток в значительной степени компенсируется возможностью мгновенно изменить внешний вид приложения с помощью всего одной строки кода.Существует ряд сторонних look'n'feels (некоторые коммерческие, некоторые с открытым исходным кодом), которые могут придать вашему приложению «дружественный» вид.

Кроме того, использование памяти также происходит из-за того, чтоJDK (по крайней мере, до 6) загружает (или предварительно загружает) классы в память: насколько я могу видеть, во второй раз, когда вы запускаете некоторый Swing API в своем коде, вся библиотека Swing загружается полностью, даже если вы не можетенадо все виджеты.Это может измениться в JDK7 (который я не тестировал) и в Jigsaw.

Answer 3

См. Прикрепленный тест, показывающий, что во многих случаях это ничья:

1. Заключение Трудно дать практическое правило, в котором SWT будет превосходить Swing, или наоборот.В некоторых средах (например, Windows) SWT является победителем.В других (Linux, VMware хостинг Windows) Swing и его оптимизация перерисовки значительно превосходят SWT.Различия в производительности значительны: факторы 2 и более являются общими, в любом направлении.Сомнительно, как часто способность Swing подавлять последовательные перерисовки эффективна.Весьма вероятно, что на практике это происходит не часто, поскольку повторные запросы на обновление за короткий промежуток времени могут быть редкостью.В этом случае результаты теста Swing Text Field (sync) следует рассматривать с большей достоверностью, чем результаты теста Swing Text Field, поскольку они более близко аппроксимируют использование ресурсов.Первоначальное ожидание до выполнения этого теста состояло в том, чтобы найти SWT, превосходящий Swing.Это ожидание проистекает из большей отзывчивости Java-приложений на базе SWT (например, Eclipse IDE) по сравнению с Swing-приложениями.Однако это ожидание не могло быть количественно подтверждено.Возможно, что воспринимаемая отзывчивость является следствием меньшего времени, необходимого для реагирования на взаимодействие с пользователем, которое включает в себя не только рисование, но также обнаружение и реагирование на действия пользователя.Кроме того, детерминизм (меньшее стандартное отклонение) может привести к большей восприимчивости.

http://public.cosylab.com/CSS/DOC-SWT_Vs._Swing_Performance_Comparison.pdf