Omówienie architektury aplikacji do multimediów

W tej sekcji wyjaśniamy, jak rozdzielić aplikację odtwarzacza na kontroler mediów (dla UI) i sesję multimediów (dla rzeczywistego odtwarzacza). Opisujemy w nim 2 architektury aplikacji multimedialnych: klienta/serwer, która dobrze sprawdza się w aplikacjach audio, i projekt z funkcją pojedynczego działania w przypadku odtwarzaczy wideo. Omówiono w nim również, jak skonfigurować aplikacje do obsługi multimediów, tak aby reagowały na elementy sterujące sprzętem i współpracowały z innymi aplikacjami, które korzystają ze strumienia wyjścia audio.

Odtwarzacz i interfejs użytkownika

Aplikacja multimedialna, która odtwarza dźwięk lub obraz zazwyczaj składa się z 2 części:

  • Odtwarzacz, który pobiera multimedia cyfrowe i renderuje je jako obraz i dźwięk
  • Interfejs z elementami sterującymi transportem do uruchamiania odtwarzacza i opcjonalnie wyświetlania jego stanu

ui-and-player

Na Androidzie możesz utworzyć własny odtwarzacz od podstaw lub wybrać jedną z tych opcji:

  • Klasa MediaPlayer udostępnia podstawowe funkcje odtwarzacza prostego, który obsługuje większość popularnych formatów audio/wideo oraz źródeł danych.
  • ExoPlayer to biblioteka open source, która opiera się na komponentach platformy multimedialnej niższego poziomu, takich jak MediaCodec i AudioTrack. ExoPlayer obsługuje funkcje o wysokiej wydajności, takie jak DASH, które nie są dostępne w wersji MediaPlayer. Możesz dostosować kod ExoPlayer, aby łatwo dodawać nowe komponenty. ExoPlayera działa tylko z Androidem 4.1 lub nowszym.

Sesja multimediów i kontroler multimediów

Interfejsy API interfejsu użytkownika i odtwarzacza mogą być dowolne, ale charakter interakcji między nimi jest w zasadzie taki sam w przypadku wszystkich aplikacji odtwarzaczy. Platforma Androida definiuje 2 klasy: sesję multimediów i kontroler multimediów, które nakładają dobrze zdefiniowaną strukturę na potrzeby tworzenia aplikacji odtwarzacza multimediów.

Sesja multimediów i kontroler multimediów komunikują się ze sobą za pomocą wstępnie zdefiniowanych wywołań zwrotnych odpowiadających standardowym działaniom odtwarzacza (odtwarzanie, wstrzymywanie, zatrzymywanie itp.), jak również rozszerzalnych wywołań niestandardowych, które służą do definiowania zachowań charakterystycznych dla aplikacji.

kontroler-sesja

Sesja multimediów

Sesja multimediów odpowiada za całą komunikację z odtwarzaczem. Ukrywa interfejs API odtwarzacza przed resztą aplikacji. Odtwarzacz jest wywoływany tylko z sesji multimediów, która go kontroluje.

Sesja zawiera informacje o stanie gracza (odtwarzanie/wstrzymane) i o tym, co jest odtwarzane. Sesja może otrzymywać wywołania zwrotne od co najmniej 1 kontrolera multimediów. W ten sposób możesz sterować odtwarzaczem za pomocą interfejsu aplikacji oraz urządzeń towarzyszących z Wear OS i Androidem Auto. Operatory logiczne, które odpowiadają na wywołania zwrotne, muszą być spójne. Odpowiedź na wywołanie zwrotne MediaSession powinna być taka sama niezależnie od tego, która aplikacja kliencka zainicjowała wywołanie zwrotne.

Kontroler multimediów

Kontroler multimediów izoluje interfejs użytkownika. Twój kod UI komunikuje się tylko z kontrolerem multimediów, a nie z samym odtwarzaczem. Kontroler multimediów przekształca działania związane ze sterowaniem w transport na wywołania zwrotne do sesji multimediów. Otrzymuje też wywołania zwrotne z sesji multimediów po każdej zmianie stanu sesji. Zapewnia to mechanizm automatycznego aktualizowania powiązanego interfejsu. Kontroler multimediów może połączyć się w danym momencie tylko z jedną sesją multimediów.

Jeśli używasz kontrolera multimediów i sesji multimediów, możesz wdrażać różne interfejsy lub odtwarzacze w czasie działania. Wygląd i działanie aplikacji możesz zmieniać niezależnie w zależności od możliwości urządzenia, na którym jest uruchomiona.

Aplikacje wideo a aplikacje audio

Podczas odtwarzania filmu Twoje oczy i uszy są wciągnięte. Gdy odtwarzasz dźwięk, słuchasz, ale w tym samym czasie możesz też korzystać z innej aplikacji. Zastosowano je w inny sposób.

Aplikacja z wideo

Aplikacja wideo musi mieć okno do wyświetlania treści. Dlatego aplikacja wideo jest zwykle implementowana jako pojedyncza aktywność na Androidzie. Ekran, na którym pojawia się film, jest częścią aktywności.

aktywność związana z odtwarzaczem wideo

Aplikacja audio

Odtwarzacz audio nie zawsze musi mieć widoczny interfejs. Gdy rozpocznie się odtwarzanie dźwięku, odtwarzacz może działać w tle. Użytkownik może przejść do innej aplikacji i dalej słuchać.

Aby wdrożyć ten projekt na Androidzie, możesz utworzyć aplikację audio z użyciem dwóch komponentów: działania dla UI i usługi dla odtwarzacza. Jeśli użytkownik przełączy się na inną aplikację, usługa może działać w tle. Rozkładając te 2 części aplikacji audio na osobne komponenty, każdy z nich może działać wydajniej. Interfejs użytkownika ma zazwyczaj krótki czas działania w porównaniu z odtwarzaczem, który może działać przez długi czas bez interfejsu użytkownika.

Aktywność związana z dźwiękiem i BrowserService

Biblioteka pomocy zawiera 2 klasy do wdrożenia tego podejścia z klientem/serwerem: MediaBrowserService i MediaBrowser. Komponent usługi jest zaimplementowany jako podklasa klasy MediaBrowserService zawierająca sesję multimediów i jej odtwarzacz. Aktywność w interfejsie i kontrolerze multimediów powinna zawierać obiekt MediaBrowser, który komunikuje się z interfejsem MediaBrowserService.

Dzięki usłudze MediaBrowserService urządzenia towarzyszące (np. Android Auto i Wear) mogą łatwo znaleźć Twoją aplikację, połączyć się z nią, przeglądać treści i sterować odtwarzaniem bez konieczności uzyskiwania dostępu do elementów interfejsu aplikacji. Z jednym elementem MediaBrowserService może być połączonych jednocześnie wiele aplikacji, a każda z nich ma własny element MediaController. Aplikacja oferująca MediaBrowserService powinna być w stanie obsługiwać wiele jednoczesnych połączeń.

Aplikacje multimedialne i infrastruktura audio Androida

Dobrze zaprojektowana aplikacja do multimediów powinna „dobrze współpracować” z innymi aplikacjami odtwarzającymi dźwięk. Powinna być przygotowana do udostępniania telefonu i współpracy z innymi aplikacjami na urządzeniu, które korzystają z dźwięku. Powinien też reagować na ustawienia sprzętu na urządzeniu.

zabawa z innymi

Wszystko to zostało opisane w sekcji Sterowanie wyjściem dźwięku.

Biblioteka Media-compat

Biblioteka media-compat zawiera klasy, które ułatwiają tworzenie aplikacji odtwarzających dźwięk i obraz. Te klasy są zgodne z urządzeniami z Androidem 2.3 (poziom interfejsu API 9) lub nowszym. Współpracują też z innymi funkcjami Androida, aby zapewnić wygodę i znajomość interfejsu Androida.

Zalecana implementacja sesji multimediów i kontrolerów multimediów to klasy MediaSessionCompat i MediaControllerCompat, które są zdefiniowane w bibliotece pomocy Media-compat. Zastępują one wcześniejsze wersje klas MediaSession i MediaController, które zostały wprowadzone w Androidzie 5.0 (poziom interfejsu API 21). Klasy compat mają te same funkcje, ale ułatwiają tworzenie aplikacji, ponieważ wystarczy napisać do jednego interfejsu API. Biblioteka zapewnia zgodność wsteczną, tłumacząc metody sesji multimedialnych na ich odpowiedniki w starszych wersjach platformy (o ile są dostępne).

Jeśli masz już działającą aplikację, która korzysta ze starszych klas, zalecamy zaktualizowanie klas compat. Jeśli używasz wersji compat, możesz usunąć wszystkie wywołania registerMediaButtonReceiver() i dowolne metody z RemoteControlClient.

Pomiar skuteczności

W Androidzie 8.0 (poziom interfejsu API 26) i nowszych metoda getMetrics() jest dostępna w przypadku niektórych klas multimediów. Zwraca obiekt PersistableBundle zawierający informacje o konfiguracji i wydajności, wyrażony w postaci mapy atrybutów i wartości. Metoda getMetrics() jest zdefiniowana dla tych klas multimediów:

Wskaźniki są zbierane oddzielnie dla każdej instancji i są przechowywane przez cały okres jej istnienia. Jeśli nie są dostępne żadne wskaźniki, metoda zwraca wartość null. Rzeczywiste zwrócone wskaźniki zależą od klasy.