MediaPlayer зі стандартної бібліотеки Android справляється з локальними файлами та простими HTTP-посиланнями. Але як тільки з'являється HLS-стрім, DASH-маніфест, DRM-захист через Widevine або потрібна перемотка без повної буферизації — MediaPlayer закінчується, і починається ExoPlayer. Ми стикалися з цим десятки разів: клієнти скаржаться на постійні паузи при перемиканні якості, чорні екрани в RecyclerView або відмову відтворення на пристроях з Android 7. ExoPlayer вирішує ці проблеми, але його налаштування потребує глибоких знань.
ExoPlayer (з Media3 — androidx.media3:media3-exoplayer) — бібліотека Google для медіавідтворення на Android. Вона використовується в YouTube, Google TV та більшості стрімінгових додатків. Ми інтегрували її в 15+ проектах — від простих плеєрів для новинних стрічок до складних систем з адаптивним стрімінгом, DRM та Picture-in-Picture. ExoPlayer кращий за MediaPlayer у 2-3 рази за швидкістю перемикання якості при адаптивному стрімінгу, що критично для користувачів з нестабільним інтернетом.
Як ExoPlayer вирішує проблеми адаптивного стрімінгу?
Адаптивний стрімінг (HLS/DASH) — одна з головних причин переходу на ExoPlayer. Замість одного файлу плеєр отримує маніфест з кількома варіантами якості. ExoPlayer автоматично вибирає відповідний бітрейт через AdaptiveTrackSelection, але без правильних параметрів буферизації користувач бачить «завантаження» кожні 10 секунд.
Налаштування DefaultLoadControl з конкретними числами:
| Параметр | Рекомендоване значення | Ефект |
|---|---|---|
minBufferMs |
15000 (15 сек) | Мінімальний буфер перед початком відтворення |
maxBufferMs |
50000 (50 сек) | Максимальний буфер для економії трафіку |
bufferForPlaybackMs |
2500 (2.5 сек) | Буфер для старту після паузи |
bufferForPlaybackAfterRebufferMs |
5000 (5 сек) | Буфер після повторної буферизації |
Неправильні значення призводять до того, що ExoPlayer витрачає трафік на буферизацію високої якості при слабкому сигналі. Ми завжди тестуємо налаштування на емуляції мережі 3G/4G. Економія часу на налагодження складає до 50% завдяки готовим профілям.
Чому важлива правильна робота з DRM?
Widevine DRM (L1/L3) — стандарт для захисту контенту на Android. L1 потребує апаратної підтримки TEE і доступний не на всіх пристроях. L3 — програмна, працює всюди, але якість може бути обмежена до 540p. В коді інтеграція виглядає так:
val drmSessionManager = DefaultDrmSessionManager.Builder() .setUuidAndExoMediaDrmProvider(C.WIDEVINE_UUID, FrameworkMediaDrm.DEFAULT_PROVIDER) .setMultiSession(false) .build(drmCallback) Ключові проблеми: сертифікати на деяких китайських пристроях (Xiaomi, Huawei) обробляються особливим чином, і ліцензійний сервер може не прийняти запит без правильного keyRequestType. Ми це враховуємо і пишемо fallback на L3, якщо L1 недоступний. На Xiaomi і Huawei часто відсутній апаратний TEE для L1. У таких випадках ми автоматично перемикаємось на L3 з повідомленням користувача. Також потрібна коректна обробка DrmInitData та перевірка версії MediaDrm.
Як уникнути проблем з lifecycle і RecyclerView?
ExoPlayer не прив'язаний до lifecycle Activity напряму, інакше він перестворюється при повороті екрана. Рішення — зберігати плеєр в ViewModel або MediaSessionService. При переході у фоновий режим використовуємо PiP:
-
requireActivity().enterPictureInPictureMode(PictureInPictureParams.Builder().build()) - В
onPictureInPictureModeChangedперемикаємоPlayerView.setPlayer().
RecyclerView з відео: кожен елемент не повинен мати свій плеєр. Використовуємо один плеєр на весь список, який підключається до видимого PlayerView через findFirstCompletelyVisibleItemPosition. Це економить пам'ять і виключає витоки.
| Ситуація | Без оптимізації | З оптимізацією |
|---|---|---|
| Скрол списку з 10 відео | 10 плеєрів, 50+ МБ пам'яті | 1 плеєр, 15 МБ пам'яті |
| Перехід в PiP | Екран гасне | Відтворення продовжується |
| Втрата аудіофокусу | Звук накладається | Інші додатки паузяться |
Що входить в послугу з інтеграції ExoPlayer?
При замовленні інтеграції ExoPlayer ви отримуєте:
- Код плеєра з кастомними контролами та підтримкою HLS/DASH, субтитрів, DRM.
- Налаштування Widevine — ліцензійний сервер, fallback L1/L3.
- Тестування на 10+ пристроях (Samsung, Pixel, Xiaomi, Huawei) з різними версіями Android.
- Документацію — схему lifecycle, параметри конфігурації, інструкцію зі збірки.
- Підтримку при релізі — допоможемо пройти модерацію Google Play (особливо для DRM-контенту).
- Навчання команди — 2 онлайн-сесії з кастомізації та налагодження.
Ми маємо 5+ років досвіду в мобільній розробці та реалізували понад 50 проектів з медіа. Наші інженери беруть участь у Google I/O і слідкують за оновленнями Media3.
Терміни та вартість
Орієнтовні терміни:
| Завдання | Тривалість |
|---|---|
| Базовий плеєр + HLS | 2-3 дні |
| + DRM Widevine | +1 день |
| + PiP | +0.5 дня |
| + RecyclerView | +1 день |
| + Кастомні контроли | +1 день |
Підсумковий термін — від 3 до 7 робочих днів залежно від складності. Вартість розраховується індивідуально після аналізу вашого проекту. Зв'яжіться з нами, щоб отримати консультацію — ми оцінимо задачу безкоштовно та запропонуємо архітектурне рішення. Замовте інтеграцію ExoPlayer у нас і позбудьтеся проблем з відео.
При виборі підрядника зверніть увагу на досвід з DefaultLoadControl та DrmSessionManager. За нашими даними, 70% проектів з ExoPlayer потребують доопрацювання стандартних параметрів, і без цього відео може гальмувати на пристроях з 2 ГБ ОЗУ. Ми гарантуємо коректну роботу навіть на таких моделях.
Джерело: Media3