wpf - 解决 WPF 应用程序的性能问题

Question

很难说出这里问的是什么。这个问题是模棱两可的、模糊的、不完整的、过于宽泛的或修辞的，无法以目前的形式得到合理的回答。如需帮助澄清这个问题以便重新打开它，visit the help center .




10年前关闭。




我已经列出了所有可以帮助在具有大量控件的非常复杂的应用程序中提高性能的所有内容。如果你想添加你的，你的欢迎!

如果你知道控件的大小，去掉 Auto 并输入真实值，这样父级就不必解析所有子级来检查他需要的大小

如果元素不需要交互，则设置参数 IsHitTestVisible=False

卡住所有可以卡住的对象

使用静态资源而不是动态资源

不要使用 Ellipse 对象，将 Ellipse 转换为 Path

如果可以使用 TextBlock，请勿使用 TextBox 或 Label

尽可能使用 Canvas 而不是 Grid

无流文档

虚拟化!!虚拟化StackPanel 而不是 StackPanel

不要使用 List，ObservableCollection 更快

使用绘图库，它比形状库更快

检查你的绑定(bind)!如果绑定(bind)不起作用，它可能会非常慢

不要使用 Visibility.Hidden，尽可能使用 Visibility.Collapsed

DependencyProperty 比 INotifyPropertyChanged

快 3 倍

StreamGeometry 比 PathGeometry

更快

完成后清除事件处理程序!

不要使用Object Opacity 属性，如果可以的话，使用他的颜色不透明度

检查您的应用程序是否是硬件渲染(第 2 层)

尽可能减小图像的大小/质量

渲染图像比渲染矢量要快得多!

我使用的工具:

WPF 检查员

窥探

WPFPerf 套件

Visual Studio 分析器

.NET 的 CLR 分析器

Answer 1

这确实是评论而不是答案，但评论空间不足。

由于 ObservableCollection 实现了 iList，ObservableCollection 比 List 快的方式对我来说似乎违反直觉。

我有一个包含 660,000 个单词的列表，我在 ListView(虚拟化)上进行了测试。
在下面创建了集合类型并创建了按钮来切换后面代码中的绑定(bind)。所有集合都即时呈现(虚拟化的力量)。

变量是创建集合的时间和您从集合中需要的功能。使用 SQLdataReader 填充集合。 SQLdataReader 存在可变性。跑每 10 次得到 2 个有效数字的可重复结果，我将平均值报告为 3 个有效数字。 List 比 ObservableCollection 快了大约 400 毫秒。没有测量内存，但 List 显然会使用更少的内存。

加载 660,000 个字符串(平均每个字符串约 40 个字符)所需的毫秒数。

    1510 List
    1780 Dictionary  
    1820 HashSet
    1980 ObservableCollection
    8000 SortedDictionary

在一个非常大的集合中，HashSet 会比 List 更好。 HashSet 应该击败 Dictionary - 这些数字在这个有限的非严格测试的可变性范围内。

它归结为功能。 ObservableCollection 支持动态插入和删除。如果您需要动态插入和删除，那么它是迄今为止最好的选择。如果您不需要动态插入和删除，那么我的经验是 List 是更好的选择(通过 ListItem List 的 iNotifyPropertyChanged 支持动态修订)。

列表保留添加项目的顺序。 HashSet 不保留顺序。选择要使用的集合的许多因素。
http://geekswithblogs.net/BlackRabbitCoder/archive/2011/06/16/c.net-fundamentals-choosing-the-right-collection-class.aspx

对单个项目的访问时间发表了评论。我使用 List、ObservableCollection 和 Dictionary 访问了项目 [1]、[100000]、[200000]、[300000]、[400000]、[500000]、[600000]。它们都是 12 毫秒。访问时间是死气沉沉且可重复的。