和您一起终身学习,这里是程序员Android
本篇文章主要介绍 Android 开发中的部分知识点,通过阅读本篇文章,您将收获以下内容:一、飞行模式底电流问题
二、正常待机功耗简介
三、最干净的待机电流波形
四、通过唤醒源理清正常待机问题
五、Audio Playback 功耗问题
六、Display 及多媒体功耗问题
七、通话功耗问题
一、飞行模式底电流问题
飞行模式底电流正常是所有功耗问题的前置条件,此时wifi 、Bluetooth、Location、Radio 都处于关闭状态。
1.系统睡眠的条件
查看CPU是否进入suspend状态, suspend确切的说是 MCU (ARM)的suspend, 也是CPU 进入WFI(Wait For Interrupt)状态,CPU 进入WFI后,整个系统就依靠一颗 SCP:SPM(System Power Manager) 来控制 睡眠/唤醒 的流程
2.灭屏到CPU 进入suspend的流程
3.判断系统是否进入suspend的方法
在kernel log中搜索关键字 Chip_pm_begin 或者 suspend entry
4.查看SPM(System Power Manager)状态
1.在 kernel log 中搜索关键字 wake up by, 可以查看唤醒源的情况,
2.在kernel log中查看R13寄存器跟debug_flag的值,如果后面值不是ff结尾,此时系统功耗可能会存在异常,需要查看分析。
二、 正常待机功耗简介
待机功耗很容易出现问题,并且很难理清,因为其涉及到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 Idlesuspend 是跑在 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 功耗
至此,本篇已结束。转载网络的文章,小编觉得很优秀,欢迎点击阅读原文,支持原创作者,如有侵权,恳请联系小编删除,欢迎您的建议与指正。同时期待您的关注,感谢您的阅读,谢谢!