使用 DynamicResource 代替 StaticResource 是否会产生显着的性能成本？

Question

我们的设计师正在使用 Blend 来设计我们的 WPF 应用程序。当他为属性选择本地资源时，Blend 会将它们应用为 {DynamicResource} 代替 {StaticResource}. 。我的猜测是 Blend 这样做是因为它使应用程序能够在运行时重新主题化，而无需重新启动它。

我的问题是：此额外查找是否会产生显着的性能成本？我们是否应该要求设计师返回并手动将这些动态更改为静态？

这是一个很好的问题，解释了类型之间的区别： WPF 中的 StaticResource 和 DynamicResource 有什么区别？

Answer 1

不幸的是，在这种情况下，很难对相对性能进行直接比较，因为出现任何性能下降的地方都在 WPF 引擎的深处。在 WPF 的早期，使用 StaticResource 是建议的标准性能调整更改之一，我们倾向于在我们的组织中非常严格地遵循它，并将其推荐给其他人。我真的很恼火，因为 Blend 所做的一切都是动态的，尽管这有助于它在设计时正确渲染其他文件中的资源。

随着时间的推移，我对此的看法发生了变化，这在一定程度上是由于个人经验的原因，同时也是由于 Microsoft Blend 团队人员的反馈。您可能知道，Blend 完全用 WPF 编写，并具有完整的备用主题 (Light)，可以在应用程序运行时即时切换。这是可能的，因为他们几乎所有的样式都使用 DynamicResource。据他们称，这并没有真正给他们带来任何真正的性能问题。鉴于 Blend 可能是现有使用最广泛的 WPF 应用程序，我倾向于非常重视他们的观点。

另一件需要考虑的事情是 DynamicResource 的实际用途。动态更改样式的能力是其中之一，而且它在构建资源层次结构时提供的灵活性可以使管理共享样式变得更加容易。我确信您遇到过 StaticResource 引用在运行时爆炸的情况，因为它指向的资源要加载到层次结构的不同分支中。

显然，StaticResource 对于指向您知道将在正确时间可用的特定键非常有用。当手写 XAML 时，我仍然倾向于一直使用它。但是，考虑到让设计人员在 Blend 中生成 XAML 所获得的生产力，您可能获得的任何微小的性能提升可能都不值得手动将所有内容维护为静态的开销。

Answer 2

据说存在性能差异，但是否“显着”将取决于发生多少动态查找。除非您有数千个 DynamicResource 引用，否则无论哪种方式都可能不会引人注目；如果动态资源的性能比静态资源差很多，我怀疑 Blend 在生成它们时会更加保守。

事实上，当我运行一个简单的测试时，我发现 DynamicResource 运行的结果违反直觉 快点 比 StaticResource （有 3000 个资源引用，当我对所有内容使用 DynamicResource 时，我看到加载时间约为 200 毫秒）对于静态资源大约 400 毫秒）。

由于多种原因，这是一个不切实际的测试：所有引用都是同一件事，我在调试器下运行，等等。ETC。但它表明，“以防万一”地努力改变 Blend 输出还为时过早 - 如果您确实注意到速度减慢，它可能不一定是 DynamicResource 引用的错误 - 始终进行测量！

Answer 3

不幸的是，如果您将动态资源更改回静态资源，则会破坏 Blend。这似乎是正确的，尤其是在使用引用动态资源的 UserControls 时，如果将它们更改为静态，则当托管在 Blend 中的另一个控件内时，该控件将不会呈现。