15.5.4 【Task实现细节】一个入口搞定一切

　　如果你反编译过异步方法（我非常希望你会这么做），会看到状态机中的 MoveNext() 方法 非常长，变化非常快，像是一个计算有多少 await 表达式的函数。它包含原始方法中的所有逻辑， 和处理所有状态变换所需要的芭蕾舞步 ① ，以及用来处理整个结果或异常的包装代码。

　　在手动编写异步代码时，你通常会将后续操作分散到多个方法内：在一个方法内开始，然后 在另一个方法内继续，并且可能在第三个方法中结束。但这样很难处理循环等流控制，对C#编译 器来说更是不可能的。这和生成代码的可读性差是两码事。状态机具有单独的入口，即 MoveNext() 方法。该方法在一开始便投入使用，并且可用于所有 await 表达式的后续操作。每当调用 MoveNext() 方法时，状态机就会通过 state 字段计算出方法要跳转到的位置。在准备计算结果 时，则跳转到方法的逻辑起始位置或 await 表达式的末尾。每个状态机只执行一次操作。实际上， 在方法内部存在一个基于 state 的 switch 语句，每种情况都具有包含不同标签的对应 goto 语句。

MoveNext() 方法一般为以下形式：

             void IAsyncStateMachine.MoveNext()
             {
                 //对于声明返回Task<int>的异步方法
                 int result = default(int);
                 try
                 {
                     bool doFinallyBodies = true;
                     switch (state)
                     {
                         //跳转到正确的位置
                     }
                     //方法主体
                 }
                 catch (Exception e)
                 {
                     state = -;
                     builder.SetException(e);
                     return;
                 }
                 state = -;
                 builder.SetResult(result);
             }

　　初始状态始终为 -1 ，方法执行时状态也是 -1 （与等待时被暂停相反）。非负值均表示一个后 续操作的目标。状态机在结束时状态为 -2 。在调试配置下创建的状态机中，你会看到一个指向 -3 状态的引用——此状态是我们未曾预料到的。退化的 switch 语句会导致糟糕的调试体验，而 -3 状态即是为避免该退化语句的出现而存在的。

　　在方法执行过程中，在原始异步方法的 return 语句处，会设置 result 变量。然而在到达方 法的逻辑末尾时，将其用于 builder.SetResult() 的调用。即使是非泛型的 AysncTask MethodBuilder 和 AsyncVoidMethodBuilder 类型，也包含 SetResult() 方法。前者表示对 于从骨架方法返回的任务来说，该方法已经完成；后者则表示原始的 SynchronizationContext 已经完成。（异常会以同样的方式向原始的 SynchronizationContext 传播。这是一种相当丑陋 的跟踪方式，但却对必须使用 void 方法的场景提供了一种解决方案。）

　　doFinallyBodies 变量用于计算执行过程离开 try 块的作用域时，原始代码中的 finally 块（包括 using 或 foreach 语句中的隐式 finally 块）是否应该执行。理论上，只有以正常方式 离开 try 块的作用域时，我们才希望执行 finally 块。如果我们只是从之前为awaiter附加了后续 操作的方法中返回，由于该方法逻辑上已经“暂停”了，因此我们不希望再执行 finally 块。 finally 块均位于相关的 try 块之后，并出现在代码方法部分的 Main 主体中。

　　从原始异步方法的角度来看，大多方法体都是可识别的。当然，你需要习惯于所有局部变量 都作为状态机的实例变量，但这并不是什么难事。正如你所想的那样，棘手之处是 await 表达式。