【问题标题】:Q: WPF - To what extent should Resource Dictionaries be avoided? [closed]问:WPF - 应在多大程度上避免使用资源字典? [关闭]
【发布时间】:2015-12-19 20:06:19
【问题描述】:
我听说过几次资源字典可以缓慢但肯定地建立并成为应用程序性能的拖累(尤其是当合并字典开始引用其他合并字典并且它们全部聚集成一个意外的资源矩阵时)。
考虑到这一点,样式是否应该被同化到 c# 中作为自定义控件,智能地尝试执行样式将给定控件的属性设置为的内容,由内部定义的 Enum="Example " 而不是 Style="{StaticResource Example}"?
如果是这样,应该在什么点/级别的 ResourceDictionary '严重性'(因为没有更好的词) 应该这样做?
此外,如果事实证明 C# 在运行时更高效,那么 XAML 甚至应该比 C# 给予多少关注?
XAML 是否应该简单地用作放置最终定义、样式、给定属性和由 C# 控制的简约标签的区域?
【问题讨论】:
标签:
c#
wpf
xaml
dictionary
【解决方案1】:
以我的观点和经验,我会说资源是 WPF 引擎提供的一个非常好的工具。现在,问题是性能问题,要回答这个问题,我会指出两个巨大的工具 Visual Studio 和 Blend 都内置在 WPF 中,并且 UI 元素大量使用动态资源。但是,该工具没有性能问题。因此,要正确回答您的问题,您应该在正确的地方使用正确的技术。当您想要修改主题或视觉外观等内容时,资源为您提供了极大的灵活性。尽管就您而言,您需要非常小心使用并尝试控制资源。在您的页面中仅包含必需的资源。
所以,结论:
1. 不,不要把一切都变成控制,根本不使用资源。
2. 是的,您需要在资源方面做出深思熟虑的努力以保持应用程序性能优化。
【解决方案2】:
如果您指的是由于通过传递依赖项重复添加相同资源而导致的内存膨胀,请查看网络上漂浮的SharedResourceDictionary 的各种实现。这可以减少工作集并减少启动时间(根据我的经验),但您应该注意避免内存泄漏,因为大多数只是将静态映射从 URI 字符串存储到 ResourceDictionary。
如果您要提出一个关于资源字典是否有用的更笼统的问题,那么是的,它们非常有用,甚至对于多种常见的 XAML 模式(例如StaticResource)来说都是必不可少的。