c# - thread - unity async await




C#中的“return await”的目的是什么? (4)

你希望这样做的唯一原因是,如果在前面的代码中还有其他人await ,或者在返回结果之前以某种方式操纵结果。 另一种可能发生的方式是通过try/catch来改变如何处理异常。 如果你没有这样做,那么你是对的,没有理由添加使方法async的开销。

没有写这种方法的场景:

public async Task<SomeResult> DoSomethingAsync()
{
    // Some synchronous code might or might not be here... //
    return await DoAnotherThingAsync();
}

代替这个:

public Task<SomeResult> DoSomethingAsync()
{
    // Some synchronous code might or might not be here... //
    return DoAnotherThingAsync();
}

会有道理吗?

为什么使用return await构造函数可以直接从内部DoAnotherThingAsync()调用返回Task<T>

我看到在很多地方都有return await代码,我想我应该错过了一些东西。 但据我所知,在这种情况下不使用async / await关键字并直接返回任务在功能上是等同的。 为什么增加附加的await层的额外开销?


制作其他简单的“thunk”方法async会在内存中创建一个异步状态机,而非异步状态机则不会。 虽然这通常可以指出人们使用非异步版本,因为它更高效(这是事实),这也意味着如果出现挂起情况,则没有证据表明该方法涉及“返回/连续堆栈”这有时会使得更难理解挂起。

所以是的,当perf不重要时(通常不会),我会对所有这些thunk方法进行异步处理,以便我有异步状态机来帮助我稍后诊断挂起,并且还帮助确保那些thunk方法随着时间的推移而不断发展,他们一定会返回错误的任务而不是抛出。


当在正常方法中return await并且在async方法中return await行为有所不同时,有一种偷偷摸摸的情况:当与using (或者更一般地,在try块中的任何return await )结合时。

考虑这两种方法的版本:

Task<SomeResult> DoSomethingAsync()
{
    using (var foo = new Foo())
    {
        return foo.DoAnotherThingAsync();
    }
}

async Task<SomeResult> DoSomethingAsync()
{
    using (var foo = new Foo())
    {
        return await foo.DoAnotherThingAsync();
    }
}

第一种方法会在DoAnotherThingAsync()方法返回时立即Dispose() Foo对象,这很可能在它实际完成之前很久。 这意味着第一个版本可能是越野车(因为Foo处置得太快),而第二个版本可以正常工作。


您可能需要等待结果的另一种情况是:

async Task<IFoo> GetIFooAsync()
{
    return await GetFooAsync();
}

async Task<Foo> GetFooAsync()
{
    var foo = await CreateFooAsync();
    await foo.InitializeAsync();
    return foo;
}

在这种情况下, GetIFooAsync()必须等待GetFooAsync的结果,因为T的类型在两个方法之间不同, Task<Foo>不能直接分配给Task<IFoo> 。 但是如果你等待结果,它就变成了可以直接分配给IFoo Foo 。 然后,异步方法只是重新包装Task<IFoo>内的结果,然后离开你。







async-await