c# - 在异步任务和 UI 线程中提高 PropertyChanged

Question

在许多博客、教程和 MSDN 中，我可以了解到从非 UI 线程访问 UI 元素是不可能的 - 好吧，我会得到一个未经授权的异常。为了测试它，我写了一个非常简单的例子:

// simple text to which TextBlock.Text is bound
private string sample = "Starting text";
public string Sample
{
    get { return sample; }
    set { sample = value; RaiseProperty("Sample"); }
}

private async void firstButton_Click(object sender, RoutedEventArgs e)
{
    await Job(); // asynchronous heavy job
    commands.Add("Element"); // back on UI thread so this should be ok?
}

private async Task Job()
{
    // I'm not on UI Thread ?
    await Task.Delay(2000); // some other job
    Sample = "Changed";  // not ok as not UI thread?
    commands.Add("Element from async"); // also not ok?
}

我有一个 Task这是异步运行的。在那Task我想更改我的属性(这将提高 PropertyChanged )并将元素添加到 ObservableCollection .运行时async ，我不应该那样做，但我没有异常(exception)，代码工作正常。于是我的疑惑和误解:

• 为什么我没有得到异常？
• 可以提高吗PropertyChanged在async任务？
• 可以修改ObservableCollection吗在async Task , 或者我应该返回 Task<ICollection>并在获得结果后修改 ObservableCollection - 清除并填充它？
• 我什么时候在Task在 UI 线程上，什么时候不？
• 在上面的代码中 firstButton_Click在 await 之后管理 UI 元素是否可以？正在 Task ？我总是回到 UI 线程吗？

为了进一步测试它，我将我的属性更改和集合修改放在其他线程中:

System.Threading.Timer newThreadTimer = new System.Threading.Timer((x) =>
   {
       Sample = "Changed";  // not UI thread - exception
       commands.Add("Element from async"); // not UI thread - exception
   }, null, 1000, Timeout.Infinite);

在上面的代码中，我的想法是正确的——就在第一行或第二行之后，我得到了一个异常。但是第一个代码呢？我的Task是不是运气好在 UI 线程上运行？

我怀疑这是非常基本的事情和我的误解，但我需要一些澄清，因此这个问题。

Answer 1

等待任务时，SynchronizationContext当前线程的线程被捕获(特别是在 Task 的情况下由 TaskAwaiter )。然后，continutation 被编码回 SynchronizationContext 以执行该方法的其余部分(await 关键字之后的部分)。

让我们看看您的代码示例:

private async Task Job()
{
    // I'm not on UI Thread ?
    await Task.Delay(2000); // some other job
    Sample = "Changed";  // not ok as not UI thread?
    commands.Add("Element from async"); // also not ok?
}

当您await Task.Delay(2000) 时，编译器会隐式捕获SynchronizationContext，它当前是您的WindowsFormsSynchronizationContext。当 await 返回时，继续在相同的上下文中执行，因为您没有明确告诉它不要这样做，这是您的 UI 线程。

如果您将代码更改为 await Task.Delay(200).ConfigureAwait(false)，则延续将不会编码回您当前的 SynchronizationContext，并且会运行 ThreadPool 线程，导致您的 UI 元素更新引发异常。

在您的计时器示例中，Elapsed 事件是通过 ThreadPool 线程引发的，因此您会收到一个异常，提示您尝试更新由一个不同的线程。

现在，让我们一一解答您的问题:

why don't I get exception?

如前所述，await Task.Delay(2000) 在 UI 线程上执行了 Continuation，这使得更新控件成为可能。

is it ok to Raise properties in async Task?

我不确定您所说的“提升属性”是什么意思，但是如果您的意思是提升一个 INotifyPropertyChanged 事件，那么是的，可以不在 UI 线程上下文中执行它们。

is it ok to modify ObservableCollecition in async Task, or should I return Task and after obtaining the result modify Observable - Clear it and Fill it?

如果您有一个 async 方法并且您想要更新一个 UI 绑定(bind)元素，请确保您在 UI 线程上编码延续。如果从 UI 线程调用该方法并且您await 它的结果，那么延续将隐式地在您的 UI 线程上运行。如果您想通过 Task.Run 将工作卸载到后台线程并确保您的延续在 UI 上运行，您可以使用 TaskScheduler 捕获您的 SynchronizationContext .FromCurrentSynchronizationContext() 并显式传递给它继续

when am I in Task on UI thread and when not?

Task 是对将来要完成的工作的 promise 。当您在 UI 线程上下文中对 TaskAwaitable 执行 await 时，您仍在 UI 线程上运行。如果出现以下情况，您不在 UI 线程中:

1. 您的异步方法当前正在从不同于 UI 线程的线程执行(ThreadPool 线程或新的 Thread)
2. 您使用 Task.Run 将工作卸载到后台 ThreadPool 线程。

in the code above in firstButton_Click is it ok to manage UI elements after awaiting the Task? Am I always back on UI thread?

只要您不明确告诉您的代码不要使用 ConfigureAwait(false) 返回其当前上下文，您就会返回到 UI 线程