WPF UI主线程之子线程与副线程

最近项目软件出现一个问题，有点困扰，就是视图绑点数值更新，运行少则半天，多则2天，停止显示更新。

视图绑点数据更新分三步：
第一步：向绑点所在的控制器发送数据请求帧；
第二步：收到控制器的应答帧后，更新Datatable dtBinding数值
第三步：更新视图界面的绑点数值、动画

方案1：将以上所有工作流程放在DispatcherTimer的TimerHandler()里实现，设置3秒更新一边，实测应该超时未全部完成工作流程，溢出了，停止更新时间最短，DispatcherTimer线程是WPF的UI主线程的子线程，应该尽量做少量工作，我用另外一个DispatcherTimer每秒显示系统时钟，工作正常，即使视图不更新的情况下，时钟更新也正常，说明故障没有出现在UI主线程，故障出现在视图显示更新DispatcherTimer子线程，或许因为没有在规定时间完成规定的工作量被排除在Dispatcher队列，因此停止数据更新？！

方案2：另外new一个Thread线程，与UI主线程并行，姑且称之为通讯线程（副线程），将以上三步全部放在这里执行，其中第三步要求在UI主线程实现，需要放到Dispatcher排队委托UI主线程更新显示，实测2天后也停止更新了，观察发现：时钟更新显示正常，Wireshark测试通讯请求和应答帧都在，说明通信线程正常，Dispacher子线程好像不怎么可靠？

方案3：第一步第二步放在通信线程，第三步用DispatcherTimer定时线程更新显示数据（显示线程），为了保险起见，设计了一个看门狗，显示线程里喂狗，通信线程是无线循环线程，完成第一步第二步后sleep 5秒，然后watchdog减1，设置25秒时间，如果显示线程没有执行，即得不到喂狗，通信线程将关闭程序后重启，重启后需要重新登录。这样重启后释放了资源，视图更新流程又回到了起点。

曾经怀疑循环运行变量反复创建，内存占用过大，打开任务管理器测试，发现内存被系统清理，没有出现运行时间长，内存增长的现象。

结论：比较倾向的故障原因是Dispatcher子线程，如果工作量大（一次更新太多绑点数据）则可能溢出，而被WPF  UI主线程排除Dispatcher队列，造成停止显示数据更新的现象。

工作之余，看世界杯现场直播，感觉国内外对待奥秘可容病毒的认知差异很大，我们好像被病毒恐慌绑架了，个中原因莫衷一是。个人觉得解决之道不应该脱离依法治国精神，简单说就是要“形式正义”，又称“程序正义”，疫情防控过程中，执行前要有书面授权，执行过程中向当事人出示盖章文件，文件盖章可以事后追责，无论多紧急都不能口头通知代替书面通知，如果事后无法追责当事人就会有人拍脑袋行事，事后不负责任造成肆意妄为，假公济私的行为，这样的社会危害甚至超过病毒本身。