使用DynamicResource与StaticResource相比，是否会有显著的性能成本？
使用DynamicResource与StaticResource相比，是否会有显著的性能成本？
我们的设计师正在使用 Blend 来设计我们的 WPF 应用程序。当他选择本地资源进行属性设置时，Blend 会将它们应用为{DynamicResource}而不是{StaticResource}。我猜测 Blend 这样做是因为它能够在运行时重新主题化应用程序而不必重新启动它。
我的问题是：这种额外的查询会有明显的性能成本吗？我们应该要求设计师回去手动将那些 Dynamics 更改为 Statics 吗？
这是一个很好的 SO 问题，它解释了这两种类型之间的区别：What\'s the difference between StaticResource and DynamicResource in WPF?
据说有性能差异，但是否“显著”取决于动态查找发生的次数。除非您有数千个DynamicResource引用，否则可能无论哪种方法都不会引起注意；如果动态资源性能比静态资源差得多，我认为Blend将更加谨慎地生成它们。\n\n实际上，当我运行一个简单的测试时，我发现逆向结果是DynamicResource比StaticResource运行得更快(使用3000个资源引用时，我看到使用DynamicResource的所有内容的负载时间约为200ms，而使用StaticResource的负载时间约为400ms)。\n\n由于许多原因，这是一个不切实际的测试：所有引用都指向同一个对象，我正在调试器下运行等等。但这表明，提前将精力投入到改变Blend输出“以防万一”是不明智的，并且如果您确实注意到了减速，这可能不一定是DynamicResource引用的错 - 总是进行测量！
不幸的是，在这种情况下，很难直接比较相对性能，因为任何退化的地方都会在WPF引擎的深处显示出来。在WPF的早期，使用StaticResource是推荐的标准性能调整之一，我们在组织中往往严格遵循它，并推荐它给其他人。我很恼火Blend做了Dynamic的一切，尽管这可以帮助它在设计时正确地渲染其他文件中的资源。
随着时间的推移，这种情况发生了变化，部分原因是个人经验，但也得到了微软Blend团队的反馈。如您所知，Blend完全是用WPF编写的，并且具有完整的备用主题（Light），可以在应用程序运行时随时切换。这是可能的，因为他们为几乎所有的样式使用了DynamicResource。根据他们的说法，这并没有给他们带来任何真正的性能问题。鉴于Blend可能是现有WPF应用程序中使用最广泛的应用程序，我倾向于认可他们的观点。
另一件需要考虑的事情是DynamicResource的实际用处。动态更改样式是其中一部分，但也是在构建您的资源层次结构时为您提供的灵活性，这可以使共享样式的管理变得更加容易。我相信您遇到过这样的情况：静态资源引用在运行时崩溃，因为它所指向的资源载入在层次结构的不同分支中。
显然，StaticResource对于指向您知道将在适当时间可用的特定键非常有用。当手写XAML时，我仍然往往一直使用它。但考虑到让设计师在Blend中生成您的XAML所获得的生产力，您可能得不到任何微小的性能提升，这可能不值得手动维护所有内容的开销。