Android PowerManager
3527 ワード
Android電源管理
まずAndroid携帯電話には2つのプロセッサがあり、1つはApplication Processor(AP)、1つはBaseband Processor(BP)です.APはARMアーキテクチャのプロセッサであり、Linux+Androidシステムを実行するために使用される.BPはリアルタイムオペレーティングシステム(RTOS)を実行するために使用され、通信プロトコルスタックはBPのRTOS上で実行される.
非通話時間ではBPの消費電力は基本的に5 mA程度であるが,APは非スリープ状態であれば少なくとも50 mA以上であり,グラフィック演算を行う場合にはさらに高くなる.またLCD動作時の消費電力は100 mA程度、WIFIも100 mA程度.一般的に携帯電話が待機している場合、AP、LCD、WIFIはいずれもスリープ状態になり、Androidではアプリケーションのコードも実行を停止します.
Androidは、アプリケーション内のキーコードの正確な実行を確保するため、Wake LockのAPIを提供し、アプリケーションがコードを通じてAPがスリープ状態に入ることを阻止する権限を持つようにした.しかし、Androidデザイナーの意図を理解せずにWake Lock APIを悪用し、自身のプログラムがバックグラウンドで正常に動作するようにAPがスリープ状態に入るのを長時間阻止すれば、待機バッテリーキラーになる.例えば、この間のアプリケーション、例えば今でもこのことをしているアプリケーション.
まず,APが休眠するとメッセージプッシュが届かないことを全く心配する必要はない.通信プロトコルスタックはBPで動作し、パケットを受信すると、BPはAPを起動し、起動時間はAPがコードを実行して受信したパケットの処理プロセスを完了するのに十分である.その他、ConnectivityイベントがトリガーされるとAPも起動します.唯一の問題は、プログラムがサーバにハートビートパケットを送信する論理をどのように実行するかです.APで心拍数を計ることはできませんAndroidが提供するAlarm Managerは、心拍数などの周期的な問題を解決します.AlarmはBPタイミング(または他の石英時計付きチップで、よくわかりませんが、決してAPではありません)であるべきで、トリガ時にAP実行プログラムコードを起動します.ではWake Lock APIは何の役に立つのでしょうか?例えば、ハートビートパケットが要求から応答に至るまで、例えば断線再接続がこれらの重要な論理の実行プロセスに再ログインするには、Wake Lockが保護する必要があります.重要な論理が成功すれば、Wake Lockをすぐに解放する必要があります.2回のハートビートリクエストは5~10分間隔で、ほとんど消費電力がかかりません.ネットワークが不安定で、頻繁に断線して再接続しない限り、その場合の方法は多くありません.
PowerManagerについて
きほんしようてつづき
1.PowerManager pm = (PowerManager) getSystemService(Context.POWER_SERVICE);
2.次に、PowerManagerのnewWakeLock(int flags,String tag)を使用してWakeLockインスタンスを生成します.int FlagsはどのWakeLockを取得するかを示し、異なるLockはcpu、スクリーン、キーボードランプに異なる影響を与える.
3.WakeLockインスタンスを取得した後、acquire()を使用して対応するロックを取得し、他のビジネスロジックの操作を行い、release()を使用してリリースします(リリースは必須).
常用FLAG:
PARTIAL_WAKE_LOCK:CPUの動作を維持し、画面とキーボードランプがオフになっている可能性があります.
SCREEN_DIM_WAKE_LOCK:CPUの運転を維持し、画面表示を維持できるが灰色である可能性があり、キーボードランプの消灯を許可する
SCREEN_BRIGHT_WAKE_LOCK:CPUの運転を保持し、画面のハイライト表示を保持し、キーボードランプのオフを許可する
FULL_WAKE_LOCK:CPUの運転を保持し、画面のハイライト表示を保持し、キーボードランプも明るさを保持する
アクセス権:
またWakeLockの設定はActivityレベルであり、Applicationアプリケーション全体ではありません.
ActivityのonResumeメソッドでWakeLockを操作し、onPauseメソッドで解放できます.
android休眠の穴
1.サーバにポーリングするコードは実行されません.
TimerとTimerTaskを利用して,サーバに対するタイミングのポーリングを設定するが,マシンが一定時間後にポーリングが行われなくなることが分かった.長い間調べていたが、休眠によるものだった.後で解決する方法は,システムのAlarmServiceを用いてポーリングを実行することである.システムは機械をスリープさせ、電力を節約するが、完全に電源を切るわけではないため、システムの一部の優先度の高いプログラムはまだ実行されている.例えば、目覚まし時計は、AlarmServiceを利用して自分のプログラムをタイミングよく起動し、cpuを起動させ、実行してからスリープさせることができる.
2.バックグラウンドの長い接続が切断されました.
最近の問題.Socket長接続でQQのようなチャット機能を実現したところ、画面が消灯してからSocketが切断されたことが分かった.画面が开く时に再接続する必要がありますが、Logを见るたびにネットがリンクされていることに気づきました.后でcpuが休眠してリンクが切れていることに気づきました.データ线を差し込んでlogを见ると、ネットのcpuが回复し、ネットを见ると确かにリンクされています.最後にPARTIAL_を使いましたWAKE_LOCK、CPUをスリープさせない.
3.デバッグ中はスリープしません.2をデバッグしたとき、Socketが切れることもあるし、切れないこともあることに気づきました.私はデータ線を差し込んでデバッグしたり、データ線を抜いたりしていたので、Androidのスリープ状態は違いました.また、机械によって异なる表现があります.例えば、ある机械は、データ线を差し込むと充电します.ある机械はできません.ある机械の设置の充电の时、スクリーンが暗くなりません.実はこの休眠メカニズムを理解して、すべてが言いやすいです.
AlarmManagerについて
AlarmManagerはAndroidがユーザーに提供するもので、スリープモードでもハートビートバッグ、断線再接続など、いくつかの動作を実行できるメカニズムです.注意すべきは、AlarmManagerのライフサイクルは、android 3.1以前に、手動cancelで登録されていない限り、AlarmManagerに登録されているクロックが有効であることです.1以降、または一部のカスタムバージョンでは、AlarmManagerに登録されているクロックは、AppがFORCE STOPによってcancel(http://blog.csdn.net/yuanyl/article/details/44201695)
まずAndroid携帯電話には2つのプロセッサがあり、1つはApplication Processor(AP)、1つはBaseband Processor(BP)です.APはARMアーキテクチャのプロセッサであり、Linux+Androidシステムを実行するために使用される.BPはリアルタイムオペレーティングシステム(RTOS)を実行するために使用され、通信プロトコルスタックはBPのRTOS上で実行される.
非通話時間ではBPの消費電力は基本的に5 mA程度であるが,APは非スリープ状態であれば少なくとも50 mA以上であり,グラフィック演算を行う場合にはさらに高くなる.またLCD動作時の消費電力は100 mA程度、WIFIも100 mA程度.一般的に携帯電話が待機している場合、AP、LCD、WIFIはいずれもスリープ状態になり、Androidではアプリケーションのコードも実行を停止します.
Androidは、アプリケーション内のキーコードの正確な実行を確保するため、Wake LockのAPIを提供し、アプリケーションがコードを通じてAPがスリープ状態に入ることを阻止する権限を持つようにした.しかし、Androidデザイナーの意図を理解せずにWake Lock APIを悪用し、自身のプログラムがバックグラウンドで正常に動作するようにAPがスリープ状態に入るのを長時間阻止すれば、待機バッテリーキラーになる.例えば、この間のアプリケーション、例えば今でもこのことをしているアプリケーション.
まず,APが休眠するとメッセージプッシュが届かないことを全く心配する必要はない.通信プロトコルスタックはBPで動作し、パケットを受信すると、BPはAPを起動し、起動時間はAPがコードを実行して受信したパケットの処理プロセスを完了するのに十分である.その他、ConnectivityイベントがトリガーされるとAPも起動します.唯一の問題は、プログラムがサーバにハートビートパケットを送信する論理をどのように実行するかです.APで心拍数を計ることはできませんAndroidが提供するAlarm Managerは、心拍数などの周期的な問題を解決します.AlarmはBPタイミング(または他の石英時計付きチップで、よくわかりませんが、決してAPではありません)であるべきで、トリガ時にAP実行プログラムコードを起動します.ではWake Lock APIは何の役に立つのでしょうか?例えば、ハートビートパケットが要求から応答に至るまで、例えば断線再接続がこれらの重要な論理の実行プロセスに再ログインするには、Wake Lockが保護する必要があります.重要な論理が成功すれば、Wake Lockをすぐに解放する必要があります.2回のハートビートリクエストは5~10分間隔で、ほとんど消費電力がかかりません.ネットワークが不安定で、頻繁に断線して再接続しない限り、その場合の方法は多くありません.
PowerManagerについて
きほんしようてつづき
1.PowerManager pm = (PowerManager) getSystemService(Context.POWER_SERVICE);
Context.getSystemService()を通過する.方法PowerManagerインスタンスを取得します.2.次に、PowerManagerのnewWakeLock(int flags,String tag)を使用してWakeLockインスタンスを生成します.int FlagsはどのWakeLockを取得するかを示し、異なるLockはcpu、スクリーン、キーボードランプに異なる影響を与える.
3.WakeLockインスタンスを取得した後、acquire()を使用して対応するロックを取得し、他のビジネスロジックの操作を行い、release()を使用してリリースします(リリースは必須).
常用FLAG:
PARTIAL_WAKE_LOCK:CPUの動作を維持し、画面とキーボードランプがオフになっている可能性があります.
SCREEN_DIM_WAKE_LOCK:CPUの運転を維持し、画面表示を維持できるが灰色である可能性があり、キーボードランプの消灯を許可する
SCREEN_BRIGHT_WAKE_LOCK:CPUの運転を保持し、画面のハイライト表示を保持し、キーボードランプのオフを許可する
FULL_WAKE_LOCK:CPUの運転を保持し、画面のハイライト表示を保持し、キーボードランプも明るさを保持する
アクセス権:
またWakeLockの設定はActivityレベルであり、Applicationアプリケーション全体ではありません.
ActivityのonResumeメソッドでWakeLockを操作し、onPauseメソッドで解放できます.
android休眠の穴
1.サーバにポーリングするコードは実行されません.
TimerとTimerTaskを利用して,サーバに対するタイミングのポーリングを設定するが,マシンが一定時間後にポーリングが行われなくなることが分かった.長い間調べていたが、休眠によるものだった.後で解決する方法は,システムのAlarmServiceを用いてポーリングを実行することである.システムは機械をスリープさせ、電力を節約するが、完全に電源を切るわけではないため、システムの一部の優先度の高いプログラムはまだ実行されている.例えば、目覚まし時計は、AlarmServiceを利用して自分のプログラムをタイミングよく起動し、cpuを起動させ、実行してからスリープさせることができる.
2.バックグラウンドの長い接続が切断されました.
最近の問題.Socket長接続でQQのようなチャット機能を実現したところ、画面が消灯してからSocketが切断されたことが分かった.画面が开く时に再接続する必要がありますが、Logを见るたびにネットがリンクされていることに気づきました.后でcpuが休眠してリンクが切れていることに気づきました.データ线を差し込んでlogを见ると、ネットのcpuが回复し、ネットを见ると确かにリンクされています.最後にPARTIAL_を使いましたWAKE_LOCK、CPUをスリープさせない.
3.デバッグ中はスリープしません.2をデバッグしたとき、Socketが切れることもあるし、切れないこともあることに気づきました.私はデータ線を差し込んでデバッグしたり、データ線を抜いたりしていたので、Androidのスリープ状態は違いました.また、机械によって异なる表现があります.例えば、ある机械は、データ线を差し込むと充电します.ある机械はできません.ある机械の设置の充电の时、スクリーンが暗くなりません.実はこの休眠メカニズムを理解して、すべてが言いやすいです.
AlarmManagerについて
AlarmManagerはAndroidがユーザーに提供するもので、スリープモードでもハートビートバッグ、断線再接続など、いくつかの動作を実行できるメカニズムです.注意すべきは、AlarmManagerのライフサイクルは、android 3.1以前に、手動cancelで登録されていない限り、AlarmManagerに登録されているクロックが有効であることです.1以降、または一部のカスタムバージョンでは、AlarmManagerに登録されているクロックは、AppがFORCE STOPによってcancel(http://blog.csdn.net/yuanyl/article/details/44201695)