Androidの消費電力過多時のロゴ分析
3712 ワード
最新では、Android携帯電話の消費電力が多すぎる原因を分析するためのtoolを書いています.pythonを使います.書きながら記録しましょう.
1.消費電力が多すぎる原因
消費電力が多すぎる原因は基本的に2つに分けることができます.一つはCPUが寝ていないこと.二つ目は、CPUが頻繁に起動されることである.もちろん、USBが挿入されていないことが前提で、画面が消えています.
1.1 CPUが頻繁に起動する場合
黒い画面の状態で、携帯電話に異常がなく、バックグラウンドにアプリをダウンロードしたり、音楽を再生したりするような行為がなければ、CPUは寝てしまいます(後文はそのまま深眠で代用します).また、あまり頻繁に起動されることはありません(起動はCPUが起動されることであり、明るい画面ではありません).ロゴを見ていると、テーブルが頻繁に目を覚ます(数秒に1回、さらに頻繁に)ことに気づいたら、それは正常ではないに違いない.
一般的には、起動時刻のlog付近で直接起動源を表示し、何が起動したのかをテーブルに位置決めします.modemには他のハードウェアがあるかもしれませんが、上層apkがalarmをいくつか設定している可能性があります.
1.2 CPUが寝ていない
CPUが寝ていない場合は、一般的にwakelockがあるからです.上層apkのwakelockかもしれないし、kernelの一部のdriverが持っているwakelockかもしれない.
kernelのwakelockのいくつかの情報はcat/d/wakeup_を通じてsources表示.active_sinceの値が特に大きいのは、疑いの対象です.
上層部のwakelockもあり、/sys/power/wake_を見ることができます.lockノード.画面が明るくなると、ここには常にPowerManagerServicesがあります.Display.
2.TOOLの実現
TOOLの現在の考え方はlogcat logとevent logを分析することである.
2.1 USBが挿入されていない時間帯を見つける
event logでUSB(パソコンUSBまたはadapter)が挿入されていない時間帯を見つけます.USBを挿入して充電すると、状況が複雑になり、消費電力を分析するのに適していないからです.
event logの意味はブログを参照してください.http://gityuan.com/2016/05/15/event-log/
その中にusbが挿入されているかどうかの判断はbattery_によるstatus
2723
battery_status
status,health,present,plugged,technology
例:
2.2 USB(none plug)が挿入されていない期間ごとの消費電力を計算する
まず、電池の電力量を読み取る必要があります.同様にevent logから読み出します.
2722
battery_level
level, voltage, temperature
例:
USbが挿入されていない期間(t 1,t 2)については、t 1以降の第1の電力量情報の時点t 11と、t 2以前の最後の電力量情報の時点t 22とを見つけ、t 11,t 22間の消費電力が要求を満たすか否かを算出する必要がある.しかし、実際に実現する過程で、この間に電力情報がなく、1つの電力情報しかない場合を含む特殊な状況があり、このようにしても、まず大雑把に処理するしかなく、電力情報がないと考え、その後、この時間を分析しない.
2.3消費電力の多いnone plug期間におけるscreen off期間の再分析を探し出す
前に、さらに分析する必要があるnone plug期間が見つかりました.次はこの時間帯の分析です.
まず、screenの情報を読み出します.やはりevent logから読み込みます.
1つ1つの黒い画面の時間帯を見つけて、次にそれぞれの黒い画面の時間帯にCPUの睡眠状況を分析する必要があります.後ろには黒い画面の時間帯しか書かれていません.
2.4黒い画面の時間帯に深い眠りがあるかどうかを判断する
ぐっすり眠るロゴはロゴログで検索できます.ロゴは次のとおりです.
もし黒い画面の時間帯に寝ていなければ、この時間が十分に長いならば、それはなぜ寝ていないのか、つまりwakelockを見ることです.
黒い画面の時間帯に寝ていたら、後ろの消費電力はほとんど頻繁に目が覚めることが多い.後でモーニングコールソースを見ます.
2.5頻繁に起動するブラックスクリーンの時間帯に対する起動源の検索
現在の考えは,ソースを起動するかlogcat logのkernel logから直接読み出すかである.
また、dumpsys batterystatsでの到の+wake_reasonは読み取りノード:/sys/kernel/wakeup_reasons/last_resume_reason.
2.6ぐっすり眠れないwakelockを見つける
本来なら/d/wakeup_を読み込むべきですsourcesは各wakelockの状況を見てみましょう.しかし、このノードはroot権限のみが読み取れることを考慮します.dumpsys batterystatsのkernel wakelock情報を直接読み込むしかありません.この情報には主にreset以来のロック回数と時間が含まれている.後でwakelockを分析するために専門的な文を書きます.
1.消費電力が多すぎる原因
消費電力が多すぎる原因は基本的に2つに分けることができます.一つはCPUが寝ていないこと.二つ目は、CPUが頻繁に起動されることである.もちろん、USBが挿入されていないことが前提で、画面が消えています.
1.1 CPUが頻繁に起動する場合
黒い画面の状態で、携帯電話に異常がなく、バックグラウンドにアプリをダウンロードしたり、音楽を再生したりするような行為がなければ、CPUは寝てしまいます(後文はそのまま深眠で代用します).また、あまり頻繁に起動されることはありません(起動はCPUが起動されることであり、明るい画面ではありません).ロゴを見ていると、テーブルが頻繁に目を覚ます(数秒に1回、さらに頻繁に)ことに気づいたら、それは正常ではないに違いない.
一般的には、起動時刻のlog付近で直接起動源を表示し、何が起動したのかをテーブルに位置決めします.modemには他のハードウェアがあるかもしれませんが、上層apkがalarmをいくつか設定している可能性があります.
1.2 CPUが寝ていない
CPUが寝ていない場合は、一般的にwakelockがあるからです.上層apkのwakelockかもしれないし、kernelの一部のdriverが持っているwakelockかもしれない.
kernelのwakelockのいくつかの情報はcat/d/wakeup_を通じてsources表示.active_sinceの値が特に大きいのは、疑いの対象です.
上層部のwakelockもあり、/sys/power/wake_を見ることができます.lockノード.画面が明るくなると、ここには常にPowerManagerServicesがあります.Display.
2.TOOLの実現
TOOLの現在の考え方はlogcat logとevent logを分析することである.
2.1 USBが挿入されていない時間帯を見つける
event logでUSB(パソコンUSBまたはadapter)が挿入されていない時間帯を見つけます.USBを挿入して充電すると、状況が複雑になり、消費電力を分析するのに適していないからです.
event logの意味はブログを参照してください.http://gityuan.com/2016/05/15/event-log/
その中にusbが挿入されているかどうかの判断はbattery_によるstatus
2723
battery_status
status,health,present,plugged,technology
例:
04-26 16:12:25.273 2875 17395 I battery_status: [4,2,1,1,Li-ion] //1, adapter
04-26 16:12:25.619 2875 4146 I battery_status: [2,2,1,1,Li-ion]
04-26 16:13:28.612 2875 17396 I battery_status: [3,2,1,1,Li-ion]
04-26 16:13:28.616 2875 17396 I battery_status: [3,2,1,0,Li-ion] //0, usb
04-26 16:55:34.546 2875 2911 I battery_status: [4,2,1,1,Li-ion] //1, adapter , 2.2 USB(none plug)が挿入されていない期間ごとの消費電力を計算する
まず、電池の電力量を読み取る必要があります.同様にevent logから読み出します.
2722
battery_level
level, voltage, temperature
例:
04-26 12:34:06.584 2875 4412 I battery_level: [65,3945,357] // 。 65%
04-26 12:43:52.743 2875 17395 I battery_level: [64,3925,352]
04-26 12:50:53.867 2875 31204 I battery_level: [63,3920,355]
USbが挿入されていない期間(t 1,t 2)については、t 1以降の第1の電力量情報の時点t 11と、t 2以前の最後の電力量情報の時点t 22とを見つけ、t 11,t 22間の消費電力が要求を満たすか否かを算出する必要がある.しかし、実際に実現する過程で、この間に電力情報がなく、1つの電力情報しかない場合を含む特殊な状況があり、このようにしても、まず大雑把に処理するしかなく、電力情報がないと考え、その後、この時間を分析しない.
2.3消費電力の多いnone plug期間におけるscreen off期間の再分析を探し出す
前に、さらに分析する必要があるnone plug期間が見つかりました.次はこの時間帯の分析です.
まず、screenの情報を読み出します.やはりevent logから読み込みます.
04-26 13:24:59.173 2875 2875 I screen_toggled: 1 //
04-26 13:24:59.398 2875 2957 I screen_toggled: 1
04-26 13:24:59.401 3610 3610 I screen_toggled: 2 //
04-26 13:25:07.070 2875 2875 I screen_toggled: 0 //
04-26 13:29:30.780 2875 2875 I screen_toggled: 1 // ，
04-26 13:29:30.884 2875 2957 I screen_toggled: 11つ1つの黒い画面の時間帯を見つけて、次にそれぞれの黒い画面の時間帯にCPUの睡眠状況を分析する必要があります.後ろには黒い画面の時間帯しか書かれていません.
2.4黒い画面の時間帯に深い眠りがあるかどうかを判断する
ぐっすり眠るロゴはロゴログで検索できます.ロゴは次のとおりです.
04-26 13:48:57.706 2958 2958 W KERNEL : [149941.121406] (CPU:0-pid:2958:system_server)Suspending console(s) (use no_console_suspend to debug)もし黒い画面の時間帯に寝ていなければ、この時間が十分に長いならば、それはなぜ寝ていないのか、つまりwakelockを見ることです.
黒い画面の時間帯に寝ていたら、後ろの消費電力はほとんど頻繁に目が覚めることが多い.後でモーニングコールソースを見ます.
2.5頻繁に起動するブラックスクリーンの時間帯に対する起動源の検索
現在の考えは,ソースを起動するかlogcat logのkernel logから直接読み出すかである.
また、dumpsys batterystatsでの到の+wake_reasonは読み取りノード:/sys/kernel/wakeup_reasons/last_resume_reason.
2.6ぐっすり眠れないwakelockを見つける
本来なら/d/wakeup_を読み込むべきですsourcesは各wakelockの状況を見てみましょう.しかし、このノードはroot権限のみが読み取れることを考慮します.dumpsys batterystatsのkernel wakelock情報を直接読み込むしかありません.この情報には主にreset以来のロック回数と時間が含まれている.後でwakelockを分析するために専門的な文を書きます.