C#.NET：Invoke和BeginInvoke的一…

这偏博文中我会就今天所认识的Invoke和BeginInvoke进行一些“简易”理论说明，更多的例子我会就现在的手头项目不断补充

首先要知道2点：

1.Control的Invoke和BeginInvoke与委托的Invoke和BeginInvoke是2个概念，不能混淆

2.Control的Invoke和BeginInvoke，他们的形参是delegate，委托的方法是在Control的线程上执行(即UI线程)

补充一点：

相对来说，可以认为Invoke是同步的，而BeginInvoke是异步的

例子一：Invoke

说明：

在上面的代码中，执行顺序分别是A--->C--->B

A在UI线程上执行完毕后，就开始Invoke（同步），此时B并不执行，而是立即在UI线程上执行InvokeMethod()//即C代码段，当InvokeMethod方法执行完毕后，代码段C才在UI线程上执行

实例二：BeginInvoke

说明：

执行顺序：A--->B--->C(这个只是我测试获得的一种可能性，它并不是简单的顺序执行)，若真要解释的话我个人是这样子的理解的：

当A执行完毕后，BeginInvoke就将消息给封送到UI线程了，此时UI线程并不等待，而是继续往下执行，即下面的B代码段，当B代码段（或者说整个btn click事件处理完成后），再处理刚才封送过来的代码（即C代码段）；

个人觉得这个Invoke和BeginInvoke在执行顺序上有点类似于ASP.NET系统对象Server的Execute和Transfer

下面再举几个例子（就百度文档里面的一些资料做2次分析和个人见解）：

通过Thread来调用Invoke和BeginInvoke：

示例三：Thread调用Control的Invoke

说明：

这里的执行顺序为：

首先A被执行，然后断点执行invokThread.Start()的时候，代码段B和C被同时执行，当C执行完毕(不管此时B有没有执行完毕)，invokeThread封送消息给UI，然后自己等到(此时D当然也不会被执行)，待B执行完(或者说B所在事件的UI线程处理完所有消息后)，再处理刚invokeThread封送过来的消息(即E)，当E处理完，D再被执行，所以生命线图大致应该是这样的：

示例四：Thread调用Control的BeginInvoke

说明：

这里的执行顺序为:

首先A被执行，当处理完A后，B和C被同时执行，当C执行完成(此时不管B是否被处理完)，BeginInvoke将封送消息到UI线程，但此时它并不等待，而是继续往下执行D，当B执行完毕(或者说B所在的btnclick事件处理完所有东西后)，才再执行刚被封送过来的代码E，这里的话可能性比较多，就我个人的猜测我做下说明：

因为是BeginInvoke，所以被封送的消息一旦被封送到UI进程，那么就跟其原先所在的线程无关了，我认为要执行这部分被封送的东西，只跟UI线程有关（即当C和D都处理完，而此时B还没被处理完，那么E还是不被执行的；或者说当C处理完，而D没处理完，此时B又已经处理完了，那么E还是会被处理【即E的处理看B是否被处理完(或者说B所在的btnclick是否处理完所有代码)】），这里有点绕，或许我的猜测是错误的，有不同见解的朋友可以留言给我，看图可能比较好理解：

图画的不规范，见谅，visio不会用。。。。