匹夫细说C#：庖丁解牛聊委托，那些编译器藏的和U3D给的

new MyDelegate(PrintNum);

即便回到C#1的时代，这行创建新的委托实例的代码看上去似乎并没有让开发者产生什么不好的印象，但是如果是作为较长的一个表达式的一部分时，就会让人感觉很冗繁了。一个明显的例子是在启动一个新的线程时候的表达式：

Thread th = new Thread(new ThreadStart(Method));

这样看起来，C#1中的方式似乎并不简洁。因而C#2为委托引入了方法组转换机制，即支持从方法到兼容的委托类型的隐式转换。就如同我们一开始的例子中做的那样。

//使用方法组转换时，隐式转换会将  //一个方法组转换为具有兼容签名的  //任意委托类型  myDelegate = PrintNum;  Thread th = new Thread(Method);

而这套机制之所以叫方法组转换，一个重要的原因就是由于重载，可能不止一个方法适用。例如下面这段代码所演示的那样：

using UnityEngine; using System.Collections; public class DelegateScript : MonoBehaviour {    //声明一个委托类型，它的实例引用一个方法 delegate void MyDelegate(int num);  //声明一个委托类型，它的实例引用一个方法  delegate void MyDelegate2(int num, int num2);  MyDelegate myDelegate;  MyDelegate2 myDelegate2;  void Start ()  {   //委托类型MyDelegate的实例myDelegate引用的方法   //是PrintNum    myDelegate = PrintNum;   myDelegate(50);   //委托类型MyDelegate2的实例myDelegate2引用的方法   //PrintNum的重载版本        myDelegate2 = PrintNum;   myDelegate(50, 50);  }  void PrintNum(int num)  {   Debug.Log ("Print Num: " + num);  }  void PrintNum(int num1, int num2)  {   int result = num1 + num2;   Debug.Log ("result num is : " + result);  } } 

这段代码中有两个方法名相同的方法：

delegate Object TellMeYourName(SoldierClass soldier);

那么我们完全可以通过构造一个该委托类型的实例来引用具有以下原型的方法：

string TellMeYourNameMethod(BaseUnitClass base);

在这个例子中，TellMeYourNameMethod方法的参数类型是BaseUnitClass，它是TellMeYourName委托的参数类型SoldierClass的基类，这种参数的逆变性是允许的；而TellMeYourNameMethod方法的返回值类型为string，是派生自TellMeYourName委托的返回值类型Object的，因而这种返回类型的协变性也是允许的。但是有一点需要指出的是，协变性和逆变性仅仅支持引用类型，所以如果是值类型或void则不支持。下面我们接着举一个例子，如果将TellMeYourNameMethod方法的返回类型改为值类型int，如下：

int TellMeYourNameMethod(BaseUnitClass base);

这个方法除了返回类型从string（引用类型）变成了int（值类型）之外，什么都没有被改变，但是如果要将这个方法绑定到刚刚的委托实例上，编译器会报错。虽然int型和string型一样，都派生自Object类，但是int型是值类型，因而是不支持协变性的。这一点，各位读者在实际的开发中一定要注意。

internal delegate void MyDelegate(int number);  MyDelegate myDelegate = new MyDelegate(myMethod1);  myDelegate = myMethod2;  myDelegate(10);

从表面看，委托似乎十分简单，让我们拆分一下这段代码：用C#中的delegate关键字定义了一个委托类型MyDelegate；使用new操作符来构造一个MyDelegate委托的实例myDelegate，通过构造函数创建的委托实例myDelegate此时所引用的方法是myMethod1，之后我们通过方法组转换为myDelegate绑定另一个对应的方法myMethod2；最后，用调用方法的语法来调用回调函数。看上去一切都十分简单，但实际情况是这样吗？

internal delegate void MyDelegate(int number);

这行对开发者们来说十分简单的代码背后，编译器为我们做了哪些幕后的工作呢？

internal class MyDelegate : System.MulticastDelegate {  //构造器   [MethodImpl(0, MethodCodeType=MethodCodeType.Runtime)]  public MyDelegate(object @object, IntPtr method);  // Invoke这个方法的原型和源代码指定的一样   [MethodImpl(0, MethodCodeType=MethodCodeType.Runtime)]  public virtual void Invoke(int number);  //以下的两个方法实现对绑定的回调函数的一步回调   [MethodImpl(0, MethodCodeType=MethodCodeType.Runtime)]  public virtual IAsyncResult BeginInvoke(int number, AsyncCallback callback, object @object);  [MethodImpl(0, MethodCodeType=MethodCodeType.Runtime)]  public virtual void EndInvoke(IAsyncResult result); } 

可以看到，编译器为我们的MyDelegate类定义了4个方法：一个构造器、Invoke、BeginInvoke以及EndInvoke。而MyDelegate类本身又派生自基础类库中定义的System.MulticastDelegate类型，所以这里需要说明的一点是所有的委托类型都派生自System.MulticastDelegate。但是各位读者可能也会了解到在C#的基础类库中还定义了另外一个委托类System.Delegate，甚至System.MulticastDelegate也是从System.Delegate派生而来，而System.Delegate则继承自System.Object类。那么为何会有两个委托类呢？这其实是C#的开发者留下的历史遗留问题，虽然所有我们自己创建的委托类型都继承自MulticastDelegate类，但是仍然会有一些Delegate类的方法会被用到。最典型的例子便是Delegate类的两个静态方法Combine和Remove，而这两个方法的参数都是Delegate类型的。

public static Delegate Combine(  Delegate a,  Delegate b ) public static Delegate Remove(  Delegate source,  Delegate value ) 

由于我们定义的委托类派生自MulticastDelegate而MulticastDelegate又派生自Delegate，因而我们定义的委托类型可以作为这两个方法的参数。

public MyDelegate(object @object, IntPtr method);

但是我们回去看一看我们构造委托类型新实例的代码：

MyDelegate myDelegate = new MyDelegate(myMethod1);

似乎和构造器的参数对不上呀？那为何编译器没有报错，而是让这段代码通过编译了呢？原来C#的编译器知道要创建的是委托的实例，因而会分析代码来确定引用的是哪个对象和哪个方法。分析之后，将对象的引用传递给object参数，而方法的引用被传递给了method参数。如果myMethod1是静态方法，那么object会传递为null。而这个两个方法实参被传入构造函数之后，会分别被_target和_methodPtr这两个私有字段保存，并且_ invocationList字段会被设为null。

using UnityEngine; using System.Collections; public class DelegateScript : MonoBehaviour {       delegate void MyDelegate(int num);  MyDelegate myDelegate;  void Start ()  {     myDelegate = new MyDelegate(this.PrintNum);     this.Print(10, myDelegate);     myDelegate = new MyDelegate(this.PrintDoubleNum);     this.Print(10, myDelegate);     myDelegate = null;     this.Print(10, myDelegate);  }  void Print(int value, MyDelegate md)  {     if(md != null)     {      md(value);     }     else     {      Debug.Log("myDelegate is Null!!!");     }  }  void PrintNum(int num)  {   Debug.Log ("Print Num: " + num);  }  void PrintDoubleNum(int num)  {   int result = num + num;   Debug.Log ("result num is : " + result);  } } 

编译并且运行之后，输出的结果如下：

Print Num:10  result num is : 20  myDelegate is Null!!!

我们可以注意到，我们新定义的Print方法将委托实例作为了其中的一个参数。并且首先检查传入的委托实例md是否为null。那么这一步是否是多此一举的操作呢？答案是否定的，检查md是否为null是必不可少的，这是由于md仅仅是可能引用了MyDelegate类的实例，但它也有可能是null，就像代码中的第三种情况所演示的那样。经过检查，如果md不是null，则调用回调方法，不过代码看上去似乎是调用了一个名为md，参数为value的方法：md(value);但事实上并没有一个叫做md的方法存在，那么编译器是如何来调用正确的回调方法的呢？原来编译器知道md是引用了委托实例的变量，因而在幕后会生成代码来调用该委托实例的Invoke方法。换言之，上面刚刚调用回调函数的代码md(value);被编译成了如下的形式：

md.Invoke(value);

为了更深一步的观察编译器的行为，我们将编译后的代码反编译为CIL代码。并且截取其中Print方法部分的CIL代码：

// method line 4  .method private hidebysig         instance default void Print (int32 'value', class DelegateScript/MyDelegate md)  cil managed  {      // Method begins at RVA 0x20c8  // Code size 29 (0x1d)  .maxstack 8  IL_0000:  ldarg.2  IL_0001:  brfalse IL_0012     IL_0006:  ldarg.2  IL_0007:  ldarg.1  IL_0008:  callvirt instance void class DelegateScript/MyDelegate::Invoke(int32)  IL_000d:  br IL_001c     IL_0012:  ldstr "myDelegate is Null!!!"  IL_0017:  call void class [mscorlib]System.Console::WriteLine(string)  IL_001c:  ret  } // end of method DelegateScript::Print

分析这段代码，我们可以发现在IL_0008这行，编译器为我们调用了DelegateScript/MyDelegate::Invoke(int32)方法。那么我们是否可以显式的调用md的Invoke方法呢？答案是Yes。所以，Print方法完全可以改成如下的定义：

void Print(int value, MyDelegate md) {  if(md != null)  {    md.Invoke(value);  }  else  {    Debug.Log("myDelegate is Null!!!");  } } 

而一旦调用了委托实例的Invoke方法，那么之前在构造委托实例时被赋值的字段_target和_methodPtr在此时便派上了用场，它们会为Invoke方法提供对象和方法信息，使得Invoke能够在指定的对象上调用包装好的回调方法。OK,本节讨论了编译器如何在幕后为我们生成委托类、委托实例的内部结构以及如何利用委托实例的Invoke方法来调用一个回调函数，那么我们接下来继续来讨论一下如何使用委托来回调多个方法。

using UnityEngine; using System; using System.Collections; public class DelegateScript : MonoBehaviour {          delegate void MyDelegate(int num);        void Start ()        {  //创建3个MyDelegate委托类的实例   MyDelegate myDelegate1 = new MyDelegate(this.PrintNum);  MyDelegate myDelegate2 = new MyDelegate(this.PrintDoubleNum);  MyDelegate myDelegate3 = new MyDelegate(this.PrintTripleNum);  MyDelegate myDelegates = null;  //使用Delegate类的静态方法Combine   myDelegates = (MyDelegate)Delegate.Combine(myDelegates, myDelegate1);  myDelegates = (MyDelegate)Delegate.Combine(myDelegates, myDelegate2);  myDelegates = (MyDelegate)Delegate.Combine(myDelegates, myDelegate3);  //将myDelegates传入Print方法  this.Print(10, myDelegates);        }        void Print(int value, MyDelegate md)        {  if(md != null)  {         md(value);  }  else  {         Debug.Log("myDelegate is Null!!!");  }        }        void PrintNum(int num)        {  Debug.Log ("1 result Num: " + num);        }        void PrintDoubleNum(int num)        {  int result = num + num;  Debug.Log ("2 result num is : " + result);        }        void PrintTripleNum(int num)        {  int result = num + num + num;  Debug.Log ("3 result num is : " + result);        } } 

编译并且运行之后（将该脚本挂载在某个游戏物体上，运行Unity3D即可），可以看到Unity3D的调试窗口打印出了如下内容：

1 result Num: 10  2 result Num: 20  3 result Num: 30

换句话说，一个委托实例myDelegates中调用了三个回调方法PrintNum、PrintDoubleNum以及PrintTripleNum。下面，让我们来分析一下这段代码。我们首先构造了三个MyDelegate委托类的实例，并分别赋值给myDelegate1、myDelegate2、myDelegate3这三个变量。而之后的myDelegates初始化为null，即表明了此时没有要回调的方法，之后我们要用它来引用委托链，或者说是引用一些委托实例的集合，而这些实例中包装了要被回调的回调方法。那么应该如何将委托实例加入到委托链中呢？不错，前文提到过基础类库中的另一个委托类Delegate，它有一个公共静态方法Combine是专门来处理这种需求的，所以接下来我们就调用了Delegate.Combine方法将委托加入到委托链中。

myDelegates = (MyDelegate)Delegate.Combine(myDelegates, myDelegate1);                myDelegates = (MyDelegate)Delegate.Combine(myDelegates, myDelegate2);                myDelegates = (MyDelegate)Delegate.Combine(myDelegates, myDelegate3);

在第一行代码中，由于此时myDelegates是null，因而当Delegate.Combine方法发现要合并的是null和一个委托实例myDelegate1时，Delegate.Combine会直接返回myDelegate1的值，因而第一行代码执行完毕之后，myDelegates现在引用了myDelegate1所引用的委托实例。

myDelegates = (MyDelegate)Delegate.Remove(myDelegates, new MyDelegate(PrintDoubleNum));

当Delegate.Remove方法被调用时，它会从后向前扫描myDelegates所引用的委托实例中的委托数组，并且对比委托数组中的元素的_target字段和_methodPtr字段的值是否与第二个参数即新建的MyDelegate委托类的实例中的_target字段和_methodPtr字段的值匹配。如果匹配，且删除该元素之后，委托实例数组中只剩余一个元素，则直接返回该元素（委托实例）；如果删除该元素之后，委托实例数组中还有多个元素，那么就会创建一个新的委托实例，这个新创建的委托实例的_invocationList字段会引用一个由删除了目标元素之后剩余的元素所组成的委托实例数组，之后返回该委托实例的引用。当然，如果删除匹配实例之后，委托实例数组变为空，那么Remove就会返回null。需要注意的一点是，Remove方法每次仅仅移除一个匹配的委托实例，而不是删除所有和目标委托实例匹配的委托实例。

using UnityEngine; using System.Collections; public class MulticastScript : MonoBehaviour {  delegate void MultiDelegate();  MultiDelegate myMultiDelegate;  void Start ()  {   myMultiDelegate += PowerUp;   myMultiDelegate += TurnRed;   if(myMultiDelegate != null)   {    myMultiDelegate();   }  }  void PowerUp()  {   print ("Orb is powering up!");  }  void TurnRed()  {   renderer.material.color = Color.red;  } } 

好，我想到此我已经回答了本小节题目中所提出的那个问题：委托是如何调用多个方法的。但是为了要实现观察者模式甚至是我们自己的消息系统，还有一个大人物不得不介绍，那就是和委托关系密切的事件，那么下一篇博客就让我们走进委托和事件的世界中吧。