В настоящее время я работаю над проблемой, с которой я сталкиваюсь последние недели или около того.
Это не обычная проблема замораживания, решаемая многопоточностью, потому что я делаю это уже для бизнес-логики.
У меня есть представление с сеткой данных, DataContext - это модель представления, предоставляющая ObservableCollection<T> для CollectionViewSource с именем iGroupingJournal.
<DataGrid Grid.Row="1" ItemsSource="{Binding Source={StaticResource iGroupedJournal}}">
<DataGrid.Columns>
<DataGridTextColumn Binding="{Binding Path=DateTime}" Header="DateTime" />
[...]
</DataGrid.Columns>
</DataGrid>
Обычно отображается около 50 строк с 7 столбцами, что приводит к зависанию приложения во время генерации этих строк.
Я уже исключил следующие причины:
1,1. сложный бизнес-класс, производящий накладные расходы -> протестирован с классом хранения данных, не дает увеличения скорости
1.2. дорогостоящий запрос к базе данных выполняется в потоке графического интерфейса из-за получения данных через LINQ -> данные извлекаются в рабочий поток путем вызова ToList и сопоставления данных с вышеупомянутыми классами хранения
1.3. группировка сборов увеличивает накладные расходы -> убрал заголовок группировки в CollectionViewSource.
Было проверено или продумано следующее:
2,1. Протестированная виртуализация пользовательского интерфейса путем удаления инструкции по группировке не дала никаких результатов, также желательна группировка
2,2. Виртуализация данных - не даст эффекта, потому что нужно создать 50 строк, как это обычно показано
Заключение
Я сделал все, что мог, чтобы вытащить работу из потока GUI, и с помощью LoadIndicator было ясно, что в тот момент, когда рабочая нить отправляет NotifyCollectionChanged потоку GUI, все приложение зависает. Вы сталкивались с этой проблемой раньше? Как ты это решил? Или мне действительно не повезло?