待机唤醒速度慢的跟踪及解决历程

　　这两天又接到一个Bug:大家都抱怨待机唤醒的速度太慢。首先我们假定应用程序没有这么大的功力来影响系统，主要从驱动方面入手。当然主要是要找出是哪个模块在待机和唤醒时比较慢，有以前编译PM模块的经验这个问题变得很简单：在PM调用SetDevicePower设置各驱动的电源状态时计算一下实际花了多少时间。经统计发现NLED和AUDIO驱动都比较慢，花费300ms以上，而且AUDIO驱动在进D3和D4状态时都各花了300ms。

　　经过与模块的维护者讨论发现AUDIO驱动在待机时会先暂停Media player，并等待300ms以确保Media player停止。而且比较致命的是它在进D3和D4时都做了这个事情，这个很好解决，先去掉延时，由此造成的问题用其它方法解决。

　　而NLED驱动因为进D4状态时LED可能还在闪烁，所以要给负责闪烁的线程一个信号，然后等待线程停止，以保证待机时LED是不亮的。因为负责闪烁的线程有好几次Sleep，所以进D4时使用了Sleep 300ms来保证进入D4状态时负责闪烁的线程已经停止。而这严重影响了系统的待机时间。现在将Sleep改成有限时间的WaitForSingleObject，这样进入D4时直接设置事件，就可以激活线程，从而不需要花费太多的时间来等待线程停止。