对于手机灭屏下的表现，我们可以从图中得到很多耗电相关的信息，关键信息摘录如下：
- CPU running：用于表征系统是否有进入休眠状态，并记录唤醒源信息。休眠时间占比越短，耗电会越差。
- Userspace wakelock：用于表征当前是否存在用户空间申请的wakelock，并且这里会展示系统被唤醒后首次申请的wakelock。值得注意的是，用户空间申请的wakelock的总时长和首次申请的wakelock并不存在必然的联系，如果要进一步确认总时长分别是哪些wakelock引起的，可以执行dumpsys batterystats --enable full-history命令后得到所有wakelock的过程记录功能，从而找到答案。
- Long wakelocks：表征是否存在长时间持有的wakelock。当持有时间超过1分钟时，则会被标记，此类的情况的出现会对灭屏功耗造成较大影响。
- Kernel only uptime：当所有用户态的wakelock都释放后，如果kernel未休眠，那么这部分的时间会被记录到这个字段。
- Screen：表征当前的亮灭屏状态。
- Doze：表征android doze省电模式的状态。值可为off foze、light doze、full doze这几种，当用户一段时间内没有使用手机且满足进入Doze的条件时，会限制应用的后台活动，以达到减少功耗的目的。具体限制的动作比如暂停网络访问、忽略应用持有的WakeLock、不再进行wifi扫描、不允许sync adapters和JobScheduler运行等。不过为了保证基础功能与用户体验，系统进程、核心应用、前台服务进程并不会受到限制。
- 其它：gps状态、通话状态、联网状态与类型、wifi状态等，都与灭屏表现息息相关，篇幅有限，不详细阐述。
上文batterystats模块中”cpu running“指标阐述的是休眠与否这个状态。然而，linux系统可分为三种状态：工作态、空闲态、休眠态。系统工作态与空闲态这两种状态下的运行表现，对灭屏功耗同样起着至关重要的影响。
如上图所示，灭屏下系统处于唤醒状态时（持有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状态描述如下：
关键函数示例如下：
