我们的设计师正在使用 Blend 来设计我们的 WPF 应用程序。当他为属性选择本地资源时，Blend 会将它们应用为 a{DynamicResource}而不是 a {StaticResource}。我的猜测是 Blend 这样做是因为它使应用程序能够在运行时重新设置主题，而无需重新启动它。
我的问题是：这种额外的查找是否有显着的性能成本？我们是否应该要求设计师返回并手动将那些 Dynamics 更改为 Statics？
这是一个很好的 SO 问题，解释了类型之间的区别：WPF 中的 StaticResource 和 DynamicResource 有什么区别？
不幸的是，在这种情况下，很难直接比较相对性能，因为任何降级都会出现在 WPF 引擎的深处。在 WPF 的早期，StaticResource 的使用是推荐的标准性能调整更改之一，我们倾向于在我们的组织中非常严格地遵循它并将其推荐给其他人。我真的很生气 Blend 做 Dynamic 一切，即使这有助于它在设计时正确地渲染来自其他文件的资源。
随着时间的推移，我对此的看法发生了变化，这在一定程度上是由于个人经验以及来自 Microsoft Blend 团队人员的反馈。您可能知道，Blend 完全是用 WPF 编写的，并且有一个完整的替代主题（Light），可以在应用程序运行时动态切换。这是可能的，因为他们几乎所有的样式都使用了 DynamicResource。据他们说，这并没有真正给他们带来任何真正的性能问题。鉴于 Blend 可能是现存最广泛使用的 WPF 应用程序，我倾向于对他们的观点给予很大的重视。
要考虑的另一件事是 DynamicResource 的实际用途。动态更改样式的能力是其中的一部分，但它在构建资源层次结构时为您提供的灵活性可以使管理共享样式变得更加容易。我确定您遇到过这样一种情况：StaticResource 引用在运行时爆炸，因为它指向的资源将被加载到层次结构的不同分支中。
显然，StaticResource 对于指向您知道将在正确时间可用的特定键非常有用。在手写 XAML 时，我仍然倾向于一直使用它。但是考虑到让设计人员在 Blend 中生成 XAML 所获得的生产力，您可能获得的任何微小的性能提升都可能不值得将所有内容手动维护为静态的开销。
据说存在性能差异，但它是否“显着”取决于发生了多少动态查找。除非您有数千个 DynamicResource 引用，否则它可能不会引起注意；如果动态资源的性能比静态资源差得多，我怀疑 Blend 在生成它们时会更加保守。
事实上，当我进行一个简单的测试时，我发现了一个违反直觉的结果，即 DynamicResource 的运行速度比 StaticResource 快（在 3000 个资源引用中，我看到所有内容都使用 DynamicResource 时的加载时间约为 200 毫秒，而 StaticResource 的加载时间约为 400 毫秒）。
这是一个不切实际的测试，原因有很多：所有引用都指向同一个东西，我在调试器下运行等等。但这表明现在“以防万一”来改变 Blend 输出还为时过早 - - 如果您确实注意到速度变慢，则不一定是 DynamicResource 引用的错误 - 始终测量！
不幸的是，如果您将动态资源改回静态资源，它将破坏 Blend。这似乎是正确的，尤其是在使用引用动态资源的 UserControl 时，如果将它们更改为静态，则当托管在 Blend 中的另一个控件中时，控件将不会呈现。