zoukankan      html  css  js  c++  java
  • 待机唤醒速度慢的跟踪及解决历程

      这两天又接到一个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时直接设置事件,就可以激活线程,从而不需要花费太多的时间来等待线程停止。

  • 相关阅读:
    ndoejs解析req,伪造http请求
    ndoejs创建多重文件夹
    路径path的正则通配符-nodejs
    例题1.5 快速排序
    例题1.3 整数划分问题
    sdcf day4 qaq模拟赛总结
    P1168 中位数
    浅谈LCA
    sdcf day1 qwq比赛题解
    2019山东夏令营划水记
  • 原文地址:https://www.cnblogs.com/ceblog/p/1853744.html
Copyright © 2011-2022 走看看