Существует ли значительная стоимость производительности для DynamicResource вместо StaticResource?
Наш разработчик использует Смешение для моделирования нашего приложения WPF. Когда он выберет локальные ресурсы для свойств, Смешение применит их как a {DynamicResource} вместо a {StaticResource}. Мое предположение - то, что Смешение делает это, потому что оно позволяет приложению быть перетематическим во времени выполнения, не имея необходимость перезапускать его.
Мой вопрос: существует ли значительная стоимость производительности для этого дополнительного поиска? Мы должны попросить, чтобы разработчик возвратился и вручную изменил те Движущие силы на Статику?
Вот великое ТАК вопрос, который объясняет различие между типами: каково различие между StaticResource и DynamicResource в WPF?
3 ответа
К сожалению, это тот случай, когда очень сложно провести прямое сравнение относительной производительности, поскольку место, где может проявиться любое ухудшение, находится глубоко в механизме WPF. На заре WPF использование StaticResource было одним из рекомендуемых стандартных изменений в настройке производительности, и мы, как правило, довольно строго следовали ему в нашей организации и рекомендовали его другим. Меня действительно раздражало, что Blend все делал динамически, хотя это помогало ему правильно отображать ресурсы из других файлов во время разработки.
Со временем мое мнение об этом изменилось, что в некоторой степени связано с личным опытом, а также с отзывами людей из команды Blend в Microsoft. Как вы, вероятно, знаете, Blend полностью написан на WPF и имеет полную альтернативную тему (Light), которую можно переключать на лету во время работы приложения. Это возможно, потому что они использовали DynamicResource практически для всех своих стилей. По их словам, это не вызвало у них серьезных проблем с производительностью. Учитывая, что Blend, вероятно, является наиболее широко используемым из существующих приложений WPF, я склонен придавать значительный вес их представлениям.
Еще одна вещь, которую следует учитывать, - это фактическая полезность DynamicResource. Возможность изменять стиль на лету - одна из ее частей, но также гибкость, которую она дает вам при построении иерархии ресурсов, может значительно упростить управление общими стилями. Я уверен, что вы столкнулись с ситуацией, когда ссылка StaticResource взорвалась во время выполнения, потому что ресурс, на который она указывал, должен был быть загружен в другую ветвь иерархии.
Очевидно, что StaticResource очень полезен для указания на конкретный ключ, который, как вы знаете, будет доступен в нужное время. Когда я пишу XAML от руки, я все время использую его постоянно. Но, учитывая продуктивность, которую вы получаете от того, что дизайнер генерирует ваш XAML в Blend, любой небольшой прирост производительности, который вы можете получить, вероятно, не стоит накладных расходов на ручное поддержание всего как статического.
К сожалению, если вы измените динамические ресурсы обратно на статические, это нарушит Blend. Это кажется правдой, особенно при использовании UserControls, которые ссылаются на динамические ресурсы, если вы измените их на статические, элемент управления не будет отображаться при размещении внутри другого элемента управления в Blend.
Говорят, что разница в производительности есть, но будет ли она «значительной», будет зависеть от того, сколько динамических поисков происходит. Если у вас нет тысяч ссылок на DynamicResource, это, вероятно, в любом случае не будет заметно; Если бы динамические ресурсы работали намного хуже, чем статические, я подозреваю, что Blend будет более консервативным в их создании.
На самом деле, когда я провел наивный тест, я обнаружил противоречивый результат, что DynamicResource работает быстрее , чем StaticResource (с 3000 ссылок на ресурсы, время загрузки составляет около 200 мс, когда я использовал DynamicResource для всего, а не StaticResource). около 400 мс для StaticResource).
Это был нереалистичный тест по многим причинам: все ссылки были на одно и то же, я работал под отладчиком и т.д. case "- и что если вы заметите замедление, это не обязательно может быть ошибкой ссылок DynamicResource - всегда измеряйте!