在这里使用任务是否有优势

Question

我有一个方法，我正在考虑使用任务来做一些工作。但在这种情况下真的有优势吗？我的理由是因为CheckInToWebDocs方法取决于SaveDocument创建的文件的存在。

没有任务

 Private Sub PopulatePDF()
     Dim PrintLib As New Print
        Dim sPDFFilePath As String = ""
        If PrintLib.CreateEnrolledApp(EnrollmentID, sPDFFilePath) Then
           AppName = Page.ResolveUrl("~\SomeLocation\" & Path.GetFileName(sPDFFilePath))
           hlApplication.NavigateUrl = AppName

           SaveDocument(Constants.enumDocumentTypes.Application, EnrollmentID, Path.GetFileName(sPDFFilePath), sPDFFilePath)

           CheckInToWebDocs(EnrollmentID, sPDFFilePath)
        End If
    End Sub

使用任务

 Private Sub PopulatePDF()
        Dim PrintLib As New Print
        Dim sPDFFilePath As String = ""
        If PrintLib.CreateEnrolledApp(EnrollmentID, sPDFFilePath) Then
            AppName = Page.ResolveUrl("~\SomeLocation\" & Path.GetFileName(sPDFFilePath))
            hlApplication.NavigateUrl = AppName

            Dim saveDocumentTask As Task = Task.Run(Sub() SaveDocument(Constants.enumDocumentTypes.Application, EnrollmentID, Path.GetFileName(sPDFFilePath), sPDFFilePath))
            saveDocumentTask.Wait()

            CheckInToWebDocs(EnrollmentID, sPDFFilePath)
        End If
    End Sub

Answer 1

不是你使用它的方式。它将增加并行任务的开销，但您仍然需要等待任务完成。

是否存在SaveDocument的异步变体？如果是这样，那么您可以创建自己的PopulatePDF()方法Async，调用Await SaveDocumentAsync(...)（如果命名遵循约定）。然后，PopulatePDF的任何消费者 也可以为异步，包括对UI事件的回复，这些回复会为您提供我认为您正在寻找的好处。

对评论的回应：这太遗憾了。在这种情况下我会说：将Task.Run添加到您的实现中仍然没有任何好处。这可能很诱人，但你需要知道这会产生一个新线程。也就是说，如果你做这样的事情：

Private Async Function PreparePdfAsync() As Task
  ...
  Await Task.Run(Sub() SaveDocument(...))
  ...
End Function

您只获得虚假异步代码 - 在后台线程上运行的同步代码。在UI场景中，您最好的选择是让UI消费者在需要时自己调用Task.Run()，不要将该细节包裹起来，因为线程产生是非显而易见且可能有害的行为。

有关Task.Run etiquette的更多信息，请参阅Stephen Cleary，如果您是Async / Await的新手，请务必阅读其他介绍文章。