SDK中三个Timer的区别

最近在做一个小游戏,由于里面要用到Timer,所在特地在SDK中彻底翻了一遍,发现在SDK中有三个Timer,
System.Threading.Timer
System.Timers.Timer
System.Windows.Forms.Timer

然后就到处去搜些资料来对比下,看哪个东西更适合我(

性能好点的,使用方便的),

后来发现微软上的一遍文章,http://msdn.microsoft.com/msdnmag/issues/04/02/timersinnet/default.aspx

总结这篇文章描述：

1。System.Windows.Forms.Timer ， 该 Timer 必须在 Winform 程序中使用，依赖于某个窗体。 因为该 Timer的时间由 系统的Timer 消息发送到窗口，然后由窗口的 主 UI 线程进行处理。 由于窗口的消息又先后顺序，并且处理的时候也是顺序同步的，因此当窗体的主ui线程正在执行其他的消息时， Timer的时间就会被丢弃。 由于该 Timer时间的处理代码直接运行在窗体主UI 线程中，可以直接访问窗体上的控件。

2。System.Timers.Timer ， 该Timer 与 System.Windows.Forms.Timer 原理机制比较相近，但是该Timer 不依赖于winform，可以是用在Component 或者一般的class里。 并且该Timer的事件默认执行在一个线程池中的工作线程（worker thread）中。 如果我们需要让代码执行在某个特定线程中（比如窗体的主UI线程），需要通过设置Timer的SynchronizingObject 属性。 同时，由于这个Timer 会将所有的时间触发 event都 queue在一个队列中， 不会像 Windows.Forms.Timer 那样一但主消息线程忙，就会丢失事件。

3。System.Threading.Timer ， 这个Timer 总的来讲是对具体应用环境以来最小的，所以可以在任何多线程环境中是用的Timer。 时间处理代码也是在线程池中的线程上执行。 但是由于灵活性，它就没有提供很多现有的比如 直接访问 窗体控间，或者 通过设置 SynchronizingObject 属性 来指定执行线程。 在对线程环境中我们需要自己编码来提供代码的同步，互斥等安全性。

三个Timer 没有什么特别的性能上的优劣，主要是根据他们的特点和局限根据程序需要适当的是用他们。

其实微软也挺怪的,一样的东西弄个好几个,就拿来Catch来说吧,也弄了两个一样的,真不知道是怎么想的.


看来用哪个都一样啦,不过出于方便性,我还是选择了System.Windows.Forms.Timer

BTW,最近就在用C#+MD9做一个连连看的游戏,基本上快完成了,下次完了,就把发在数据结构组里,因为我一直觉得连连看还是比较能用来训练算法的.