このドキュメントでは、落とし穴になり得る 2 つの領域について説明します。
状態。「Medialayer」では、特定のオペレーションは特定の状態でのみ有効です。不適切なオペレーションを行うと、例外や予期しない動作が発生する可能性があります。
リソース 画面の回転などの構成を変更する場合は、
MediaPlayerオブジェクトを解放してシステム リソースを解放し、リソースの枯渇を回避する必要があります。
状態を管理する
MediaPlayer は状態ベースです。つまり、操作によっては、プレーヤーが特定の状態のときにのみ有効になります。そのため、コードを記述する際には、常に の内部状態を意識する必要があります。状態に適さない操作を行うと、システムから例外がスローされるなど、望ましくない動作が発生する可能性があります。
MediaPlayer クラスのドキュメントの状態遷移図では、MediaPlayer の状態がどのメソッドによりどう変わるかがわかるようになっています。例:
- 新しい
MediaPlayerを作成すると、アイドル状態になります。 setDataSource()を呼び出して初期化すると、状態が 初期化済みに変わります。prepare()メソッドまたはprepareAsync()メソッドを使用して準備します。MediaPlayerの準備が完了すると、Prepared状態になります。つまり、start()を呼び出してメディアを再生できます。
図が示すように、この時点では、start()、pause()、seekTo() などのメソッドを呼び出すことで、Started、Paused、PlaybackCompleted の各状態間を行き来できます。
ただし、stop() を呼び出した場合は、MediaPlayer を再度準備するまで start() を呼び出すことはできません。
状態に合わないメソッドの呼び出しは、よく見られるバグです。MediaPlayer オブジェクトを操作するコードを記述する際は、常に状態遷移図を念頭に置いてください。
MediaPlayer を解放する
MediaPlayer は、貴重なシステム リソースを消費する可能性があります。そのため、MediaPlayer インスタンスが必要以上に長く存在することのないよう、常に特別な措置を講じなければなりません。使用を終了したら必ず release() を呼び出して、割り当てられたシステム リソースが適切に解放されるようにする必要があります。
たとえば、MediaPlayer を使用していて、アクティビティが onStop() の呼び出しを受け取った場合、アクティビティがユーザーとやり取りしていない間に保持しておくのは意味がないため、MediaPlayer を解放する必要があります（バックグラウンドでメディアを再生している場合を除きます。これは次のセクションで説明します）。
当然のことながら、アクティビティを再開または再起動するときには、再生を再開する前に、新しい MediaPlayer を作成してもう一度準備を行う必要があります。
MediaPlayer の解放と無効化は次のように行います。
Kotlin
mediaPlayer?.release()
mediaPlayer = null
Java
mediaPlayer.release();
mediaPlayer = null;
たとえば、アクティビティの停止時に MediaPlayer を解放し忘れ、アクティビティの再起動時に新しく作成した場合に起こりうる問題を考えてみましょう。ユーザーが画面の向きを変更した場合（またはデバイスの構成を別の方法で変更した場合）、デフォルトではアクティビティが再起動されます。ユーザーがデバイスを縦向きと横向きを切り替えるたびに、新しい MediaPlayer が作成され、解放されないため、システム リソースがすぐに消費される可能性があります。
ランタイムの再起動の詳細については、ランタイムの変更を処理するをご覧ください。
ユーザーがアクティビティを離れた場合でも、組み込みの音楽アプリで行うのと同様に、「バックグラウンド メディア」の再生を続けたい場合はどうすればよいか、という疑問が生じるかもしれません。この場合は、次のセクションで説明するように、サービスで制御する MediaPlayer が必要になります。
詳細
アプリでのメディア再生には、Jetpack Media3 が推奨されるソリューションです。詳しくは、こちらをご覧ください。
以下は音声と動画の録音、録画、保存、再生に関するトピックを扱うページです。