.NET 5.0下INotifyPropertyChanged实现后WPF视图不更新问题咨询

核心根因 #

出现该现象的本质是跨线程属性更新的Dispatcher调度优先级机制问题：

• 当前代码使用的System.Threading.Timer的回调运行在线程池工作线程上，而非WPF UI主线程。
• 当从非UI线程触发PropertyChanged通知时，WPF绑定系统会自动将对应的UI更新操作封送到UI线程的Dispatcher队列，但绑定系统默认给这类跨线程更新设置了极低的调度优先级（约等于ApplicationIdle级别的空闲优先级）。
• 当UI处于无交互的空闲状态时，Dispatcher会优先处理高优先级的窗口消息，长期不会调度到队列里堆积的低优先级跨线程更新。只有当用户拖动窗口时，窗口移动、重绘等高优先级消息进入队列，Dispatcher处理这些消息时才会顺带着执行之前堆积的低优先级更新，表现为拖动窗口时进度条才规律刷新。

排查步骤 #

• 在Progress属性的setter内添加日志，确认Timer回调是否持续正常触发、属性值是否按预期递增。该环节可排除Timer失效、逻辑中断的问题。
• 在OnPropertyChanged方法内添加日志，确认属性变更事件是否正常触发，排除事件订阅丢失、绑定路径错误的问题。可配合Snoop这类UI调试工具直接观察ProgressBar的实际依赖属性值，验证“后台属性值持续变化、UI渲染长期不更新”的典型特征。
• 抓取UI线程Dispatcher队列状态，可直观看到所有跨线程来源的绑定更新操作长期堆积在队列尾部，未被及时调度。

可落地修复方案 #

方案1：替换为DispatcherTimer（推荐） #

这是WPF场景下最适配的实现方式，彻底避免跨线程封送带来的优先级问题：

1. 引入命名空间using System.Windows.Threading;
2. 替换原有线程池Timer的初始化逻辑：

   public MainWindowViewModel()
   {
       updateProgressBarTimer = new DispatcherTimer(DispatcherPriority.Normal)
       {
           Interval = TimeSpan.FromMilliseconds(50)
       };
       updateProgressBarTimer.Tick += (s, e) => 
       {
           Progress += 2;
           if (Progress > 100)
               Progress -= 100;
       };
       updateProgressBarTimer.Start();
   }
   

   DispatcherTimer的回调直接运行在UI线程上，更新操作使用和窗口交互消息一致的优先级入队，不会出现长期堆积的问题。

方案2：手动调整跨线程更新的调度优先级 #

如果场景要求必须使用线程池Timer处理后台任务（例如后台计算、IO操作的进度同步），可以手动用更高优先级把属性变更通知投递到UI线程，替代WPF绑定系统默认的低优先级封送逻辑：

public int Progress
{
    get => progress;
    set
    {
        if (progress == value) return;
        progress = value;
        // 以常规UI优先级投递属性变更通知
        System.Windows.Application.Current.Dispatcher.Invoke(
            DispatcherPriority.Normal, 
            new Action(OnPropertyChanged)
        );
    }
}

认知误区纠正 #

很多开发者认为“WPF绑定自动支持跨线程属性更新，就等同于高效的线程安全实现”。实际上WPF为了避免高频跨线程更新阻塞UI响应，默认给跨线程的属性变更封送设置了极低的调度优先级，这是内置的流量控制机制，并非绑定链路故障。该机制在低频次更新场景下不会被感知，在定时器高频更新的场景下就会出现更新延迟、仅交互时才刷新的典型现象。

内容的提问来源于stack exchange，提问作者soaringmatty