c# - Dispatch Thread being Saturated - 从 vanilla MVVM 寻找设计模式更改

Question

也许“饱和”是错误的词，但基本上我的 Dispatch 线程一直很忙，因为我有大量的 UI 更新。

在此之前，我一直遵循(并享受)我所说的 vanilla MVVM 设计模式。我用来指导我的开发的关键资源列在对 MVVM: Tutorial from start to finish 的优秀公认答案中。 .

具体来说;

Jason Dolinger's presentation on the Model-View-ViewModel

粗略架构

我有以下命名空间；

数据

连接到外部服务并监听更新

每 1-2 秒接收一个更新包

单个“调度源”，它在调度程序上为应用程序调度所有 ViewModel 更新

View 模型

在 UI 线程上创建的所有类和所有方法都在 UI 线程上调用

处理从数据到 GUI 代码的所有转换

看法

Xaml 类(class)

很少(如果有)代码隐藏或转换逻辑

唯一的重量级组件是 XCeed DataGrid在内部对数据进行排序

数据集

在高峰期，调度源每分钟在调度线程上调度 65,000 个事件。

每秒 1,000 个事件 其中每个事件都会导致大约 4 个绑定(bind)发生变化。用于确定新值的逻辑很少(但有一些逻辑)，通常可能有一个字符串开关或哈希查找来查找行背景的颜色。

问题

我想现在这很明显，但是响应能力很差。有时 UI 会完全锁定。

如果我将负载减半，那么 GUI 就可以了，所以它不会减少一个数量级，但如果它能够处理一个数量级以上的情况会很好。

这种情况有没有好的设计模式？

我建议这个问题不是我独有的，我希望有比我更聪明的人试图设计一个解决方案。很明显我需要

许多和轻量级 VS 不频繁和重量级

我可以在后台线程中以某种方式进行更改，然后在 UI 线程上运行的批处理方法中更新 4000 个绑定(bind)，而不是在 UI 线程上调度 1000 次单独的更新(方法调用)，每次更改 4 个绑定(bind)。

这将减少调度方法调用所花费的开销，但可能会在任何时候执行这些批处理之一时锁定 UI。不理想。

底线

我不知道该怎么做，我觉得我需要在后台线程上对对象进行所有更改，然后每隔一段时间(每两秒？)轮询状态，以便 UI 保持响应。

这听起来不像我知道和喜欢的 MVVM。是否有合适的方法绑定(bind)到以这种速度变化的数据集？

Answer 1

您可以创建所有内容都绑定(bind)到的基本/根 ViewModel 并让它实现 INotifyPropertyChanged - 但只有火PropertyChanged使用计时器的事件，如果任何属性已更改。

当属性更改时 -> 将其添加到唯一的“脏”列表中。计时器经过 -> 触发该列表中的所有事件，重置列表。