Как две программы могут общаться друг с другом на Java?

Question

Я хочу уменьшить загрузку ЦП / ПЗУ / ОЗУ - как правило, все системные ресурсы, используемые моим приложением - а кто нет? :)

По этой причине я хочу отделить окно настроек от остальной части приложения, и пусть окно настроек запускается как самостоятельная программа.

Программа предпочтений должна записать в файл Свойство (это не проблема) и отправить «сигнал обновления» основной программе - это означает, что она должна вызвать метод обновления (что я написал) что нашел в Главном классе.

Как вызвать метод обновления в основной программе из программы настроек?

Другими словами, это способ построения окна настроек, которое потребляет системные ресурсы просто при появлении окна?

Является ли этот подход - разделять программы и позволять им разговаривать друг с другом (каким-то образом) - правильным подходом для ускорения моих программ?

Answer 1

То, что вы описываете, звучит как Преждевременная оптимизация . Если вы пишете что-то кроме игрушечного приложения, важно быть уверенным, что ваши оптимизации действительно решают реальную проблему. Ваша программа работает медленно? Если да, то запускали ли вы его через профилировщик или иным образом определяли, где происходит низкая производительность?

Если вы определили, что то, что вы хотите сделать, решит вашу проблему с производительностью, я предлагаю вам рассмотреть возможность одновременного запуска компонентов в разных потоках, а не в разных процессах. Тогда ваши компоненты смогут избежать блокирования друг друга, вы сможете использовать преимущества многоядерных процессоров, и вы не будете брать на себя сложность и накладные расходы производительности межпроцессного взаимодействия через сетевые сокеты и тому подобное.

Answer 2

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

К сожалению, я не думаю, что это поможет вам минимизировать использование ЦП, ОЗУ и т. Д. Во всяком случае это может увеличить использование ЦП, ОЗУ и т. Д., Потому что вам нужно запустить две JVM вместо одной. Если у вас нет невероятно сложного окна настроек, маловероятно, что вам понадобится столько ресурсов, чтобы беспокоиться об этом. Добавляя сетевое взаимодействие, вы просто увеличиваете сложность, не добавляя никаких преимуществ.

Edit:

Если вы читали книгу «Грязные богатые клиенты», то одним из главных пунктов этой книги является то, что богатые эффекты не должны быть ресурсоемкими. Большая часть книги посвящена тому, как добавить интересные эффекты в приложение, не затрачивая много ресурсов. На протяжении всей книги они очень тщательно подбирают время, чтобы показать, что занимает много времени, а что нет. Это очень важно, когда ваше приложение менее требовательно к ресурсам. Напишите свое приложение, посмотрите, что ощущается медленно, добавьте временный код к тем медленным элементам и ускорите эти конкретные части кода. Проверьте с вашим временным кодом, чтобы увидеть, если это на самом деле быстрее. Промыть и повторить. В противном случае вы делаете оптимизацию, которая может не иметь никакого значения. Без учета времени вашего кода вы не знаете, нужно ли ускорять код, даже если вы ускорили код после выполнения оптимизации.

Другие упоминали о загрузке окна свойств в отдельном потоке. Важно помнить, что в Swing есть только один поток, называемый EDT , который выполняет всю картину пикселей на экране. Любой код, который вызывает изменение пикселей на экране, должен вызываться из EDT и, следовательно, не должен вызываться из отдельного потока. Итак, если у вас есть что-то, что может занять некоторое время (например, вызов веб-службы или некоторые дорогостоящие вычисления), вы запустите отдельный поток вне EDT, и когда он завершит выполнение кода в EDT, чтобы выполнить обновление UI , Есть библиотеки, такие как SwingWorker , чтобы сделать это проще. Если вы устанавливаете диалоговое окно, чтобы оно было видимым, это не должно быть в отдельном потоке, но может иметь смысл построить структуры данных в отдельном потоке, если создание этих структур занимает много времени.

Использование Swing Worker - одна из многих ценных идей в Filthy Rich Clients для того, чтобы пользовательский интерфейс чувствовал себя более отзывчивым. Используя идеи из этой книги, я взял довольно ресурсоемкие пользовательские интерфейсы и сделал их такими, чтобы пользовательский интерфейс почти не использовал никаких ресурсов.

Answer 3

Может быть, вы могли бы использовать какой-то наблюдатель каталога, например this , или, возможно, реализовать какой-то семафор. Честно говоря, я думаю, что вы сможете решить проблему, если у вас есть какой-то пункт меню, к которому пользователь может получить доступ. Как только пользователь сохраняет настройки, они записываются в файл. Затем приложение загружает значения из файла всякий раз, когда они им нужны. Если ваша система работает медленно или зависает, вы можете рассмотреть возможность использования потоков или увеличить количество потоков.

Answer 4

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

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

Answer 5

Никто, кажется, не упомянул DBUS - доступный для разработчиков в системе Linux. Я думаю, что это не очень хорошо, если вы пытаетесь создать приложение для Windows / кроссплатформенности, но DBUS - это готовая коммуникационная платформа для приложений. Это помогает решать такие проблемы, как:

• Кто-то, возможно, уже использует порт, который вы пытаетесь. У вашего клиентского приложения нет способа (я полагаю, что это окно «Preferences»), чтобы узнать, является ли прослушивание этого порта вашим основным приложением, или просто что-то еще, что происходит там, так что вам придется сделать что-то вроде рукопожатие и реализовать механизм разрешения конфликтов
• Ни для вас, ни для тех, кто придет поддержать ваше приложение, не будет очевидно, почему вы находитесь на порте, в котором находитесь. Это может показаться не важным, но общение на Socket 5574 не кажется мне таким же интересным, как общение на канале org.yourorganisation.someapp.
• Межсетевые экраны (как я думаю, кто-то уже сказал) могут быть немного чрезмерно усердными

Кроме того, стоит приложить руку к DBUS - это полезно для связи с целым рядом других приложений, таких как маленькие всплывающие уведомления, которые вы найдете в последних дистрибутивах Ubuntu, или с некоторыми клиентами мгновенных сообщений и т. Д. 1011 *

---

Вы можете прочитать о том, о чем я говорю (и, возможно, поправить меня в отношении некоторых вещей, которые я сказал) здесь: http://www.freedesktop.org/wiki/Software/dbus. Похоже, что они работают над тем, чтобы это произошло и в Windows, что приятно.

Answer 6

На самом деле, как объяснили другие, вы можете использовать сокет для межпроцессного взаимодействия. Тем не менее, это не уменьшит ваше общее использование CPU / RAM. (может даже немного ухудшить использование ваших ресурсов)

В вашем случае вы можете запустить окно Perference в другом потоке, а не в другом процессе. Поток легче для обработки ОС и не представляет дополнительной сложности для межпроцессного взаимодействия.