今天在社区上又看到了一篇在WINDOWS MOBILE上TIMER不准确的问题。这种篇子很多所以有感而发写博客。
先明确两个概念，WM下有两个TIMER，一个是窗体TIMER，一个是线程TIMER。二，其实TIMER和框架没有关系不管是MFC，还是WIN32亦或是NET C#他最终的实现都是靠原生的WIN32的机制完成的。我们下面呢用C#为例讲解。
窗体TIMER，在System.Windows.Forms命名空间下，他的最大好处是其实处理（回调）函数是运行在UI进程，怎么看函数的运行进程呢，当然你可以看线程的ID。但是在。NET下不太需要这样做。原因很简单，每个CONTROL都有一个公共的属性InvokeRequire。如果函数运行在CONTROL创建运行的进程中InvokeRequire是FALSE。那么很好，因为FORM也是CONTROL的子类，所以在FORM当中创建一个TIMER观察这个TIMER在的TICK也就是回调函数当中FORM的InvokeRequire属性就好了。下面给出一下示例代码。
Class testForm:Form
{
System.Windows.Forms.Timer timer=new System.Windows.Forms.Timer();
testForm()
{
timer.tick=new EventHandler(Tick);
}
Tick(Object sender,EventArgs e)
{
MessageBox.Show(this.InvokeRequire.ToString());
}
}
如果在MAIN当中testForm.ShowDialog的话那么就可以看到这个InvokeRequire是FALSE的
那么就能解释了为什么窗体TIMER不准确的原因了。因为他运行在他创建的线程。他是通过WINDOWS的线程泵（messagepump）的原理来保证运行在运行进程的。到时不见得可以触发。
上面讲座了窗体的TIMER，我们再来看线程的TIMER。如果做上述的实验的话可以发现他运行在自己的线程，触发时间较窗体的TIMER准确。但是如果必须要做UI进程进行动作，因为非UI进程不能更改控制的要素。
所以一般在C#下会调用INVOKE函数来修改UI。INVOKE的实现机制是怎么样的呢，看MSDN当中写得很清楚MESSAGEPUMG。呵呵，所以可以这样认为线程TIMER+INVOKE的话和窗体TIMER没有本质区别。
最后说一下总结
首先这两种TIMER都不能到CPU时钟级别的精确。
二线程TIMER相对来说准确。但是其回调运行在单独的线程。
三窗体TIMER不能保证准确尤其是其创建的线程繁忙的时候。
四窗体TIMER的机制就是线程TIMER+MESSAGEPUMP