为什么要拆分未在 UI 线程上运行的任务以使 WPF 应用程序更具响应性？答案

【问题标题】：Why to split the tasks not running on UI thread to make WPF app more responsive?为什么要拆分未在 UI 线程上运行的任务以使 WPF 应用程序更具响应性？
【发布时间】：2013-04-03 09:16:02
【问题描述】：

在part1 "Getting Started"的

亚历山德拉·鲁西娜的系列。 .NET Framework 4 中的并行编程

为了使 WPF UI 响应，它是通过将密集的计算外包到 UI 之外来完成的。最终，代码改为：

for (int i = 2; i < 20; i++)
 {
     var t = Task.Factory.StartNew(() =>
     {
         var result = SumRootN(i);
         this.Dispatcher.BeginInvoke(new Action(() =>
             textBlock1.Text += "root " + i.ToString() + " " + 
                result.ToString() + Environment.NewLine)
             ,null);
     });
 }

更新：因此将密集计算从 UI 线程中移出。

这是Part1 article 来到这个sn-p 时的引述：

“为了让 UI 具有响应性，我将使用任务，这是任务并行库引入的一个新概念。任务表示通常在单独的线程上运行的异步操作” 李>
“编译、运行……嗯，UI 是响应式的”

为了从那些单独的任务线程输出到 WPF UI（或避免 InvalidOperationException 说“调用线程无法访问此对象，因为不同的线程拥有它。”）使用了 Dispatcher.BeginInvoke()。

同一系列"Parallel Programming: Task Schedulers and Synchronization Context"的第二部分讲述了相同的sn-p代码（在引入局部迭代变量的小改动之后）：

“这个需要更彻底的重构。我无法运行所有 UI 线程上的任务，因为它们执行长时间运行的操作这将使我的用户界面冻结。此外，它将取消所有并行化的好处，因为只有一个 UI 线程。

我能做的就是把每个任务分成……”

the part1-article 与 the part2-article 不矛盾吗？

将不在 UI 线程上运行的任务分成几部分有什么需要？

我在这里误解了什么？

【问题讨论】：

标签： c# wpf multithreading c#-4.0 task-parallel-library

【解决方案1】：

我认为这里有两个不同的概念。第 1 部分讨论了在任务中运行代码以不阻塞 UI 线程。第 2 部分讨论并行运行多个任务。一个用于“不阻塞 UI 线程”，另一个用于并行完成更多事情。如果您只有两个线程：UI 线程和任务线程，那么事情就不会并行发生，您也没有利用并行处理的真正力量。

【讨论】：

【解决方案2】：

这些陈述并不矛盾，它们是一个整体。
UI 线程负责刷新窗口和其中的控件，因此当您激活它们时会做出反应，用鼠标光标移动它们等等。
如果您要执行长时间运行的操作，例如具有 10000 次迭代的for-loop，UI would freeze 会变得无响应（窗口会变得模糊，并且会出现蓝色的小甜甜圈）。 for-loop 完成后，您的 UI 将再次出现。
为了减轻 UI 线程的额外负担，您将长时间运行的任务放在单独的线程/任务中，以便它们同时执行。您的UI 将保持响应并接受命令（点击、击键等）。也许不相关，但正在努力解决其背后的基础知识

用户希望应用在计算时保持响应，无论机器类型如何。这对不同的应用程序意味着不同的东西。对于一些人来说，这意味着提供更真实的物理，更快地从磁盘或 Web 加载数据，快速呈现复杂场景并在页面之间导航，在快照或快速处理数据。无论计算类型如何，用户都希望他们的应用程序根据他们的输入采取行动，并消除看起来暂停的实例当它“思考”时。

在此处阅读this 文章。

【讨论】：