Реализация офлайн-воспроизведения медиа в мобильном приложении

Скачать сериал в самолёт — базовый пользовательский сценарий. Реализовать его правильно — нетривиально: нужно управление хранилищем, отображение прогресса загрузки, поддержка паузы и возобновления, а если контент защищён — DRM с офлайн-лицензией. Мы берём на себя весь цикл: от проектирования до публикации в App Store и Google Play. Такой подход сокращает время выхода на рынок на 30% и снижает количество жалоб пользователей на заполненную память на 40%.

Какую проблему решаем?

Пользователь ожидает, что контент будет доступен офлайн после одного касания. Но без правильной архитектуры приложение либо занимает гигабайты, либо не может возобновить загрузку после обрыва сети. Apple рекомендует использовать AVAssetDownloadURLSession для HLS, а для Android — media3 DownloadManager. Разница в подходах существенная: iOS автоматически управляет структурой HLS-потока, а Android требует настройки CacheDataSource. media3 снижает объём кода загрузки на 30% по сравнению с устаревшим AsyncTask. Apple Developer Documentation

Почему важно управлять хранилищем?

Офлайн-контент накапливается. Пользователь не всегда помнит, что скачал. Показываем размер каждого скачанного элемента. iOS: AVURLAsset.assetCache?.isPlayableOffline — флаг готовности, размер через FileManager. Android: DownloadHelper.getDownloadedBytes(download). Ручное удаление и автоматическая очистка старых файлов (дольше N дней не воспроизводились). Квота: предупреждаем, если меньше 500 МБ свободного места. Такой подход снижает жалобы на заполненную память на 40% по опыту наших проектов.

Загрузка: подходы и инструменты

iOS. AVAssetDownloadURLSession — нативный API для загрузки HLS. Сохраняет не отдельные файлы, а структуру HLS-потока в виде AVURLAsset на диск:

let configuration = URLSessionConfiguration.background(withIdentifier: "com.app.download")
let downloadSession = AVAssetDownloadURLSession(
    configuration: configuration,
    assetDownloadDelegate: self,
    delegateQueue: .main
)

let task = downloadSession.makeAssetDownloadTask(
    asset: asset,
    assetTitle: "Эпизод 1",
    assetArtworkData: nil,
    options: [AVAssetDownloadTaskMinimumRequiredMediaBitrateKey: 2_000_000]
)
task.resume()

background конфигурация — загрузка продолжается, когда приложение в фоне или закрыто. Прогресс через URLSessionTaskDelegate.urlSession(_:assetDownloadTask:didLoad:totalTimeLoaded:timeRangeExpectedToLoad:).

Android. media3 DownloadManager + DownloadService. Сервис держит загрузки живыми в фоне:

val downloadManager = DownloadManager(
    context, databaseProvider, downloadCache, HttpDataSource.Factory(), Executor.Main
)
val downloadRequest = DownloadRequest.Builder(contentId, uri)
    .setMimeType(MimeTypes.APPLICATION_M3U8)
    .build()
DownloadService.sendAddDownload(context, MyDownloadService::class.java, downloadRequest, false)

Прогресс через DownloadManager.Listener.onDownloadChanged. Для прогрессивных файлов (MP4, MP3) без HLS — стандартный WorkManager + OkHttp с поддержкой Range заголовков для возобновления.

Сравнение подходов iOS и Android

Как работает офлайн-лицензия для DRM?

Без DRM раздел упрощается. С DRM — добавляется значительный пласт интеграции.

FairPlay (iOS). Офлайн-воспроизведение требует офлайн-лицензии: AVContentKeyRequest с makeStreamingContentKeyRequestData(forApp:contentIdentifier:options:). Лицензия скачивается от сервера (KSM) и сохраняется в защищённом хранилище. При воспроизведении офлайн — AVContentKeySession использует сохранённую лицензию.

Widevine (Android). ExoPlayer + DefaultDrmSessionManager. Офлайн-лицензия: OfflineLicenseHelper.downloadLicense(drmInitData), сохраняем keySetId. При воспроизведении офлайн — setLicenseUri + keySetId в MediaItem.DrmConfiguration.

Как настроить офлайн-лицензию для DRM?

Настройка включает несколько шагов. Во-первых, приложение должно получить лицензию от сервера, сохранить её в защищённом хранилище. На iOS это делается через AVContentKeyRequest с делегатом, на Android — через OfflineLicenseHelper. После сохранения лицензии при воспроизведении офлайн плеер должен использовать её вместо запроса к сети. Типичная ошибка — не проверять наличие сохранённой лицензии перед началом воспроизведения.

Воспроизведение скачанного контента

После загрузки на iOS: AVURLAsset(url: localHlsURL) — путь к сохранённому HLS. asset.assetCache?.isPlayableOffline должен быть true перед созданием AVPlayerItem. Если открыть ассет без проверки этого флага — плеер попытается обратиться к сети.

На Android с media3 DownloadManager: получаем DownloadRequest из базы данных, передаём в ExoPlayer через DownloadHelper.getDownloadedBytesForRequest(). CacheDataSource.Factory автоматически подставляет локальные данные вместо сетевых запросов.

Прогресс загрузки в UI

Несколько скачиваемых файлов одновременно — стандартная ситуация. Каждой загрузке нужен отдельный ProgressBar с процентом. На iOS: URLSession.progress.fractionCompleted через KVO, обновляем @Published в ViewModel. На Android: DownloadManager.Listener вызывается на фоновом потоке — переводим в Main через withContext(Dispatchers.Main).

Типичные ошибки при реализации

• Отсутствие проверки доступного места перед загрузкой.
• Игнорирование возобновления прерванных загрузок (требуется Range заголовки для прогрессивных файлов).
• Неправильное управление офлайн-лицензией: лицензия может истечь, нужно обрабатывать обновление.
• Забывают обрабатывать удаление контента при нехватке места.

Что входит в работу

1. Анализ требований к контенту (типы файлов, DRM, кодеки)
2. Проектирование архитектуры загрузки и хранилища
3. Реализация загрузчика с фоновыми задачами и возобновлением
4. Интеграция DRM (FairPlay / Widevine) с офлайн-лицензиями
5. Разработка UI прогресса и управления памятью
6. Тестирование на реальных устройствах (iOS 14+, Android 8+)
7. Подготовка к публикации в сторах (App Store Review, Google Play Console)
8. Документация и передача кода

Сроки

Мы гарантируем поддержку решения после деплоя. Свяжитесь с нами для обсуждения вашего проекта. Получите консультацию по архитектуре офлайн-воспроизведения.

Как выбрать подход к камере на мобильных платформах

Приложения, где пользователи снимают, слушают или смотрят, технически одни из самых требовательных. Мы сталкиваемся с этим каждый день. Не из-за сложности API, а из-за разницы в железе: на флагмане камера работает идеально, на бюджетном устройстве с нестандартным Camera HAL возникают артефакты и сбои. На iOS стабилизация одного поколения отличается от другого. Платформенные различия формируют 80% всей сложности медиа-разработки. Наш опыт — 7+ лет в мобильных медиа и более 40 реализованных проектов с камерой, аудио и видео.

CameraX против Camera2 и AVFoundation

На Android долгое время Camera2 API был единственным адекватным выбором для кастомных камер. Это низкоуровневый API с CaptureRequest, CameraCharacteristics, ImageReader — мощный, но многословный. Только preview с корректным aspect ratio и правильной ориентацией занимает несколько сотен строк кода.

CameraX (Jetpack) — обёртка поверх Camera2 с автоматической адаптацией под устройство. Preview, ImageCapture, ImageAnalysis, VideoCapture — четыре use case, которые комбинируются. Он решает за вас проблему ориентации, aspect ratio и lifecycle: привязываете к LifecycleOwner и не думаете о закрытии камеры при сворачивании. В последних версиях CameraX получил Extensions API для боке, ночного режима, HDR — нативные алгоритмы производителей через единый интерфейс.

Когда нужен Camera2 напрямую: RAW-съёмка через ImageFormat.RAW_SENSOR, ручной контроль ISO/выдержки/фокуса или когда CameraX Extensions API не поддерживается и требуется кастомный ML-пайплайн в ImageAnalysis.

На iOS AVFoundation — единственный путь для кастомной камеры. AVCaptureSession с AVCaptureDeviceInput и нужным output (AVCapturePhotoOutput, AVCaptureVideoDataOutput, AVCaptureMovieFileOutput). Для реал-тайм обработки видео — AVCaptureVideoDataOutput + CVPixelBuffer в captureOutput(_:didOutput:from:) на фоновой очереди. Именно тут CoreML-модели получают кадры для инференса.

Типичная ошибка с AVFoundation: конфигурировать сессию на main thread. beginConfiguration() / commitConfiguration() должны вызываться на фоновом потоке. Иначе preview фризит, пользователь видит заморозку интерфейса. Эта ошибка встречается в 70% проектов, которые мы аудировали.

Почему AudioFocus критичен для Android приложений

Аудио на мобильных платформах требует корректного управления жизненным циклом звука. AudioFocus — механизм координации между приложениями. AudioManager.requestAudioFocus() с OnAudioFocusChangeListener. Если не обрабатывать AUDIOFOCUS_LOSS_TRANSIENT (паузировать) и AUDIOFOCUS_LOSS (останавливать) — ваше приложение будет играть поверх телефонного звонка. Это гарантированный плохой отзыв в Google Play. Android Developer Guide: AudioFocus

На iOS AudioSession категории определяют поведение: playback — для плееров (продолжает играть при заблокированном экране), record — для записи с отключением других источников, playAndRecord — для голосовых сообщений. Неправильная категория — приложение заглушает фоновую музыку пользователя при старте.

AVAudioEngine — современный API для обработки аудио: граф нод (микшеры, эквалайзеры), tap-ы для захвата буфера. Для речи в реальном времени — SFSpeechRecognizer + inputNode.installTap.

На Android для записи с шумоподавлением — NoiseSuppressor.isAvailable() + create(audioRecord.audioSessionId). Работает не на всех устройствах, нужен fallback.

Видео: воспроизведение и стриминг

ExoPlayer (Media3) — стандарт для Android. Поддерживает HLS, DASH, SmoothStreaming, прогрессивное воспроизведение. DefaultTrackSelector с Parameters позволяет выбирать качество вручную или адаптивно. DRM через DefaultDrmSessionManager с Widevine L1/L3.

Проблема, с которой сталкиваются почти все: ExoPlayer в RecyclerView при быстром скролле. Нужен PlayerPool — пул переиспользуемых плееров. Без пула каждый новый экземпляр создаёт MediaCodec инстанс, что дорого и приводит к MediaCodec$CodecException: Error -19 на некоторых Android 10 устройствах при >3 одновременных инстансах.

AVPlayer / AVPlayerViewController на iOS — для воспроизведения. Для кастомного UI — AVPlayerLayer + собственные контролы. HLS работает нативно через AVPlayer(url:) с m3u8. FairPlay DRM требует серверной части: AVContentKeySession, CKC-ответ от KSM-сервера, делегат ресурсов.

Для Flutter — video_player как базовый слой, chewie для UI. Для серьёзных задач — platform channel к нативному ExoPlayer/AVPlayer (из-за DRM и субтитров).

WebRTC на мобильных — через нативные фреймворки или flutter_webrtc. Реальная сложность — не в самом протоколе, а в сигналинге и TURN-серверах. Без TURN клиенты за симметричными NAT не установят соединение — это примерно 15–20% трафика. Coturn — стандартный open-source сервер.

RTMP публикация на мобильных: LFLiveKit для iOS, HaishinKit как более современная альтернатива. На Android — rtmp-rtsp-stream-client-java или через FFmpeg с JNI. Последнее даёт максимальную гибкость, но бинарник растёт на 10–15 МБ.

Обработка медиа: компрессия и транскодирование

Видео в ProRes может занимать 6 ГБ/минуту. Перед загрузкой нужна компрессия. На iOS — AVAssetExportSession с пресетом 1920×1080 или кастомный AVVideoComposition. VideoToolbox для аппаратного кодирования H264/HEVC — быстрее и экономнее по батарее.

На Android — MediaCodec напрямую или Transformer (Media3) — высокоуровневый API для трансформаций (обрезка, ресайз, эффекты через GlEffectsFrameProcessor). Для изображений — BitmapFactory.Options.inSampleSize для даунсемплинга, Glide / Coil для кеширования. Coil на Coroutines хорошо вписывается в Compose. Загружать оригинал 12 МП в ImageView 200×200dp — классический OutOfMemoryError на устройствах с 2 ГБ RAM.

Как реализовать стриминг на мобильных устройствах: пошаговый план

1. Определить требования: целевая задержка, количество одновременных пользователей, необходимость P2P.
2. Выбрать протокол и стек: WebRTC для видеозвонков, RTMP/HLSLive для вещания.
3. Настроить сигналинг (SIP, WebSocket, MQTT) и TURN-сервер.
4. Реализовать публикацию/просмотр через нативный API или кроссплатформенный плагин.
5. Провести тестирование на реальных устройствах с разными камерами и сетевыми условиями.
6. Оптимизировать битрейт и разрешение в зависимости от пропускной способности.

Что входит в работу

Процесс разработки медиафункциональности

Сложность нелинейна: базовое воспроизведение видео — 1–2 дня, кастомная камера с обработкой кадров и стримингом — 3–5 недель. Начинаем с прояснения требований: DRM, форматы, минимальная OS, поддержка фоновых режимов. Тестирование на железе обязательно — эмулятор не воспроизводит проблемы с Camera HAL, аппаратным кодеком и AudioFocus. Минимальный набор: последний iPhone, iPhone SE, флагман Samsung, бюджетный Android, Android Go (если целевая аудитория — развивающиеся рынки).

Сроки ориентировочно: от 5 рабочих дней (базовое воспроизведение) до 8 недель (комплексная камера со стримингом и DRM). Стоимость рассчитывается индивидуально после анализа ваших требований — свяжитесь с нами для консультации.

Фраза услуги: «Работа с медиа в мобильных приложениях» — это наш профиль. Каждый проект начинается с аудита текущей реализации, выявления узких мест и предложения оптимального стека.

Коммерческие сигналы: закажите аудит вашей медиа-функциональности, получите консультацию инженера без обязательств.