React Native Video- und Audio-Wiedergabe implementieren

1. Die richtige Bibliothek für den Anwendungsfall wählen

Die Videowiedergabe in React Native hat sich mit dem Übergang von expo-av zu den getrennten Paketen expo-video und expo-audio deutlich verändert. Google und Apple treiben ihre nativen Player-APIs kontinuierlich weiter, und die aufgeteilten Expo-Pakete spiegeln diese Trennung besser wider als das ältere, monolithische expo-av, das inzwischen als veraltet markiert ist. Für Expo-Projekte mit Standard-Anforderungen an Video- und Audiowiedergabe sind expo-video und expo-audio deshalb der empfohlene Einstiegspunkt.

Für Bare-React-Native-Projekte oder Anwendungsfälle mit fortgeschrittenen Streaming-Anforderungen, etwa detaillierter Kontrolle über Bitrate-Wechsel oder eigene native Erweiterungen, bleibt react-native-video die etabliertere Wahl mit einer größeren Community und mehr nativen Konfigurationsoptionen. Für einen dedizierten Audio-Player-Anwendungsfall wie eine Podcast- oder Musik-App ist wiederum react-native-track-player die spezialisierteste Lösung, da diese Bibliothek von Grund auf für Warteschlangen-Management, Lock-Screen-Steuerung und Background-Wiedergabe konzipiert wurde, statt diese Funktionen nachträglich auf einen generischen Video-Player aufzusetzen.

Diese Dreiteilung ist keine akademische Unterscheidung: Ein TikTok-artiger Kurz-Video-Feed mit Dutzenden gleichzeitig gerenderten Video-Elementen stellt völlig andere Anforderungen an Speicherverwaltung als ein einzelner, dauerhaft im Hintergrund laufender Podcast-Player. Die falsche Bibliothek für den jeweiligen Anwendungsfall zu wählen führt später zu Workarounds, die sich vermeiden lassen, wenn die Entscheidung von Anfang an bewusst getroffen wird.

2. Grundlegende Video-Player-Komponente

Eine grundlegende Video-Player-Komponente mit expo-video besteht aus einem Video-Hook, der einen Player-Zustand mit Play, Pause und Seek-Funktionen bereitstellt, kombiniert mit einer eigenen UI-Overlay-Komponente für Steuerelemente, da die native Standard-UI oft nicht zum restlichen App-Design passt. Der zentrale Vorteil von expo-video gegenüber dem älteren expo-av ist eine deutlich reaktivere API, bei der sich der Player-Zustand direkt über React-Hooks beobachten lässt, statt manuell auf Status-Events zu lauschen.

Für die Steuerelemente selbst hat sich ein Muster bewährt, bei dem die Steuerleiste nach einigen Sekunden ohne Interaktion automatisch ausgeblendet wird, ähnlich dem Verhalten nativer Video-Apps, und bei Tippen auf den Video-Bereich wieder eingeblendet wird. Ein Poster-Bild, das während des initialen Ladens angezeigt wird, verhindert einen unschönen schwarzen Bildschirm und verbessert die wahrgenommene Ladezeit erheblich.

// VideoPlayerScreen.tsx - basic expo-video player with custom controls
import { useVideoPlayer, VideoView } from 'expo-video';
import { useState } from 'react';
import { Pressable, View } from 'react-native';

export function VideoPlayerScreen({ videoUrl, posterUrl }) {
  const player = useVideoPlayer(videoUrl, (p) => {
    p.loop = false;
  });
  const [showControls, setShowControls] = useState(true);

  return (
    <View style={{ flex: 1 }}>
      <VideoView
        player={player}
        style={{ flex: 1 }}
        contentFit="contain"
        nativeControls={false}
      />
      <Pressable
        style={{ position: 'absolute', inset: 0 }}
        onPress={() => setShowControls((v) => !v)}
      >
        {showControls && (
          <View style={{ position: 'absolute', bottom: 20, left: 20, right: 20 }}>
            {/* Custom play/pause/seek controls go here */}
          </View>
        )}
      </Pressable>
    </View>
  );
}

3. Adaptives Streaming mit HLS und DASH

Für On-Demand-Video ist adaptive Bitrate-Streaming über HLS-Manifeste auf iOS und sowohl HLS als auch DASH auf Android der Standardansatz, um Videoqualität dynamisch an die verfügbare Bandbreite des Nutzers anzupassen. Ein HLS-Manifest referenziert mehrere Videostreams in unterschiedlichen Qualitätsstufen, zwischen denen der native Player während der Wiedergabe automatisch wechselt, ohne dass die App selbst Bandbreite messen oder Qualitätsentscheidungen treffen muss.

Sowohl expo-video als auch react-native-video unterstützen HLS-Quellen direkt über die URL des Manifests, ohne dass zusätzliche Konfiguration notwendig ist, solange der Server korrekte HLS-Segmente und ein valides Master-Playlist-Format ausliefert. Für DASH-Streaming auf Android bietet react-native-video zusätzlich detailliertere native Konfigurationsoptionen, etwa zur bevorzugten Startqualität oder zu Bandbreitenschätzungs-Strategien, die für Enterprise-Video-Anwendungen mit hohen Qualitätsanforderungen relevant werden können.

4. Background-Audio-Wiedergabe konfigurieren

Damit Audiowiedergabe weiterläuft, wenn die App in den Hintergrund wechselt oder der Bildschirm gesperrt wird, muss auf iOS die Audio-Session-Kategorie explizit auf playback gesetzt werden, statt der Standardkategorie, die Wiedergabe beim Sperren automatisch stummschaltet. Auf Android erfordert kontinuierliche Hintergrundwiedergabe einen Foreground Service mit sichtbarer Benachrichtigung, da das Betriebssystem sonst App-Prozesse ohne sichtbaren Benachrichtigungshinweis nach kurzer Zeit im Hintergrund beendet.

Dieser Unterschied zwischen den Plattformen wird oft unterschätzt: Während iOS Background-Audio über eine einfache Konfigurationseinstellung erlaubt, verlangt Android eine explizite, für den Nutzer sichtbare Benachrichtigung während der gesamten Wiedergabedauer. react-native-track-player kapselt diese plattformspezifische Komplexität bereits vollständig und bietet dafür ein fertiges Benachrichtigungslayout, während bei reinem expo-video oder react-native-video die Foreground-Service-Konfiguration manuell nachgerüstet werden muss.

{
  "expo": {
    "plugins": [
      [
        "expo-audio",
        {
          "microphonePermission": false
        }
      ]
    ],
    "ios": {
      "infoPlist": {
        "UIBackgroundModes": ["audio"]
      }
    },
    "android": {
      "permissions": ["FOREGROUND_SERVICE", "FOREGROUND_SERVICE_MEDIA_PLAYBACK"]
    }
  }
}

5. Lock-Screen- und Kontrollzentrum-Steuerung

Ein Podcast- oder Musik-Player-Nutzer erwartet, direkt vom Sperrbildschirm oder Kontrollzentrum aus pausieren, zum nächsten Titel springen oder die Wiedergabeposition ändern zu können, ohne die App zu öffnen. react-native-track-player bietet dafür eine fertige "Now Playing"-Integration, die Titel, Interpret und Cover-Art automatisch an die native Media-Session-API des Betriebssystems übergibt und Remote-Control-Events wie einen Tastendruck auf einem Bluetooth-Headset direkt an die App zurückmeldet.

Bei generischeren Video-Bibliotheken wie expo-video oder react-native-video muss diese Integration für einen dedizierten Audio-Anwendungsfall größtenteils manuell über native Module nachgebaut werden, was den zusätzlichen Implementierungsaufwand für ein Musik- oder Podcast-Projekt gegenüber react-native-track-player erheblich erhöht. Für ein Video-zentriertes Projekt mit gelegentlicher Audio-Wiedergabe im Hintergrund reicht die einfachere Konfiguration hingegen meist aus.

6. Offline-Wiedergabe und Download-Caching

Für Offline-Wiedergabe muss Videomaterial vorab heruntergeladen und lokal zwischengespeichert werden, was sowohl Speicherplatz-Management als auch eine Strategie zur Bereinigung alter, nicht mehr benötigter Downloads erfordert. Eine typische Implementierung lädt Segmente über einen Hintergrund-Download-Task herunter, verfolgt den Fortschritt über einen Progress-Callback und markiert abgeschlossene Downloads in einer lokalen Datenbank als offline verfügbar.

Die App-Speicherbegrenzung des Betriebssystems spielt hier eine wichtige Rolle: Wird zu viel Videomaterial gleichzeitig zwischengespeichert, kann iOS oder Android die App-Daten bei knappem Gerätespeicher automatisch bereinigen, ohne die App darüber explizit zu informieren. Eine robuste Implementierung prüft deshalb bei jedem App-Start, ob zwischengespeicherte Dateien noch tatsächlich vorhanden sind, statt sich blind auf den zuletzt bekannten Download-Status zu verlassen.

7. Picture-in-Picture und DRM-geschützte Inhalte

Picture-in-Picture erlaubt Nutzern, ein Video in einem kleinen, schwebenden Fenster weiterzuschauen, während sie zu einer anderen App wechseln, eine Funktion, die sowohl iOS als auch Android nativ unterstützen, aber pro Bibliothek unterschiedlich weit implementiert ist. react-native-video bietet hierfür bereits eine eingebaute Prop zur Aktivierung, während bei expo-video die Unterstützung je nach SDK-Version variieren kann und vor dem produktiven Einsatz gegen die jeweils aktuelle Dokumentation geprüft werden sollte.

Für Premium-Videoinhalte mit Lizenzschutz ist DRM über Widevine auf Android und FairPlay auf iOS notwendig, was zusätzliche Serverinfrastruktur zur Lizenzausstellung sowie eine native Konfiguration des Players für den jeweiligen DRM-Schlüsselserver erfordert. react-native-video bietet dafür ausgereiftere Konfigurationsoptionen als expo-video, weshalb Projekte mit ernsthaften DRM-Anforderungen, etwa Streaming-Dienste mit lizenziertem Content, in der Praxis meist zu react-native-video oder einer noch spezialisierteren nativen Integration greifen.

// iOS reference: configuring an AVAudioSession for background playback
import AVFoundation

func configureBackgroundAudioSession() throws {
    let session = AVAudioSession.sharedInstance()
    try session.setCategory(.playback, mode: .default, options: [])
    try session.setActive(true)
}

8. Performance-Tuning bei mehreren Video-Instanzen

Ein häufiger Performance-Fehler bei Video-Feeds im Listenformat ist, dass die Elternkomponente bei jedem Scroll-Event neu rendert und dabei versehentlich den Video-Player mit neu erzeugt, was zu einem sichtbaren Ruckler und einem erneuten Ladevorgang führt. Der Player selbst sollte über useMemo oder eine stabile Referenz außerhalb des häufig neu rendernden Elternteils gehalten werden, um dieses unerwünschte Verhalten zu vermeiden.

In einem TikTok-artigen Kurz-Video-Feed sollten außerdem niemals alle sichtbaren und unsichtbaren Video-Elemente gleichzeitig aktiv im Speicher gehalten werden. Ein bewährtes Muster begrenzt aktive Player-Instanzen auf das aktuell sichtbare Element sowie jeweils ein Element davor und danach, während weiter entfernte Elemente in der Liste nur noch das Poster-Bild anzeigen und ihren Player erst reaktivieren, wenn sie in den sichtbaren Bereich zurückscrollen.

9. Testing und Vergleich der Bibliotheken

Wiedergabe sollte unter verschiedenen Netzwerkbedingungen getestet werden, insbesondere mit gedrosselter Bandbreite über die Netzwerkbedingungs-Simulation von Xcode oder das Android-Emulator-Netzwerkprofil, um sicherzustellen, dass adaptives Streaming tatsächlich auf niedrigere Qualitätsstufen herunterschaltet, statt bei schlechter Verbindung komplett zu stocken. Ebenso wichtig ist ein Test des App-Wechsels während laufender Wiedergabe, um Background-Audio-Konfiguration und Lock-Screen-Steuerung zu verifizieren.

Die folgende Übersicht fasst zusammen, welche Bibliothek für welchen Anwendungsfall die geeignetste Wahl ist.

10. Zusammenfassung

Video- und Audio-Wiedergabe in React Native erfordert je nach Anwendungsfall eine unterschiedliche technische Grundlage: expo-video und expo-audio decken Standardanforderungen in Expo-Projekten ab, react-native-video bietet ausgereiftere DRM- und Streaming-Konfiguration für On-Demand-Video, und react-native-track-player ist die spezialisierteste Lösung für dedizierte Podcast- und Musik-Player mit Lock-Screen-Steuerung.

Background-Audio-Konfiguration unterscheidet sich fundamental zwischen iOS und Android, adaptives HLS- und DASH-Streaming passt Videoqualität automatisch an die Bandbreite an, und Performance-Tuning bei mehreren gleichzeitigen Video-Instanzen verhindert Speicherprobleme in Feed-artigen Layouts. Wer die richtige Bibliothek früh im Projekt wählt, statt nachträglich zwischen ihnen zu wechseln, spart erheblichen Implementierungsaufwand über die gesamte Projektlaufzeit.

11. FAQ: React Native Video- und Audio-Wiedergabe