极力推荐Android 开发大总结文章：欢迎收藏
程序员Android 力荐 ，Android 开发者需要的必备技能
本篇文章主要介绍 Android 开发中的部分知识点，通过阅读本篇文章，您将收获以下内容:
1. 飞行模式底电流问题1.飞行模式底电流问题
2.正常待机功耗简介
3.最干净的待机电流波形
4.通过唤醒源理清正常待机问题
5.Audio Playback 功耗问题
6.Display 及多媒体功耗问题
7.通话功耗问题
系统睡眠的底电流是所有功耗问题的前置条件，此时wifi 、Bluetooth、Location、Radio 都处于关闭状态。
系统睡眠的条件
查看CPU是否进入suspend 状态， suspend 确切的说是 MCU （ARM）的suspend , 也是CPU 进入WFI（Wait For Interrupt）状态，CPU 进入WFI后，整个系统就依靠一颗 SCP：SPM（System Power Manager） 来控制 睡眠/唤醒 的流程
灭屏到CPU 进入suspend的流程
判断系统是否进入suspend
在kernel log中搜索关键字 Chip_pm_begin 或者 suspend entry
查看SPM（System Power Manager）状态
在 kernel log 中搜索关键字 wake up by, 在 kernel Log中查看R13寄存器跟debug_flag的值
待机功耗很容易出现问题，并且很难理清，因为其涉及到APK 、Modem、Wifi、Other 这些不确定因素。
功耗问题处理原则：
1.先花时间把现象理清，到底在什么样的环境下复现。
2.多做几个实验，给出清晰的问题描述、问题复现条件、电流波形图。
3.提供关闭 modem 的log。
1. 其他唤醒源分析
kernel Log收缩关键字 wakeup by, wakeup by xxxx ,其中 xxxx 就是唤醒源。
2. APK 唤醒源分析
APK 唤醒系统是通过设置 type 0 和type 2的alarm 来唤醒系统，这两种alarm 会设置到RTC寄存器中，而RTC Module 其实是在PMIC 里面，因此APK 唤醒实际上是PMIC的EINT 唤醒。
RTC 唤醒sys_log中搜索关键字 AlarmManager: sending alarm Alarm，查看 type 0 和 type 2 的应用有哪些。
如果log没有开启，请使用adb shell dumpsys alarm log on
Audio playback 时候MTK 低端平台没有专门的audio DSP（Heilo X20除外），故无法在suspend 状态下完成audio playback，故需要CPU 做这件事情。
通话的时候之所以可以睡眠，是疑问modem 充当了dsp的角色。
deep idle 状态
Deep idle 实际上系统还是Active 状态，因此CPU 需要快速响应系统请求调度，因此 GPT唤醒源 是Deep idle 的主要唤醒源。
在 Kernel Log中搜索关键字 wake up by , 这个log是在 swapper进程 中打印出来的（代表当前CPU在运行idle task） ，并且后面可以看到 DP：的字样。
MP3 播放时进入deep idle 状态（20mA）举例
区分suspend 与deep Idle
- suspend 是跑在
suspend workqueue中，因此log的进程主体是kwork - deep idle 是跑在
idle task中，因此log的进程主体是swapper - suspend 默认不会被
GPT唤醒。
手机所有亮屏的场景都是模块自身的耗电跟Display 部分耗电的叠加，所以Display 的功耗在整个系统中占比非常高。Display 功耗 = 硬件+平台+内容
在 Kernel Log中搜索关键字 wake up by , 这个log是在 swapper进程 中打印出来的（代表当前CPU在运行idle task） ，并且后面可以看到 SO：的字样（通）
通话模式的功耗跟正常模式的功耗区别
一般情况下
GSM 功耗< 3G-TD < 3G-W 功耗
飞行模式底电流 参考文档
标准模式功耗 参考文档
Audio PlayBack功耗 参考文档
通话底功耗 参考文档
Display 及多媒体功耗 参考文档
至此，本篇已结束，如有不对的地方，欢迎您的建议与指正。同时期待您的关注，感谢您的阅读，谢谢！
