使用WPF MVVM进行周期性更新时出现间歇性卡顿问题

我之前处理过几乎一模一样的高频数据绑定场景，你的问题核心出在绑定机制的低效使用和UI线程过度负载上，咱们一步步拆解修复：

1. 先揪出卡顿的关键原因 #

从你的代码来看，导致每2-3秒停滞的几个核心问题：

• 重复Linq计算开销：Changes1-Changes8都是返回_changes.Skip().Take()的IEnumerable，每次UI触发绑定更新时，都会重新执行一遍这些Linq查询，高频更新下这会额外消耗大量CPU。
• 过度的Dispatcher调用：每次循环给1000个ChangeModel分别调用Dispatcher.BeginInvoke，直接把UI线程的消息队列塞满，导致UI来不及处理请求，出现停滞。
• 未启用ListView虚拟化：默认情况下，搭配GridView的ListView可能没开启虚拟化，这会导致1000条数据全部被渲染——哪怕它们不在可视区域内，极大消耗UI资源。
• 频繁的PropertyChanged触发：每个ChangeModel每次值变化都触发一次属性通知，1000条数据每次更新就产生1000次通知，UI绑定系统需要处理海量更新请求。

2. 具体解决方案 #

方案一：优化集合绑定，避免重复计算 #

把IEnumerable类型的Changes1-Changes8替换为缓存的List，一次性完成切片计算，避免每次绑定都重新执行Linq：

// ViewModel中缓存切片后的列表
private List<ChangeModel> _changes1;
public List<ChangeModel> Changes1 => _changes1;

private void Initialize()
{
    for (int i = 1; i <= _maxCount; i++)
    {
        _changes.Add(new ChangeModel { Name = "Item " + i, Value = i });
    }
    // 一次性完成所有切片并缓存
    int sliceSize = _maxCount / 8;
    _changes1 = _changes.Skip(0).Take(sliceSize).ToList();
    _changes2 = _changes.Skip(sliceSize * 1).Take(sliceSize).ToList();
    _changes3 = _changes.Skip(sliceSize * 2).Take(sliceSize).ToList();
    // ... 同理初始化_changes4到_changes8
    Routine();
}

方案二：批量更新UI，减少Dispatcher调用 #

不要给每个ChangeModel单独调用Dispatcher，而是在后台计算好所有新值，一次性推给UI线程更新：

private void Routine()
{
    Task.Run(async () =>
    {
        while (true)
        {
            // 后台线程完成所有计算，不占用UI资源
            foreach (var change in _changes)
            {
                if (change.Value == change._minValue)
                    change._direction = true;
                else if (change.Value == change._maxValue)
                    change._direction = false;

                double temp = change.Value;
                temp += change._direction ? 1 : -1;
                change.SetTempValue(temp);
            }

            // 一次性在UI线程更新所有值，触发PropertyChanged
            Application.Current?.Dispatcher.Invoke(() =>
            {
                foreach (var change in _changes)
                {
                    change.ApplyTempValue();
                }
            });

            await Task.Delay(_delay);
        }
    });
}

然后修改ChangeModel增加临时值存储逻辑：

public class ChangeModel : ViewModelBase
{
    private double _tempValue;
    // ... 原有字段、属性

    public void SetTempValue(double value)
    {
        _tempValue = value;
    }

    public void ApplyTempValue()
    {
        Value = _tempValue;
    }
}

方案三：开启ListView虚拟化 #

在XAML的每个ListView上添加虚拟化属性，让控件只渲染可视区域内的item：

<ListView Grid.Row="0" Grid.Column="0" ItemsSource="{Binding Path=Changes1}"
          VirtualizingStackPanel.IsVirtualizing="True"
          VirtualizingStackPanel.VirtualizationMode="Recycling"
          ScrollViewer.CanContentScroll="True">
    <!-- 原有GridView内容 -->
</ListView>

注意ScrollViewer.CanContentScroll="True"是虚拟化生效的前提，WPF虚拟化依赖物理滚动而非平滑滚动。

方案四：优化PropertyChanged触发（可选） #

如果你的ViewModelBase的SetValue方法没有值变化判断，先加上这个逻辑，避免无效通知：

protected bool SetValue<T>(ref T field, T value, [CallerMemberName] string propertyName = null)
{
    if (EqualityComparer<T>.Default.Equals(field, value))
        return false;
    field = value;
    OnPropertyChanged(propertyName);
    return true;
}

3. 额外优化建议 #

• 可以用BindingOperations.EnableCollectionSynchronization允许后台线程直接更新ObservableCollection（需注意线程安全），进一步减少Dispatcher的使用。
• 所有数据读取、计算都放在后台线程，只把最终结果推给UI线程更新，绝对不要在UI线程做计算。
• 无需追求1ms级更新，人类视觉无法感知这么快的变化，10-30ms的更新频率已经足够流畅，可以适当调整_delay值。

内容的提问来源于stack exchange，提问作者Seung-hyun Kim