Gdy poprawnie korzystasz z Task.Run i gdy tylko async-czekaj

Chciałbym zapytać Cię o Twoją opinię na temat prawidłowej architektury, kiedy używać Task.Run. Występuje opóźniony interfejs użytkownika w naszej aplikacji WPF .NET 4.5 (z ramą Caliburn Micro).

Zasadniczo robię (bardzo uproszczone fragmenty kodu):

public class PageViewModel : IHandle<SomeMessage>
{
   ...

   public async void Handle(SomeMessage message)
   {
      ShowLoadingAnimation();

      // Makes UI very laggy, but still not dead
      await this.contentLoader.LoadContentAsync();

      HideLoadingAnimation();
   }
}

public class ContentLoader
{
    public async Task LoadContentAsync()
    {
        await DoCpuBoundWorkAsync();
        await DoIoBoundWorkAsync();
        await DoCpuBoundWorkAsync();

        // I am not really sure what all I can consider as CPU bound as slowing down the UI
        await DoSomeOtherWorkAsync();
    }
}

Z artykułów / filmów, które przeczytałem / widziałem, wiem, że await asyncniekoniecznie działa na wątku w tle i aby rozpocząć pracę w tle, musisz go owinąć Task.Run(async () => ... ). Użycie async awaitnie blokuje interfejsu użytkownika, ale nadal działa w wątku interfejsu, więc powoduje, że jest on opóźniony.

Gdzie najlepiej umieścić Task.Run?

Powinienem tylko

1. Zawiń zewnętrzne wywołanie, ponieważ jest to mniej wątkowe dla platformy .NET

2. , czy powinienem zawijać tylko wewnętrznie działające metody związane z procesorem, Task.Runponieważ dzięki temu można go używać w innych miejscach? Nie jestem tutaj pewien, czy dobrym pomysłem jest rozpoczęcie pracy nad wątkami w tle głęboko w rdzeniu.

Ad (1) pierwsze rozwiązanie wyglądałoby tak:

public async void Handle(SomeMessage message)
{
    ShowLoadingAnimation();
    await Task.Run(async () => await this.contentLoader.LoadContentAsync());
    HideLoadingAnimation();
}

// Other methods do not use Task.Run as everything regardless
// if I/O or CPU bound would now run in the background.

Ad (2), drugie rozwiązanie wyglądałoby tak:

public async Task DoCpuBoundWorkAsync()
{
    await Task.Run(() => {
        // Do lot of work here
    });
}

public async Task DoSomeOtherWorkAsync(
{
    // I am not sure how to handle this methods -
    // probably need to test one by one, if it is slowing down UI
}

Zwróć uwagę na wytyczne dotyczące wykonywania pracy w wątku interfejsu użytkownika , zebrane na moim blogu:

• Nie blokuj wątku interfejsu użytkownika przez więcej niż 50 ms jednocześnie.
• Możesz zaplanować ~ 100 kontynuacji w wątku interfejsu użytkownika na sekundę; 1000 to za dużo.

Należy użyć dwóch technik:

1) Użyj, ConfigureAwait(false)kiedy możesz.

Np. await MyAsync().ConfigureAwait(false);Zamiast await MyAsync();.

ConfigureAwait(false)informuje await, że nie trzeba wznawiać w bieżącym kontekście (w tym przypadku „w bieżącym kontekście” oznacza „w wątku interfejsu użytkownika”). Jednak w pozostałej części tej asyncmetody (po ConfigureAwait) nie można zrobić niczego, co zakładałoby, że jesteś w bieżącym kontekście (np. Zaktualizować elementy interfejsu użytkownika).

Aby uzyskać więcej informacji, zobacz mój artykuł MSDN Najlepsze praktyki w programowaniu asynchronicznym .

2) Służy Task.Rundo wywoływania metod związanych z procesorem.

Powinieneś używać Task.Run, ale nie w żadnym kodzie, który ma być wielokrotnego użytku (tj. Kod biblioteki). Więc użyć Task.Runaby zadzwonić metody, a nie jako część realizacji tego sposobu.

Więc praca związana wyłącznie z procesorem wyglądałaby następująco:

// Documentation: This method is CPU-bound.
void DoWork();

Które nazwałbyś używając Task.Run:

await Task.Run(() => DoWork());

Metody będące połączeniem procesora i operacji we / wy powinny mieć Asyncpodpis z dokumentacją wskazującą na ich charakter:

// Documentation: This method is CPU-bound.
Task DoWorkAsync();

Który też wywołałbyś używając Task.Run(ponieważ jest częściowo związany z procesorem):

await Task.Run(() => DoWorkAsync());

Jednym z problemów z ContentLoaderem jest to, że wewnętrznie działa on sekwencyjnie. Lepszym wzorem jest ujednolicenie pracy, a następnie sychronizacja na końcu, więc otrzymujemy

public class PageViewModel : IHandle<SomeMessage>
{
   ...

   public async void Handle(SomeMessage message)
   {
      ShowLoadingAnimation();

      // makes UI very laggy, but still not dead
      await this.contentLoader.LoadContentAsync(); 

      HideLoadingAnimation();   
   }
}

public class ContentLoader 
{
    public async Task LoadContentAsync()
    {
        var tasks = new List<Task>();
        tasks.Add(DoCpuBoundWorkAsync());
        tasks.Add(DoIoBoundWorkAsync());
        tasks.Add(DoCpuBoundWorkAsync());
        tasks.Add(DoSomeOtherWorkAsync());

        await Task.WhenAll(tasks).ConfigureAwait(false);
    }
}

Oczywiście nie działa to, jeśli którekolwiek z zadań wymaga danych z innych wcześniejszych zadań, ale powinno zapewnić lepszą ogólną przepustowość w większości scenariuszy.