Есть ли значительная стоимость для DynamicResource вместо StaticResource?

Наш дизайнер использует Blend для создания нашего приложения WPF. Когда он выбирает локальные ресурсы для свойств, Blend будет применять их как {DynamicResource} вместо {StaticResource}. Я предполагаю, что Blend делает это, потому что он позволяет приложению обновляться во время выполнения без необходимости его перезапуска.

Мой вопрос: есть ли значительная стоимость для этого дополнительного поиска? Должны ли мы попросить дизайнера вернуться и вручную изменить эту динамику на статику?

Вот большой вопрос SO, объясняющий разницу между типами: В чем разница между StaticResource и DynamicResource в WPF?

Ответ 1

К сожалению, это случай, когда очень сложно сделать прямое сравнение относительной производительности с места, где будет проявляться какая-либо деградация, глубоко в двигателе WPF. В начале WPF использование StaticResource было одним из стандартных изменений настройки производительности, которые были рекомендованы, и мы, как правило, придерживались его строго в нашей организации и рекомендовали его другим. Мне было очень досадно, что Blend сделал Dynamic все, хотя это помогло ему правильно отображать ресурсы из других файлов во время разработки.

Со временем мой взгляд на это изменился из-за личного опыта, а также отзывов от людей из команды Blend в Microsoft. Как вы, вероятно, знаете, Blend полностью написан в WPF и имеет полную альтернативную тему (Light), которую можно включить "на лету" во время работы приложения. Это возможно, потому что они использовали DynamicResource для почти всех своих стилей. По их словам, это не вызывало у них никаких реальных проблем. Учитывая, что Blend, вероятно, является наиболее широко используемым приложением WPF, я, как правило, уделяю значительное внимание их представлениям.

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

Очевидно, что StaticResource очень полезен для указания на определенный ключ, который, как вы знаете, будет доступен в нужное время. Когда я пишу XAML, я все равно использую его все время. Но, учитывая производительность, которую вы получаете от того, что дизайнер генерирует ваш XAML в Blend, любое небольшое увеличение производительности, которое вы можете получить, вероятно, не стоит накладных расходов на поддержание рук как Static.

Ответ 2

Говорят, что разница в производительности, но будет ли она "значимой", будет зависеть от того, сколько динамических запросов происходит. Если у вас нет тысяч ссылок DynamicResource, это, вероятно, не будет заметным в любом случае; если динамические ресурсы выполняются гораздо хуже, чем статические, я подозреваю, что Blend будет более консервативным в отношении их генерации.

Фактически, когда я провел наивный тест, я нашел встречный результат, который DynamicResource работал быстрее, чем StaticResource (с 3000 ссылками на ресурсы, я видел время загрузки около 200 мс, когда я использовал DynamicResource для всего около 400 мс для StaticResource).

Это было нереалистичным тестом по многим причинам: все ссылки были на одно и то же, я работал под отладчиком и т.д. и т.д. Но это предполагает, что было бы преждевременно прилагать усилия для изменения вывода Blend "только в case" - и если вы заметите замедление, это может быть не обязательно ошибка ссылок DynamicResource - всегда измерьте!

Ответ 3

К сожалению, если вы измените динамические ресурсы на статику, она сломает Blend. Это, похоже, верно, особенно при использовании UserControls, которые ссылаются на динамические ресурсы, если вы измените их на статические, элемент управления не будет отображаться при размещении внутри другого элемента управления в Blend.