使用数据绑定WPF ComboBox诊断性能问题

Question

我今天早上一直在和一个"慢"的WPF ComboBox作战,并且很想知道是否有人有调试这样一个问题的技巧.

假设我有两个组合框,A和B.当A改变时,B中的项也会改变.每个ComboBox都有他们的SelectedItem和ItemsSource数据绑定,如下所示:

<ComboBox Grid.Column="1" ItemsSource="{Binding Names}" SelectedItem="{Binding CurrentName, Mode=TwoWay}" Margin="3" MinWidth="100" />
<ComboBox Grid.Column="1" Grid.Row="1" ItemsSource="{Binding SubNames}" SelectedItem="{Binding CurrentSubName, Mode=TwoWay}" Margin="3" MinWidth="100" />

每当B中的列表需要更改时,我通过清除子名称然后根据A中的SelectedItem重新添加条目来执行此操作.这样做是因为使用new覆盖SubNames ObservableCollection<string>会破坏数据绑定.

一台计算机上的所有内容都按照您的预期运行.选择A,然后单击B并立即弹出新项目.在另一台计算机上,当我这样做时,在渲染ComboBox之前最多有5秒的暂停.项目数量完全相同.一个不同之处在于,在慢速机器上,后台正在进行硬件通信.我冻结了所有这些线程并没有帮助.

我最大的问题是我无法弄清楚在哪里开始寻找.我需要查看系统在点击ComboBox时正在做什么.我正在使用数据绑定,所以我无法在任何地方放置断点.我确实试图改变我的SubNames声明

public ObservableCollection<string> SubNames { get; set; }

至

private ObservableCollection<string> subnames_ = new ObservableCollection<string>();
public ObservableCollection<string> SubNames
{
  get { return subnames_; }
  set { subnames_ = value; }
}

然后在getter和setter中放置断点以查看是否有过多的读取或写入,但没有.

任何人都可以建议我下一步尝试确定这种放缓的来源吗？我不相信它与ComboBox库存模板有任何关系,如本文所述.

Answer 1

虽然这可能无法直接回答您的问题，但一个建议是不要直接绑定到 ObservableCollection。由于集合在操作其内容时可能引发大量事件，因此最好将 ItemsControl 绑定到表示该 ObservableCollection 的 ICollectionView，并在更新集合时使用ICollectionView.DeferRefresh().

我通常做的是创建一个从 ObservableCollection 派生的类，该类公开一个DefaultView属性，该属性延迟实例化与该集合对应的 ICollectionView。然后，我将所有 ItemsControl 绑定到 collection.DefaultView 属性。然后，当我需要刷新或以其他方式操作集合中的项目时，我使用：

using (collection.DefaultView.DeferRefresh()) {
  collection. // add/remove/replace/clear etc
}

DeferRefresh()仅在释放返回的对象后才会刷新绑定控件。

另请注意，WPF 中的绑定机制有一个默认的 TraceSource，您可以使用它来收集有关绑定本身的更多信息；它不跟踪时间，所以我不确定它有多大用，但你可以通过以下方式激活它：

System.Diagnostics.PresentationTraceSources.DataBindingSource.Switch.Level = System.Diagnostics.SourceLevels.Verbose;

（或您喜欢的任何其他级别）。