DynamicResource而不是StaticResource是否需要大量的性能成本? [英] Is there a significant performance cost to DynamicResource instead of StaticResource?
问题描述
我们的设计师正在使用Blend来设计WPF应用程序的样式.当他为属性选择本地资源时，Blend会将它们作为{DynamicResource}而不是{StaticResource}应用.我的猜测是Blend这样做是因为它使应用程序可以在运行时重新设定主题，而不必重新启动它.
Our designer is using Blend to style our WPF application. When he chooses local resources for properties, Blend will apply them as a {DynamicResource} instead of a {StaticResource}. My guess is that Blend does this because it enables the app to be re-themed at runtime without having to restart it.
我的问题是:这种额外的查询是否需要大量的性能成本?我们是否应该要求设计者返回并手动将那些动力学"更改为静态"?
My question is: is there a significant performance cost to this additional lookup? Should we ask the designer to go back and manually change those Dynamics to Statics?
Here is a great SO question that explains the difference between the types: What's the difference between StaticResource and DynamicResource in WPF?
推荐答案
不幸的是，在这种情况下，很难直接比较相对性能，因为WPF引擎中显示退化的地方很深.在WPF的早期，使用StaticResource是建议的标准性能调整更改之一，我们倾向于在组织中严格遵循它，并将其推荐给其他人.我真的很烦，Blend所做的一切都是动态的，尽管它可以帮助它在设计时正确地渲染其他文件中的资源.
Unfortunately this is a case where it's very hard to do a direct comparison of the relative performance since the place where any degradation would show up is deep in the WPF engine. In the early days of WPF the use of StaticResource was one of the standard performance tuning changes that was recommended and we tended to follow it pretty strictly in our organization and recommend it to others. I was really annoyed that Blend did Dynamic everything even though that helped it to render resources from other files properly at design time.
随着时间的流逝，我的观点已经改变，这在某种程度上是由于个人经验，也来自Microsoft Blend团队的人员的反馈.您可能已经知道，Blend是完全用WPF编写的，并且具有完整的替代主题(Light)，可以在应用程序运行时即时对其进行切换.这是可能的，因为他们几乎所有样式都使用了DynamicResource.根据他们的说法，这实际上并没有引起他们任何实际的性能问题.鉴于Blend可能是现有的使用最广泛的WPF应用程序，因此我倾向于对他们的观点给予极大的重视.
Over time my view on this has changed, due somewhat to personal experience, but also feedback from people on the Blend team at Microsoft. As you are probably aware, Blend is written completely in WPF and has a complete alternate theme (Light) that can be switched on the fly while the application is running. This is possible because they used DynamicResource for pretty much all of their styling. According to them, this didn't really cause them any real perf issues. Given that Blend is probably the most widely used WPF application in existence, I tend to give significant weight to their views.
要考虑的另一件事是DynamicResource的实际用途.即时更改样式的能力是其中的一部分，但是它为您构建资源层次结构提供的灵活性也使管理共享样式变得更加容易.我敢肯定，您会遇到一种情况，因为在此期间，StaticResource引用会在运行时崩溃，因为它指向的资源将被加载到层次结构的另一个分支中.
The other thing to consider is DynamicResource's actual usefulness. The ability to change styling on the fly is one part of it, but also the flexibility it gives you in building your Resource hierarchy can make it a lot easier to manage shared styles. I'm sure you've run into a situation where a StaticResource reference blew up at runtime because the resource it pointed to was to be loaded in a different branch of the hierarchy.
显然，StaticResource对于指向您知道将在正确的时间可用的特定密钥非常有用.手写XAML时，我仍然倾向于一直使用它.但是，鉴于您从设计人员在Blend中生成XAML所获得的工作效率，您可能会获得的任何微小的性能提高都不值得将所有内容手动维护为静态的开销.
Obviously StaticResource is very useful for pointing to a specific key that you know is going to be available at the right time. When hand-writing XAML I still tend to use it all the time. But given the productivity you gain out of having a designer generate your XAML in Blend, any small performance gain you might get is probably not worth the overhead of hand-maintaining everything as Static.
这篇关于DynamicResource而不是StaticResource是否需要大量的性能成本?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
