極力推薦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 及多媒體功耗 參考文檔
至此，本篇已結束，如有不對的地方，歡迎您的建議與指正。同時期待您的關注，感謝您的閱讀，謝謝！
