功耗分析
极力推荐Android 开发大总结文章：欢迎收藏
程序员Android 力荐 ，Android 开发者需要的必备技能
本篇文章主要介绍 Android 开发中的部分知识点，通过阅读本篇文章，您将收获以下内容:
1.飞行模式底电流问题
2.正常待机功耗简介
3.最干净的待机电流波形
4.通过唤醒源理清正常待机问题
5.Audio Playback 功耗问题
6.Display 及多媒体功耗问题
7.通话功耗问题
1. 飞行模式底电流问题
系统睡眠的底电流是所有功耗问题的前置条件，此时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的值
2. 正常待机功耗简介
待机功耗很容易出现问题，并且很难理清，因为其涉及到APK 、Modem、Wifi、Other 这些不确定因素。
功耗问题处理原则：
1.先花时间把现象理清，到底在什么样的环境下复现。
2.多做几个实验，给出清晰的问题描述、问题复现条件、电流波形图。
3.提供关闭 modem 的log。
3. 最干净的待机电流波形
4. 通过唤醒源理清正常待机问题
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
5. Audio Playback 功耗问题
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唤醒。
6.Display 及多媒体功耗问题
手机所有亮屏的场景都是模块自身的耗电跟Display 部分耗电的叠加，所以Display 的功耗在整个系统中占比非常高。
Display 功耗 = 硬件+平台+内容
在 Kernel Log中搜索关键字 wake up by , 这个log是在 swapper进程 中打印出来的（代表当前CPU在运行idle task） ，并且后面可以看到 SO：的字样（通）
7. 通话电流功耗问题
通话模式的功耗跟正常模式的功耗区别
一般情况下
GSM 功耗< 3G-TD < 3G-W 功耗
飞行模式底电流 参考文档
标准模式功耗 参考文档
Audio PlayBack功耗 参考文档
通话底功耗 参考文档
Display 及多媒体功耗 参考文档
至此，本篇已结束，如有不对的地方，欢迎您的建议与指正。同时期待您的关注，感谢您的阅读，谢谢！
