Насколько интенсивно использующий ресурсы Слушатели в Java?

Использование ЦП: практически отсутствует. Слушатели вызываются только при изменении состояния объекта, который они слушают. Они на самом деле не «слушают». Объект, который они слушают, вызывает их, когда это необходимо. (Примечание: это упрощение)

Использование памяти: в основном ActionListener не имеет состояния. Таким образом, общее длительное использование памяти - это минимум, необходимый для любого объекта. В вашем примере - это состояние , так как у вас есть поле setColor. Но использование памяти невелико.

IMO, слушатели эффективны, и вы можете использовать их сколько угодно.

Слушатели очень дешевы по сравнению с Компонентами, к которым они прикреплены. Даже наличие сотен слушателей вряд ли сильно повлияет на процессор или память. Однако важнее общая работа, которую выполняют слушатели. Если вы видите проблему с производительностью, вы можете использовать профилировщик ЦП / памяти для определения и оптимизации причины. Это не то, о чем вам стоит беспокоиться заранее.

Имейте в виду, что прослушивание - это не то же самое, что ожидание занятости. Слушатель регистрируется в списке заинтересованных сторон через какие-то прокси-методы. В большинстве шаблонов прослушивателя расходуется очень мало времени ЦП.

В Java ME существует традиция использовать меньшее количество классов, так как накладные расходы на загрузку другого файла класса значительны, поэтому иногда вы получаете код Java, который пытается уменьшить количество типов слушателей и использовать условная логика в слушателе. Для настольных приложений размер Java на самом деле не является проблемой, но иногда вы видите, как он просачивается в это пространство.

Не совсем ответ на вопрос, но как только вы зайдете так далеко, вы обнаружите, что можете уменьшить область видимости большинства полей MenuTest до переменных метода в конструкторе.

Я обычно использую анонимных слушателей, поскольку в большинстве случаев они слишком просты, чтобы их можно было назвать.

В показанном коде используются прослушиватели действий, чтобы определять, активированы ли пункты меню.

В конструкторе устанавливает выбранный пункт меню, затем в основном методе он обращается к полю colorValues ​​ объекта и устанавливает значение фона. Очевидно, это не работает как при скрытии информации, так и при инкапсуляции.

Если вместо этого вы используете ChangeListener s, чтобы проверить, установлен ли пункт меню как выбранный, тогда у вас не будет двух отдельных частей логики чтобы поддерживать то же состояние, что и цвет, установленный в ответ на вызов setSelected , и вам не нужно передавать вызывающей стороне поле colorValues ​​.

for ( int count = 0; count < colors.length; count++ ){
    colorItems[count] = new JRadioButtonMenuItem(colors[count]);
    colorMenu.add(colorItems[count]);
    colorButtonGroup.add(colorItems[count]);

    final Color color = colorValues[count];

    colorItems[count].addChangeListener ( new ChangeListener() {
        public void stateChanged ( ChangeEvent event ){
            if ( ( ( AbstractButton ) event.getSource() ).isSelected () ) 
                getContentPane().setBackground ( color );
        }
    });
}

colorItems[0].setSelected(true);

// no call to setBackgroundColour() in main() 

У вас также может быть вторая конечная переменная для хранения colorItem и предотвращения преобразования в event.getSource () .

Также можно было бы реализовать изменение слушатель также прослушивает изменения, устанавливающие цвет фона в кадре, и выберите соответствующий пункт меню, если цвет изменен с помощью setBackground ().

Вызов setBackground () автоматически помечает панель как поврежденную, поэтому впоследствии не нужно вызывать перерисовку.

Что ж, рассмотрим самую простую реализацию слушателя: все, что вы делаете, в основном добавляете объект в список слушателей, не более того. Зарегистрируйте функцию обратного вызова, если хотите. Таким образом, реализация этой строки:

someObject.addListener(new someAnonymousListener{ ... });

по существу будет выглядеть так:

someListenerList.add(new someAnonymousListener{ ... });

До сих пор нет вреда, нет фола. Объект просто находится в списке со всеми другими зарегистрированными слушателями.

Однако обратите внимание, что происходит, когда на объекте запускается событие:

for (SomeListener l : someListenerList) {
    l.doSomeAction();
}

Yikes . Здесь следует быть осторожным. Убедитесь, что ваш слушатель не делает ничего слишком сложного, иначе вы увидите узкое место, которое проявится во время профилирования.

Итог: просто удерживать слушателя на объекте почти бесплатно. Просто убедитесь, что вы не регистрируете слишком много слушателей, и что каждый из них сохраняет это »

Гораздо более серьезной проблемой здесь является время настройки и, в меньшей степени, постоянная память для генерации.

Для фактических размеров объектов вы можете выполнить анализ воздействия на оболочку. Около 20 байт на объект. Допустим, у вас их 10 000, это 200 000. На машине размером 1 Гбайт это 0,02% памяти вашей машины, используемой для слушателей - я бы не стал беспокоиться об этом в сотовом телефоне.

Более широкая картина - это то, сколько классов вы загружаете. Мой эксперимент (где-то в Usenet) дал около 2 КБ накладных расходов на каждый загруженный относительно небольшой анонимный внутренний класс. 10 000 из них - 20 МБ. 2% от нашей машины 1 ГБ. Я бы беспокоился об этом для широко распространенного программного обеспечения, но не для пары десятков машин в компании или отделе среднего размера. Тем не менее, это ' Намного важнее получить программное обеспечение, которое действительно работает и может быть сопровождено (очевидно, 85% затрат на разработку программного обеспечения приходится на обслуживание (для некоторого определения), и большинство проектов никогда не доходят до этого).

Загрузка кода является относительно дорогой операция. Хотя, к счастью, теперь у нас есть jar-файлы, а не открытие нового сокета для выполнения запроса HTTP 1.0 для каждого файла класса (апплеты запускались медленно - как это произошло?). Тем не менее, строки нужно искать, определять методы, проверять байт-код и т. Д. И это все еще интерпретируется в течение 1500 итераций, прежде чем мы понесем расходы на компилятор.

После того, как вы заработали (он не работает, пока не будет запущен в производство) , поддерживаемое программное обеспечение, то вы можете рассмотреть возможность точной настройки производительности (хотя, чтобы не противоречить, лучше иметь хедз-ап). Настройте самую медленную часть. С процессорами с тактовой частотой ГГц реагирование на каждый щелчок мыши, как правило, происходит более чем достаточно быстро. Медленными обычно являются такие операции, как открытие нового диалогового окна.

Итак, для нас мы хотим сократить время настройки, но мы можем быть весьма неэффективными во время возникновения события. 50 мс - это время отклика, к которому мы должны стремиться, и это на машине с частотой 1 ГГц, это 20 000 000 циклов (много!). Таким образом, наиболее эффективная стратегия - использовать несколько типов слушателей. Используйте один тип слушателя (возможно, экземпляр), чтобы слушать изрядное количество модели. Игнорируйте аргументы события (обычно это хорошая идея для слушателя изменения состояния) и выполните проверку, что нужно сделать (помните, у нас много времени).

Я чувствую необходимость повторить себя здесь. Сделайте свой код красивым. Используйте множество слушателей ввода (и команд).

Я программист Swing уже 5 лет. По моему опыту, никогда не было проблемой, как там могут быть слушатели. Важно отменить регистрацию слушателей, когда они больше не интересуются событиями.

просто помните, что в приложениях с графическим интерфейсом пользователя время отклика более важно, чем память. Возможно, вам будут интересны мои статьи:

Используйте слабые слушатели, чтобы избежать утечек памяти
Знайте, когда ваш объект собирает мусор
Долговечные модели могут вызывать утечки памяти