我的手机灭屏了为什么还在耗电呢,为什么手机息屏也会耗电( 二 ) _我的手机灭屏了为什么还在耗

文章插图
如上图所示，灭屏下系统处于唤醒状态时（持有wakelock未休眠或者睡眠后被唤醒），如果cpu没有被关闭，那么处理deadline、real time、fair调度类上的任务时认为cpu处于工作态。为了改善灭屏工作态的功耗，往往通过减少任务量、降低硬件功耗两方面来制定策略，比如冻结与清理非核心的任务、job策略优化、降低cpu的工作频率、关闭能效差的cpu等。此时batterystats模块又充分展示出”对耗电工作的主动与积极性“，对灭屏下的各个应用的cpu使用情况做了详细的统计，这对灭屏耗电分析与调试、优化效果呈现等方面起到一定的辅助作用，结果示例如下：

文章插图
当deadline、realtime、fair调度类上无任务需要处理时，kernel则会执行idle调度类上的任务，该任务的职责是走cpu idle流程以节省功耗。另外，可以选择不同的idle governor比如menu governor、ladder governor、平台定制的governor等以满足不同的应用场景。为了快速便捷的了解各cpu的idle执行情况，可通过idlestat开源工具（源码参考网址https://github.com/scheduler-tools/idlestat）来分析、统计各个cpu在每个idle c-state下的停留时间、进入次数等信息，也可通过busybox powertop工具（源码参考网址https://busybox.net/）来分析cpu的irq、timer表现以找出top类的idle唤醒源。
另外，当cpu的idle级别达到某个级别以上（C1、C2 ….），或者处于idle的cpu数量达到某个条件，亦或者其它特殊的条件（不同平台表现不一）得到满足时，SOC往往会进入深度定制的省电模式以将idle状态下的耗电降低到极致。其中，这里提及的特殊条件的满足，依赖的条件往往比较多，各个设备模块往往充分利用内核提供的runtime pm框架，在合适的时机尽可能的释放相应的资源以提供必要条件。runtime pm状态描述如下：

文章插图
关键函数示例如下：

文章插图
以i2c控制器为例，在不需要传输数据的时候及时释放clock，代码示例如下：

文章插图
如上所述，灭屏情况下的kernel休眠态、工作态、空闲态表现对灭屏功耗均起到关键的影响，因此，策略设计不合理、运行逻辑出现异常，都会造成灭屏耗电不理想。
回到前面提到的几个维度，kernel是否有触发休眠动作、是否频繁退出休眠状态、触发休眠后是否执行成功等关键信息可以在batterystats模块统计的信息中找到线索。然而，平台级别的休眠状态、外围器件的休眠状态，由于终端设备之间的差异性比较大，batterystas的覆盖还不够。
对于整机硬件系统，除了cpu之外， modem子系统、sensor子系统、audio子系统、wireless子系统往往也不可或缺，这些子系统对灭屏耗电影响也很大。
Modem子系统：负责处理与基站相关的通信业务，承担着电话、短信、上网等业务。造成该子系统休眠差的原因有多种，比如业务联网频繁、小区切换频繁、无服务搜网、RRC连接不释放、弱信号重传多等。Sensor子系统：负责传感器业务需求、基础功能的支撑（比如抬手检测、计步检测、开合检测等），出于耗电的考虑，越来越多的传感器算法会转移到sensor子系统来实现。应用调用sensor是否合理、sensor的采样频率、省电模式的配置、算法实现的复杂度，是影响sensor子系统休眠与耗电表现的重要因素。Audio子系统：处理音频相关业务，比如音频播放、录音、特效算法等。三方应用的不合理使用（例如后台持续播放、录音行为）往往是造成audio子系统异常耗电的主要原因。Wireless子系统：该子系统往往集成了wifi、bt、gps、fm等无线功能模块，相应模块的作业状态直接影响该子系统的耗电表现。随着业务需求的发展，手机终端的集成度越来越高，功能也越来越复杂，无论是硬件、底层设备驱动还是应用软件，在设计与实现时都需要充分考虑耗电影响，以本文提及的灭屏为例，围绕AP（工作态、空闲态、休眠态）以及特殊业务子系统进行硬件功耗优化、软件算法优化、耗电策略改善等，提升用户灭屏耗电体验。