Winform消息与并行的形象比喻

有一次我给同事讲述跨线程调用时使用了高速行驶的并行列车来比喻，感觉比较形象。

线程列车

多线程就像多个并行的列车，每个线程在各自的轨道上不断向前行驶。主界面所在的线程称为UI线程，也叫主线程，主线程依靠消息驱动，可以将主线程的列车每节车厢想象为一个消息，每次转换并处理一个消息，处理过程中如果有新的消息不会马上处理而是放入一个消息队列，等下一轮处理。

例如我在屏幕上点击一个按钮，操作系统将鼠标的按下抬起等消息推送到消息队列中。程序主线程的下一轮开始转换这个消息然后处理这个消息，发送给指定窗口。假设我们在点击消息处理方法中进行一些界面更新，并调用了Invalidate，此时只是发出了消息，然后继续执行后续代码，当点击消息处理完毕后，才会从消息队列获取下一个消息处理。

对于跨线程操作的Invoke，可以这么理解。就是并行列车在高速行驶中如果直接调用另一个列车上的方法是非常危险的，我们坐车的时候售票员总是提醒我们不要把头和手伸出窗外是一个道理。所以，假如我们在一个主线程之外的线程列车上想要UI线程去执行一个方法，此时我们需要将方法包装成委托，然后通过Control.Invoke给主线程发送消息，主线程会在下一次消息处理时处理我们的消息，由被调用的Control在UI线程执行我们的方法。

如果我们在Invoke后，还需要处理返回值，那么我们自己所在的列车就不能继续开了，要停下列车，等主线程的列车处理完我们的方法，返回结果，并通过消息发送回来，我们收到返回的消息时，才继续开动列车处理后续消息。也就是使用Invoke的返回的WaitHandle的WaitOne方法等待了。

需要理解Windows的消息驱动机制。我们知道任意时刻执行的代码一定是处于一个消息中，或者是空闲事件消息中。消息也是跨线程调用的基本机制。

Control.BeginInvoke是从线程池启动一个线程执行，相对主线程是异步的。Control.Invoke则是在其他线程中回到UI线程执行。但这两种方式都不是推荐的最优做法，推荐用TPL模式，就是使用Task来进行异步。需要回到主线程时用AsyncOperation，原理是一样的还是发消息，只是AsyncOperation会发送给一个必定存在的句柄，避免线程安全问题。

句柄问题

另一个很多人不明白的问题就是窗口句柄何时创建，以及OnLoad的时机。其实，Winform程序是对本地代码的包装而已，底层还是过程式语言的API调用。过程语言通过句柄来唯一标识所有的本地资源，所有的方法都需要传入句柄 。而我们创建的控件类其实并不是真正的可见的类，翻看C++版本的代码就可以知道，其实还是调用API来CreateWindow，此时传入的类名才是API中所指的类名，此时传入的参数在Control里使用了CreateParam结构体和CreateParam方法来实现。

简单的说吧，当我们创建一个Button时，只是调用了Button的构造方法而已，并没有在屏幕上可见，当我们调用Parent的AddControl时，才会去创建句柄，此时才会触发控件的OnCreateControl，如果控件是一个UserControl才会触发OnLoad事件。Control的OnCreateControl和UserControl的OnLoad是同一个时机发生的。只有创建了句柄才会在屏幕上绘制出来，当父窗体隐藏时，所有子控件的句柄会销毁，因为不用绘制了，而再次Show时，会重新创建句柄。