在大型数据绑定 ObservableCollection 中添加/删除许多项目，而无需冻结 GUI

我和我的团队正在开发一个 WPF 应用程序，该应用程序显示多个并发 XamDataChart 控件（由 Infragistics 提供）。每个图表都绑定到不同的 ObservableCollection，最多可包含 200 万个点。对于每个图表，DispatcherTimer 会定期检索要附加到集合中的新项目（每 100 毫秒最多 1000 个）。每次新项目出现时，它们都会被添加到集合的“尾部”，并从“头部”删除相同数量的项目，以便集合中的项目数量在一段时间内保持不变。

我们面临的问题是添加/删除操作冻结了 GUI，因为集合只能由主线程修改。我们尝试了很多方法（BackgroundWorker、Application.Current.Dispatcher 和 DispatcherPriority.Background、Task.Factory 等），但似乎都没有解决问题，并且 GUI 一直冻结。

您能否建议我们处理大量绑定数据同时保持 GUI 响应能力的最佳方法？

UPDATEs:

1）正如我在下面的评论中所指出的，我们已经尝试在抑制 OnCollectionChanged 的​​同时添加和删除项目。即使它看起来对少量数据有效，但在我们的场景中，该解决方案的优势确实不明显。

2) 在单独的线程中准备和收集数据。这是一个长时间运行的操作，但没有明显的缓慢或无响应现象。当数据传递到图表组件进行渲染时，应用程序会冻结。

3) 以下是生成数据（在单独的线程中）并在 UI 上显示数据的方法：

private void GenerateDataButtonClick(object sender, RoutedEventArgs e)
{
   Task<List<RealTimeDataPoint>> task = Task.Factory.StartNew(() =>           this.RealTimeDataPointGenerator.GenerateData(2000000));
   Application.Current.Dispatcher.BeginInvoke(DispatcherPriority.Background, new Action(() =>  {                                                                                                    this.DataPoints.Clear();
                                                                                            this.DataPoints.AddRange(task.Result);
                                                                                                 if (!this.StartDataFeedButton.IsEnabled)
                                                                                                     this.StartDataFeedButton.IsEnabled = true;
                                                                                             }));
}

public void DispatcherTimerTick(object sender, EventArgs e)
{
   Task<List<RealTimeDataPoint>> task = Task.Factory.StartNew(() => this.RealTimeDataPointGenerator.GenerateData(1000));
   Application.Current.Dispatcher.BeginInvoke(DispatcherPriority.Background, new Action(() => {                                                                                                  this.DataPoints.RemoveRange(0, task.Result.Count);                                                                                                  this.DataPoints.AddRange(task.Result);                                                                                              }));
}

提前致谢， 詹卢卡

如果不了解更多关于您的情况，很难知道正确的建议，因此我建议您将示例发布到 Infragistics 论坛并寻求帮助，如果您还没有这样做，如果您已经这样做，请回复链接帖子，我会看一下。

如果您要作为单独的操作同时更新许多点，那么让您的集合仅引发一个事件而不是每个单独的事件会很有帮助。例如，如果您通过重复调用 Add 来更新集合的全部内容，则最好发送一个 Reset 事件，而不是发送所有单独的事件。但似乎您已经在调用 AddRange，我相信这只会向图表发送一个通知。

如果您只有两个系列并且仅每 100 毫秒更新一次，我认为这不会导致 UI 冻结，但如果您有许多单独的系列，并且通过单独的调度程序交互单独更新数据，那么实际上会导致图表的刷新次数可能比您预期的要多得多。

图表将批量修改并限制刷新次数，但它使用调度程序来执行此操作，因此，如果您有 15 个不同的系列，您正在以不同的时间间隔进行更新，并且全部作为单独的调度程序重击，那么您将导致更多与通过在同一调度程序 thunk 中更新多个系列数据源来限制更新次数相比，图表的更新次数要少。

此外，如果您在上面的代码中使用 CategoryDateTimeXAxis，您可能会遇到它当前在修改时对日期列进行排序的限制，这将损害您在该规模下的性能。在这种情况下，我建议提交该轴类型的功能请求以支持预排序的数据。

如果您的数据项支持 INotifyPropertyChanged，但您不使用它来通知图表值更改，则最好使用不实现 INotifyPropertyChanged 的​​项类型。如果您提交实现此接口的项目，则图表假定它需要订阅此接口才能收到更改通知（您可能永远不打算进行更改）。这听起来可能不是一个问题，但如果您有 200 万条记录需要频繁更新，那么就会无缘无故地产生大量事件订阅。

据我所知，该图表从属性绑定检索值的速度比字符串索引器快得多，因此请确保它是一个简单的属性，并且不是 MemberPath 中的点式属性路径。

希望这些信息对您有用。但使用可运行的示例来诊断问题要容易得多，该示例提供了可能导致问题的所有上下文。