Bagian ini menjelaskan cara memisahkan aplikasi pemutar media menjadi pengontrol media (untuk UI) dan sesi media (untuk pemutar sebenarnya). Di sini dijelaskan dua arsitektur aplikasi media: desain klien/server yang berfungsi dengan baik untuk aplikasi audio dan desain aktivitas tunggal untuk pemutar video. Panduan ini juga menunjukkan cara membuat aplikasi media merespons kontrol hardware dan bekerja sama dengan aplikasi lain yang menggunakan streaming output audio.
Pemutar dan UI
Aplikasi multimedia yang memutar audio atau video biasanya memiliki dua bagian:
- Pemutar yang menerima media digital dan merendernya sebagai video dan/atau audio
- UI dengan kontrol transport untuk menjalankan pemutar dan, jika diinginkan, menampilkan status pemutar
Di Android, Anda dapat membuat pemutar sendiri dari awal, atau memilih dari opsi berikut:
- Class MediaPlayer menyediakan fungsi dasar untuk pemutar standar yang mendukung format audio/video dan sumber data yang paling umum.
- ExoPlayer adalah library open source yang di-build di atas komponen framework media tingkat rendah seperti
MediaCodecdanAudioTrack. ExoPlayer mendukung fitur berperforma tinggi seperti DASH yang tidak tersedia diMediaPlayer. Anda dapat menyesuaikan kode ExoPlayer, sehingga mudah untuk menambahkan komponen baru. ExoPlayer hanya dapat digunakan dengan Android versi 4.1 dan yang lebih tinggi.
Sesi media dan pengontrol media
Meskipun API untuk UI dan pemutar dapat bersifat arbitrer, sifat interaksi antara dua bagian tersebut pada dasarnya sama untuk semua aplikasi pemutar media. Framework Android menentukan dua class, sesi media dan pengontrol media, yang menerapkan struktur yang ditetapkan dengan baik untuk mem-build aplikasi pemutar media.
Sesi media dan pengontrol media saling berkomunikasi menggunakan callback standar yang sesuai dengan tindakan pemutar standar (putar, jeda, berhenti, dll.), serta panggilan kustom yang dapat diperluas yang Anda gunakan untuk menentukan perilaku khusus yang unik untuk aplikasi Anda.
Sesi media
Sesi media bertanggung jawab atas semua komunikasi dengan pemutar. Metode ini menyembunyikan API pemutar dari bagian aplikasi lainnya. Pemutar hanya dipanggil dari sesi media yang mengontrolnya.
Sesi ini mempertahankan representasi status pemutar (diputar/dijeda)
dan informasi tentang konten yang sedang diputar. Sesi dapat menerima
callback dari satu
atau beberapa pengontrol media. Hal ini memungkinkan pemutar
dikontrol oleh UI aplikasi Anda serta perangkat pendamping yang menjalankan Wear OS dan
Android Auto. Logika yang merespons callback harus konsisten. Respons
terhadap callback MediaSession harus sama, apa pun aplikasi klien
yang memulai callback tersebut.
Pengontrol media
Pengontrol media mengisolasi UI Anda. Kode UI Anda hanya berkomunikasi dengan pengontrol media, bukan pemutar itu sendiri. Pengontrol media menerjemahkan tindakan kontrol transpor menjadi callback ke sesi media. Pengontrol media juga menerima callback dari sesi media setiap kali status sesi berubah. Tindakan ini menyediakan mekanisme untuk otomatis mengupdate UI terkait. Pengontrol media hanya dapat terhubung ke satu sesi media dalam satu waktu.
Saat menggunakan pengontrol media dan sesi media, Anda dapat men-deploy berbagai antarmuka dan/atau pemutar saat runtime. Anda dapat mengubah tampilan dan/atau performa aplikasi secara terpisah, bergantung pada kemampuan perangkat tempat aplikasi berjalan.
Aplikasi video versus aplikasi audio
Saat memutar video, mata dan telinga Anda sama-sama aktif. Saat memutar audio, Anda mendengarkan, tetapi Anda juga dapat membuka aplikasi lain secara bersamaan. Ada desain yang berbeda untuk setiap kasus penggunaan.
Aplikasi video
Aplikasi video memerlukan jendela untuk melihat konten. Karena alasan ini, aplikasi video biasanya diterapkan sebagai satu aktivitas Android. Layar tempat video ditampilkan adalah bagian dari aktivitas.
Aplikasi audio
Pemutar audio tidak perlu selalu menampakkan UI-nya. Setelah mulai memutar audio, pemutar dapat berjalan sebagai tugas latar belakang. Pengguna dapat beralih ke aplikasi lain dan bekerja sambil terus mendengarkan.
Untuk mengimplementasikan desain ini di Android, Anda dapat mem-build aplikasi audio menggunakan dua komponen: aktivitas untuk UI dan layanan untuk pemutar. Jika pengguna beralih ke aplikasi lain, layanan dapat berjalan di latar belakang. Dengan memfaktorkan dua bagian aplikasi audio ke dalam komponen terpisah, masing-masing bagian dapat berjalan dengan lebih efisien sendiri. UI biasanya berumur pendek dibandingkan dengan pemutar, yang dapat berjalan untuk waktu yang lama tanpa UI.
Support library menyediakan dua class untuk menerapkan pendekatan klien/server ini: MediaBrowserService dan MediaBrowser. Komponen layanan
diimplementasikan sebagai subclass MediaBrowserService yang berisi sesi media dan
pemutarnya. Aktivitas dengan UI dan pengontrol media harus menyertakan
MediaBrowser, yang berkomunikasi dengan MediaBrowserService.
Penggunaan MediaBrowserService akan memudahkan perangkat pendamping (seperti Android
Auto dan Wear) untuk menemukan, menghubungkannya, menjelajahi konten, dan
mengontrol pemutaran, tanpa mengakses aktivitas UI aplikasi Anda sama sekali. Bahkan, mungkin
ada beberapa aplikasi yang terhubung ke MediaBrowserService yang sama secara bersamaan, setiap aplikasi dengan MediaController-nya sendiri. Aplikasi yang menawarkan
MediaBrowserService harus dapat menangani beberapa koneksi
secara bersamaan.
Aplikasi media dan infrastruktur audio Android
Aplikasi media yang dirancang dengan baik harus "dapat diputar dengan baik bersama" dengan aplikasi lain yang memutar audio. Aplikasi harus siap untuk berbagi ponsel dan bekerja sama dengan aplikasi lain di perangkat Anda yang menggunakan audio. Aplikasi ini juga harus merespons kontrol hardware di perangkat.
Semua perilaku ini dijelaskan dalam Mengontrol Output Audio.
Library media-compat
Library media-compat berisi class yang berguna untuk mem-build aplikasi yang memutar audio dan video. Class ini kompatibel dengan perangkat yang menjalankan Android 2.3 (API level 9) dan yang lebih baru. Fitur ini juga berfungsi dengan fitur Android lainnya untuk menciptakan pengalaman Android yang nyaman dan familier.
Implementasi sesi media dan pengontrol media yang direkomendasikan adalah
class MediaSessionCompat dan
MediaControllerCompat, yang ditentukan dalam
support library
media-compat. Keduanya menggantikan class MediaSession
dan MediaController versi lama yang diperkenalkan di Android 5.0 (API level 21). Class compat menawarkan fungsi yang sama, tetapi mempermudah pengembangan aplikasi karena Anda hanya perlu menulis ke satu API. Library ini menangani kompatibilitas
mundur dengan menerjemahkan metode sesi media ke metode yang setara pada
versi platform lama jika tersedia.
Jika Anda sudah memiliki aplikasi yang berfungsi dan menggunakan class yang lebih lama, sebaiknya
lakukan update ke class compat. Saat menggunakan versi compat, Anda dapat menghapus semua panggilan ke registerMediaButtonReceiver() dan metode apa pun dari RemoteControlClient.
Mengukur performa
Di Android 8.0 (API level 26) dan yang lebih baru, metode getMetrics() tersedia
untuk beberapa class media. Metode ini menampilkan objek PersistableBundle yang berisi informasi konfigurasi dan performa, yang dinyatakan sebagai peta atribut dan nilai.
Metode getMetrics() ditentukan untuk class media berikut:
MediaPlayer.getMetrics()MediaRecorder.getMetrics()MediaCodec.getMetrics()MediaExtractor.getMetrics()
Metrik dikumpulkan secara terpisah untuk setiap instance dan bertahan selama masa aktif instance. Jika tidak ada metrik yang tersedia, metode akan menampilkan null. Metrik sebenarnya yang ditampilkan bergantung pada class-nya.