URLからオーディオを再生する(ストリーミング)サービスでMediaPlayerを実行しています。今のところうまく機能しているようで、電話をスタンバイ状態にしても再生を続けます。
現在、ウェイクロックを取得していません。私の質問は:
- 私の状況では、実際にウェイクロックを取得する必要がありますか?
- 必要な場合、どのタイプのウェイクロックを取得する必要がありますか?
はい、これはwakelockの正当な使用例です。これは、ユーザーが明示的にオーディオの再生を継続することを望んでいるためです。
URLからオーディオを再生する(ストリーミング)サービスでMediaPlayerを実行しています。今のところうまく機能しているようで、電話をスタンバイ状態にしても再生を続けます。
現在、ウェイクロックを取得していません。私の質問は:
はい、これはwakelockの正当な使用例です。これは、ユーザーが明示的にオーディオの再生を継続することを望んでいるためです。
編集:あなたが安全な側でプレーしたいなら、あなたはWakeLockを使いたいです。そうすれば、MediaPlayerが変更され、電話が一時停止したときにスリープ状態になることが許可された場合でも、プログラムは正しく機能します。WakeLockを追加しても、必要がなくなったときに確実に解放すれば、失うものは何もありません。そうしないと、意図したよりも多くのバッテリーを消耗し、最悪の場合、アプリケーションの終了時にロックを解除しなかったことを示すエラーがすぐに表示されます。WakeLockを追加すると(冗長になる可能性がありますが)、依存するソフトウェアの変更に対してアプリケーションがより堅牢になるため、これは良い習慣です。
MediaPlayerは、デフォルトではこれを自動的に行いません。
ただし、ウェイクロックを取得する代わりに、プレイ中にウェイクロックを保持するように指示するために呼び出すことができるメソッドがあります。
ドキュメントに記載されているように、ウェイクロックを保持しているのはアプリであるため、この機能を使用するには、ウェイクロックのアクセス許可をリクエストする必要があります。
PowerManagerが再生中に起動してスリープしないことを保証できないため、おそらくWakeLockが必要になります。PARTIAL_WAKE_LOCKは、最低レベルのバッテリー消耗が使用されることを保証します(CPUがオン、画面/キーボードがオフ)。バッテリーの消耗の影響はいつでもテストできますが、音楽を再生するにはCPUがオンになっている必要があるため、バッテリーの消耗が大きくなるとは思えません。この方法により、使用されている電話(またはその電話の設定)に関係なく、CPUがスリープ状態になることで再生が中断されることはありません。
これにはWakeLockは必要ないと思います。MediaPlayerを初めて使用したとき、スタンバイ状態でシャットダウンしないことがすぐにわかりました。それを克服するのに少し手間がかかりましたが、スタンバイによってストリーミングMediaPlayerオブジェクトが停止するケースは見たことがありません。
mediaPlayer.setScreenOnWhilePlaying(true);
ドキュメントには次のように書かれています。「これは、アプリケーションが低レベルのウェイクロックアクセスのアクセス許可を持っている必要がないため、可能な場合は「setWakeMode」よりも推奨される方法です。」
ウェイクロックは必要ありません。WAKE LOCKを使用すると、ユーザーに画面をオンのままにするように強制されます。私は個人的に、メディアの再生中は画面をオフにすることを好みます。
ここでの長期実行サービスの例例