2014-11-19 4 views
0

У меня есть сложное приложение WPF, которое использует много ресурсов из общего ресурсного словаря ресурсов. Первое инициализированное окно занимает 8 секунд для инициализации. Проблема с производительностью меньше на дисках SSD, но для этого требуется 2 секунды.Проблема с производительностью при запуске приложения WPF

Я попытался использовать Visual Studio Profiler, и он показывает большие затраты времени на InitializeComponent(); окон, которые необходимо отобразить.

Я считаю, что это связано с используемым словарем ресурсов, но я не могу его заменить, потому что мне это действительно нужно, потому что все элементы Windows и WPF используют ссылки StaticResource.

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

Итак, подведем итоги. Начиная с момента, когда ShowDialog вызывается до тех пор, пока окно не отобразится, оно занимает 8 секунд. Это видно только в первом окне. Любое другое окно, открытое после этого, будет отображаться быстро.

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

Я не упомянул, но во время запуска нет исключений или данных. Это значит, что не относится к Исключениям.

Я считаю, что это что-то с инициализацией кнопок и других компонентов, потому что почти у всех из них есть Restrled ControlTemplate.

ответ

2

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

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

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

Если вы считаете, что ваши ресурсы Xaml являются проблемой, разделите их, и каждый взгляд будет тянуть только те ресурсы, которые ему нужны. Не сливайте их в App.xaml. Вы также можете посмотреть, как share the resources more efficiently на несколько видов.

Throwing up a splash screen может улучшить воспринимается время запуска. Получив что-нибудь на экране, чтобы пользователь знал, что ваше приложение действительно делает что-то, проходит долгий путь.

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

+0

К сожалению, это мне не помогает. Мне не разрешено использовать заставку. На первом экране отсутствует тяжелый код или данные, используемые при загрузке. Есть только 2 кнопки и один фон LinearGradientBrush. Даже профайлер не знает, как измерить, что происходит после InitializeComponent(); Это должно быть что-то связанное с XAML и ресурсами. Необходимо найти дополнительную информацию о том, как инициализируются словари ресурса. – Patrik

+0

«Это должно быть что-то связанное с XAML и ресурсами». => Почему вы так думаете? –

+0

Потому что я измерил время, затраченное на инициализацию. По сравнению с загрузкой другого кода это большая разница. Это составляет 87% времени для ресурсов и 4.7 для кода позади + оставшихся нескольких процентов для некоторых DLL ... – Patrik

0

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

Смежные вопросы