Picture-in-Picture в мобилните приложения — какво е, как работи и къде се прилага

Какво е Picture-in-Picture?

Picture-in-Picture (PiP) е режим на показване на видео в малък плаващ прозорец, който остава над всички други прозорци и приложения. Потребителят може да премества прозореца PiP по екрана, да променя размера му (на някои платформи) и да продължи да гледа съдържание, докато работи в други приложения.

Концепцията PiP идва от телевизията: още през 90-те години телевизорите можеха да показват втори канал в ъгъла на екрана. В мобилните устройства PiP се появи за първи път на iPad в iOS 9 (2015) за видео в Safari, а пълноценният системен PiP за приложения стана достъпен в iOS 14 (2020). На Android поддръжката на PiP се появи по-рано — във версия 8.0 Oreo (2017), но само за видео, а от Android 12 — за всички видове съдържание.

PiP се различава от фоновото възпроизвеждане по това, че видеото продължава да се показва на екрана, а не само да се възпроизвежда в аудио потока. Фоново възпроизвеждане (background audio) е достъпно и на двете платформи, но PiP дава на потребителя визуален контрол върху съдържанието: вижда кадри, може да постави на пауза, да превърти или да затвори прозореца. Това е особено важно за видео уроци, стриймове и видеоразговори, където визуалното съдържание е също толкова важно, колкото и аудиото.

Как работи PiP?

Архитектурно PiP се имплементира чрез системния мениджър на прозорци, който създава отделен прозорец с по-нисък приоритет на показване. Приложението делегира видео изхода на системна услуга, която продължава рендерирането на видео дори след като приложението премине във фонов режим или бъде минимизирано.

Жизнен цикъл на PiP сесия

Процесът започва, когато потребителят минимизира приложението с активно видео или натисне бутона PiP (на iOS) или системата автоматично прехвърля Activity в PiP режим (на Android). Системният мениджър на прозорци улавя видео потока и създава плаващ прозорец с фиксирани пропорции. Размерът на прозореца зависи от съотношението на страните на оригиналното видео и ограниченията на платформата: на iOS прозорецът PiP заема приблизително 1/6–1/4 от ширината на екрана, на Android — най-малко 108 dp ширина и 240 dp височина за мобилни устройства.

Когато прозорецът PiP е активен, приложението може да бъде в едно от три състояния: на заден план (минимизирано), в активно състояние (потребителят се е върнал към приложението) или в състояние на изчакване (системата е спряла PiP поради липса на ресурси). При преминаване в PiP приложението трябва да спре ненужните UI операции (анимации, рендериране на интерфейса) и да освободи памет, тъй като системните ресурси в мултитаскинг режим се разпределят по-строго. iOS автоматично изпраща на приложението известие AVPictureInPictureControllerWillStartNotification, а Android — обратно извикване onPictureInPictureModeChanged.

Ограничения на PiP режима

Прозорецът PiP има значителни ограничения: на него не могат да се показват стандартни UI елементи за управление (бутон за пауза, плъзгач за напредък) — само минимално системно наслагване с основни елементи: play/pause, затваряне, разширяване на цял екран. Системният UI на PiP на iOS включва бутон за пауза и затваряне, а на Android — същите елементи плюс допълнителен бутон за настройки. Взаимодействието със съдържание вътре в PiP (превъртане, избор на субтитри) е невъзможно — за това трябва да отворите приложението на цял екран.

PiP на iOS: имплементация и ограничения

На iOS PiP е имплементиран чрез рамката AVKit и класа AVPictureInPictureController. Това API е достъпно на iOS 14+ за iPhone и iPad, но с различни изисквания: на iPad PiP работи чрез AVPlayerLayer, на iPhone — само чрез AVPlayerViewController.

Изисквания за PiP на iOS

За работа на PiP на iOS трябва да бъдат изпълнени няколко условия: приложението трябва да използва AVPlayer за възпроизвеждане на видео, аудио сесията трябва да бъде настроена към категория .playback или .playAndRecord, и приложението трябва да има права за фоново аудио (UIBackgroundModes = audio). Без тези настройки PiP няма да стартира — системата ще отхвърли заявката за създаване на PiP сесия, тъй като не може да гарантира коректно възпроизвеждане след преминаване на заден план.

На iOS прозорецът PiP се показва автоматично при минимизиране на приложението, ако видеото се възпроизвежда активно и потребителят не е изключил тази функция в настройките. Потребителят може също ръчно да минимизира видеото в PiP чрез бутона в AVPlayerViewController. Размерът на прозореца PiP на iOS е фиксиран и се определя от системата — разработчикът не може да го промени. Съотношението на страните на прозореца PiP съответства на съотношението на страните на оригиналното видео, но максималният размер е ограничен до 1/4 от ширината на екрана на iPhone и 1/3 на iPad.

Ограничения на iOS PiP

Основните ограничения на PiP на iOS: невъзможност за персонализиран UI в прозореца PiP, ограничение до един PiP поток едновременно и изискване за активен AVPlayer за работа на PiP. Multi-PiP — едновременно възпроизвеждане на множество PiP прозорци — не се поддържа на iOS. При опит за стартиране на втори PiP, първият автоматично се затваря. Това е хардуерно ограничение: видео процесорът не може едновременно да обслужва два независими PiP канала поради ограничения на DMA и видео паметта.

Друго важно ограничение — продължителността на възпроизвеждане на заден план. Ако потребителят не взаимодейства с прозореца PiP, системата може да спре възпроизвеждането след известно време за пестене на енергия. Автоматична пауза на PiP на iOS настъпва след 10–15 минути неактивност, ако приложението не е имплементирало keep-alive механизъм чрез background task. За видеоразговори и стриймове се препоръчва използването на PushKit и VoIP сертификати, които заобикалят това ограничение.

PiP на Android: имплементация и ограничения

На Android PiP е имплементиран като вграден режим на Activity, който се активира чрез метода enterPictureInPictureMode. От Android 8.0 (API 26) всяка Activity може да премине в PiP режим, а от Android 12 (API 31) се появи поддръжка на PiP за SurfaceView и TextureView без необходимост от използване на MediaCodec.

Конфигурация на манифеста

За поддръжка на PiP в Android манифеста трябва да се посочи атрибутът android:supportsPictureInPicture за Activity в секцията . Без този атрибут системата няма да разреши преминаване в PiP. Допълнително се препоръчва добавяне на android:configChanges="screenSize|smallestScreenSize|screenLayout|orientation", за да не се пресъздава Activity при промяна на размера на прозореца при преминаване в PiP. Компилацията трябва да има targetSdkVersion >= 26 (Android 8.0) за работа на основния PiP.

В Android прозорецът PiP по подразбиране няма елементи за управление. Разработчикът може да добави персонализирани действия чрез RemoteAction в метода setPictureInPictureParams. Достъпни са до 3 действия (например: пауза/възпроизвеждане, превъртане назад/напред, затваряне). Всяко действие се показва в системното наслагване на PiP като икона. За разлика от iOS, където всички UI елементи са строго фиксирани, Android предоставя повече гъвкавост за основни контроли.

Адаптация към различни версии

PiP на Android има различни възможности в зависимост от версията на операционната система. На Android 8.0–8.1 PiP е достъпен само за видео, възпроизвеждано чрез MediaPlayer или MediaCodec с SurfaceView. От Android 9 може да се използва PictureInPictureArgs.Builder за конфигуриране на съотношението на страните на прозореца PiP. Android 12 добави поддръжка на PiP за персонализирани SurfaceView и TextureView, както и подобрено управление на преходите между цял екран и PiP режим. Android 13+ позволява показване на прозореца PiP дори на заключен екран, ако приложението има съответното разрешение.

Ключовата разлика на Android PiP от iOS — възможността за multi-PiP. На Android от версия 12 системата може да показва множество PiP прозорци едновременно, ако приложенията го поддържат и производителността на устройството позволява. На практика обаче multi-PiP е ограничен от възможностите на SoC: повечето устройства поддържат само един PiP прозорец поради хардуерни ограничения на декодера, тъй като всеки PiP прозорец изисква собствен видео поток и отделна сесия за декодиране.

Примери за код на PiP

Нека разгледаме практическата имплементация на PiP на двете мобилни платформи, като вземем предвид последните промени в API.

PiP на iOS с AVPictureInPictureController

import AVKit
import AVFoundation

class VideoPlayerViewController: UIViewController {
    var player: AVPlayer!
    var pipController: AVPictureInPictureController?
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        let playerLayer = AVPlayerLayer(player: player)
        playerLayer.videoGravity = .resizeAspect
        view.layer.addSublayer(playerLayer)
        
        guard AVPictureInPictureController.isPictureInPictureSupported()
        else { return }
        
        pipController = AVPictureInPictureController(playerLayer: playerLayer)
        pipController?.delegate = self
    }
    
    @IBAction func startPiPTapped() {
        pipController?.startPictureInPicture()
    }
}

extension VideoPlayerViewController: AVPictureInPictureControllerDelegate {
    func pictureInPictureControllerWillStart(
        _ pictureInPictureController: AVPictureInPictureController
    ) {
        // Скрий UI елементите, освободи памет
    }
    
    func pictureInPictureControllerDidStop(
        _ pictureInPictureController: AVPictureInPictureController
    ) {
        // Възстанови UI, поднови рендерирането
    }
}

В примера AVPictureInPictureController се инициализира с playerLayer след проверка на isPictureInPictureSupported (PiP не се поддържа на iPhone SE 1-во поколение и някои iPad без достатъчно памет). Делегатът уведомява приложението за началото и края на PiP — в тези обратни извиквания трябва да се скрият и възстановят UI елементите, тъй като в PiP режим интерфейсът на приложението не е видим. При преминаване в PiP се препоръчва спиране на всички анимации, скриване на контролите на плейъра и освобождаване на неизползваната памет за предотвратяване на принудителното разтоварване на приложението от системата.

PiP на Android с PictureInPictureParams

class PipVideoActivity : AppCompatActivity() {
    
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setupVideoPlayer()
    }
    
    private fun enterPipMode() {
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
            val aspectRatio = Rational(16, 9)
            
            val pipParams = PictureInPictureParams.Builder()
                .setAspectRatio(aspectRatio)
                .setAutoEnterEnabled(true)
                .build()
            
            enterPictureInPictureMode(pipParams)
        }
    }
    
    override fun onPictureInPictureModeChanged(
        isInPictureInPictureMode: Boolean,
        newConfig: Configuration
    ) {
        if (isInPictureInPictureMode) {
            // Скрий UI, фокусирай се само върху медия
            binding.controlsGroup.visibility = View.GONE
        } else {
            // Възстанови UI
            binding.controlsGroup.visibility = View.VISIBLE
        }
    }
}

Примерът на Kotlin използва PictureInPictureParams.Builder за конфигуриране на PiP. Методът setAspectRatio задава съотношението на страните на прозореца PiP (16:9 за типично видео). setAutoEnterEnabled(true) включва автоматично преминаване в PiP при минимизиране на приложението. Обратното извикване onPictureInPictureModeChanged се извиква при влизане и излизане от PiP — в него трябва да се скриват или показват UI елементите. За видео на SurfaceView се изисква допълнителна обработка на конфигурацията чрез добавяне на android:configChanges="screenSize|smallestScreenSize" в манифеста за предотвратяване на пресъздаването на Activity при преминаване в PiP режим.

Кога да използваме Picture-in-Picture

PiP е мощен инструмент за подобряване на потребителското изживяване в приложения, където съдържанието остава релевантно дори при превключване към други задачи. Имплементацията на PiP обаче трябва да бъде обоснована и да не разсейва потребителя.

Оптимални сценарии

Видеоразговори и конференции — един от основните сценарии за PiP. В Zoom, FaceTime, Google Meet PiP позволява да се вижда събеседникът по време на работа в други приложения: четене на бележки, преглед на презентация или проверка на поща. PiP за видеоразговори изисква поддръжка на камера на заден план и правилна конфигурация на аудио сесията за продължаване на улавянето на звук на заден план. На iOS за това се използва AVSampleBufferDisplayLayer вместо AVPlayerLayer, тъй като видеоразговорите не използват AVPlayer.

Стрийминг услугите (YouTube, Netflix, Twitch) активно използват PiP за продължаване на гледането по време на търсене на ново съдържание. YouTube Premium предлага PiP като платена функция, Netflix също ограничава PiP до определени тарифни планове поради лицензионни ограничения на съдържанието. За имплементация на PiP в стрийминг приложение се изисква интеграция с DRM система (FairPlay, Widevine), която поддържа сигурен pipeline в PiP режим.

Кога PiP не е необходим

PiP не е подходящ за приложения с интерактивно видео съдържание, където се изисква взаимодействие с потребителя: образователни платформи с тестове вътре в плейъра, гейминг стриймове с чат, приложения за пазаруване с връзки към продукти във видеото. В тези случаи прозорецът PiP е твърде малък за показване на допълнителна информация, а интерактивните елементи в PiP не се поддържат от системата. Препоръчва се използване на PiP само за пасивно гледане, когато не се изисква взаимодействие със съдържанието.

За музикални приложения и подкасти PiP е излишен — достатъчно е фоново аудио без визуален прозорец. PiP консумира допълнителни GPU ресурси за рендериране на видео в плаващ прозорец, което съкращава времето за работа на батерията. Ако съдържанието е аудио (музика, подкасти, аудиокниги) — използвайте фоново възпроизвеждане без PiP. Ако е визуално — внедрете PiP за подобряване на потребителското изживяване.