问:WPF -在多大程度上应该避免资源字典?



我多次听说资源字典可以缓慢但肯定地建立并成为应用程序性能的拖累(特别是当合并字典开始引用其他合并字典时,所有这些都聚集在一起形成一个意想不到的资源矩阵)。

考虑到这一点,是否应该将样式吸收到c#中作为自定义控件,智能地尝试执行样式将设置给定控件的属性,由内部定义的Enum="Example"而不是style ="{StaticResource Example}"来设置?如果是这样,在ResourceDictionary的"严重性"(因为没有更好的词)的哪个点/级别上应该这样做?

另外,如果c#在运行时效率更高,那么XAML应该比c#得到多少关注呢?XAML是否应该被简单地用作放置由c#最终定义、样式、给定属性和控制的极简标签的区域?

以我的观点和经验,我会说资源是WPF引擎提供的一个非常好的工具。现在,问题是性能问题,为了回答这个问题,我想指出两个巨大的工具Visual Studio和Blend都是在WPF中构建的,UI元素大量使用动态资源。但是,该工具没有性能问题。所以,要正确回答你的问题,你应该在正确的地方使用正确的技术。当您希望修改主题或视觉外观等内容时,资源为您提供了很大的灵活性。尽管就您的观点而言,您需要非常小心地使用它,并尽量控制资源。在你的页面中只包含必要的资源。

所以,结论:1. 不,不要把一切都转化为控制,不要使用任何资源。2. 是的,您需要在资源方面做出深思熟虑的努力,以保持应用程序性能优化。

如果你指的是由于通过传递依赖关系反复添加相同资源而导致的内存膨胀,请查看web上浮动的SharedResourceDictionary的各种实现。这可以减少工作集和减少启动时间(以我的经验),但你应该注意避免内存泄漏,因为大多数只是存储一个从URI字符串到ResourceDictionary的静态映射。

如果你想问资源字典是否有用,那么是的,它们非常有用,甚至对于许多常见的XAML模式(如StaticResource)来说是必不可少的。

最新更新