.net - как связать службу Windows с приложением systray
У меня есть служба Windows, которая делает что-то периодически. под учетной записью пользователя запускается приложение systray (написанное на C#), которое взаимодействует со службой Windows (через.net remoting) и показывает статус и некоторые опции пользователям.
Все работает хорошо, кроме того, что приложение Systray использует 20-30 МБ оперативной памяти! он должен работать в терминальной среде, когда 50 пользователей входят в систему, только приложения systray занимают>1 ГБ ОЗУ! и мне не нужно добавлять, это неправильно:)
Можно ли написать приложение.net systray, которое будет небольшим? (1-2 МБ максимум?) Или я должен написать это на c/ C++? Тогда какой тип связи я должен использовать между службой Windows (написанной на C#) и приложением systray?
8 ответов
Я добавил следующую строку в мой код (приложение вызывает ее иногда вместе с GC.Collect())
System.Diagnostics.Process.GetCurrentProcess().MaxWorkingSet =
System.Diagnostics.Process.GetCurrentProcess().MinWorkingSet;
Использование памяти сократилось до ~2 МБ (с 15-25 МБ), после обнуления некоторых объектов после использования (меню рисования и значок) использование памяти сократилось до ~540 КБ! он немного увеличивается (до ~2-3 МБ, если я использую контекстное меню, но затем он падает до ~540 КБ)
Итак, цель достигнута:)
Другое соображение заключается в том, что много памяти, используемой приложениями.NET, находится в общих (.NET) dll и не будет дублироваться при запуске нескольких экземпляров (если ОС не использует рандомизированные адреса загрузки dll).
Вы также можете уменьшить объем памяти, используемой JIT-компиляцией, установив ваши сборки в GAC и предварительно JITting их, используя ngen, Опять же, это приведет к уменьшению использования памяти, если ОС не рандомизирует адреса загрузки DLL.
Скорее всего, проблемы с использованием памяти, которые вы испытываете, характерны для вашего приложения, а не для всех приложений sys-tray, созданных с помощью.NET.
Вы должны профилировать ваше приложение, чтобы определить, где происходит большое использование памяти.
Если все, что вам нужно, это изменить значки в systray, изменить всплывающую подсказку и показать небольшое контекстное меню, непременно напишите ваше приложение systray на C/C++, используя чистый WinAPI, и используйте именованный канал в режиме сообщений для взаимодействия со службой. Не забудьте использовать Global\ префикс имени канала, чтобы позволить приложениям systray, работающим в нескольких сеансах, подключаться к одной и той же службе.
Ваше приложение sys-tray, вероятно, имеет утечки памяти. Хороший инструмент профилирования поможет вам понять, что происходит.
Мы сталкивались с подобной проблемой в прошлом, и я поделюсь с вами своим решением.
.Net framework Библиотека TCP/IP жалко не работает и пожирает память, как и все остальное.
В качестве решения этой проблемы мы выбрали библиотеку XF от KODART - высокопроизводительную библиотеку TCP/IP с открытым исходным кодом для приложений .Net. Он прекрасно масштабируется на нескольких клиентских подключениях.
Вы можете установить каналы TCP/IP с помощью библиотеки XF и наблюдать за результатами самостоятельно.
Закажите эту статью для получения дополнительной информации.
Итак, если я решу написать приложение systray на c/ C++, какой тип связи я должен использовать между службой Windows (написанной на C#) и приложением systray?
Выпуск WCF (.NET 3.0 или 3.5?) Сделал удаленное взаимодействие.NET устаревшим. С WCF у вас есть возможность разместить сервер WCF в вашей службе Windows, а затем обмениваться данными со своей службой через TCP/IP. По моему опыту, WCF гораздо стабильнее, чем удаленное взаимодействие.NET.
В зависимости от ваших потребностей вы можете рассмотреть возможность использования ServiceControllerвместо удаленного доступа или WCF. С ServiceController вы можете запускать и останавливать службы, а также отправлять команды, определенные приложением (в виде целых чисел), с помощью службы Service.Controller.ExecuteCommand, С помощью ServiceController это намного проще, чем удаленное взаимодействие и WCF, но не так гибко.