Picture-in-Picture dans les applications mobiles — ce que c’est, comment ça marche et où l’utiliser

Qu’est-ce que Picture-in-Picture ?

Picture-in-Picture (PiP) est un mode d’affichage vidéo qui montre le contenu dans une petite fenêtre flottante qui reste au-dessus de toutes les autres fenêtres et applications. L’utilisateur peut déplacer la fenêtre PiP sur l’écran, la redimensionner (sur certaines plateformes) et continuer à regarder le contenu tout en travaillant dans d’autres applications.

Le concept de PiP vient de la télévision : dès les années 1990, les téléviseurs permettaient d’afficher une deuxième chaîne dans un coin de l’écran. Sur les appareils mobiles, PiP est apparu pour la première fois sur iPad avec iOS 9 (2015) pour les vidéos dans Safari, tandis que le PiP système complet pour les applications est devenu disponible dans iOS 14 (2020). La prise en charge de PiP sur Android est arrivée plus tôt — dans la version 8.0 Oreo (2017), mais uniquement pour la vidéo, et à partir d’Android 12 pour tous les types de contenu.

PiP diffère de la lecture en arrière-plan car la vidéo continue de s’afficher à l’écran, et pas seulement d’être lue dans le flux audio. La lecture audio en arrière-plan est disponible sur les deux plateformes, mais PiP donne à l’utilisateur un contrôle visuel sur le contenu : il peut voir les images, mettre en pause, rembobiner ou fermer la fenêtre. C’est particulièrement important pour les tutoriels vidéo, les streams et les appels vidéo où le contenu visuel est aussi important que l’audio.

Comment fonctionne PiP ?

Sur le plan architectural, PiP est implémenté via un gestionnaire de fenêtres système qui crée une fenêtre séparée avec une priorité d’affichage réduite. L’application délègue la sortie vidéo à un service système qui continue de rendre la vidéo même après que l’application est passée en arrière-plan ou a été réduite.

Cycle de vie d’une session PiP

Le processus commence lorsque l’utilisateur réduit l’application avec une vidéo active ou appuie sur le bouton PiP (sur iOS), ou que le système transfère automatiquement l’Activity en mode PiP (sur Android). Le gestionnaire de fenêtres système capture le flux vidéo et crée une fenêtre flottante avec des proportions fixes. La taille de la fenêtre dépend du rapport hauteur/largeur de la vidéo d’origine et des contraintes de la plateforme : sur iOS, la fenêtre PiP occupe environ 1/6 à 1/4 de la largeur de l’écran ; sur Android, pas moins de 108 dp de largeur et 240 dp de hauteur pour les appareils mobiles.

Lorsque la fenêtre PiP est active, l’application peut être dans l’un des trois états : en arrière-plan (réduite), à l’état actif (l’utilisateur est revenu à l’application), ou en attente (le système a mis PiP en pause par manque de ressources). Lors de la transition vers PiP, l’application doit suspendre les opérations d’interface inutiles (animations, rendu de l’interface) et libérer de la mémoire, car les ressources système sont allouées plus strictement en mode multitâche. iOS envoie automatiquement à l’application une notification AVPictureInPictureControllerWillStartNotification, tandis qu’Android envoie le callback onPictureInPictureModeChanged.

Limitations du mode PiP

La fenêtre PiP a des limitations importantes : elle ne peut pas afficher les éléments d’interface standard (bouton de pause, barre de progression) — seulement une superposition système minimale avec des contrôles de base : lecture/pause, fermer, agrandir en plein écran. L’interface PiP système sur iOS inclut les boutons de pause et de fermeture, tandis que sur Android elle inclut les mêmes éléments plus un bouton de paramètres supplémentaire. L’interaction avec le contenu dans PiP (rembobinage, sélection de sous-titres) n’est pas possible — pour cela, il faut agrandir l’application en plein écran.

PiP sur iOS : implémentation et limitations

Sur iOS, PiP est implémenté via le framework AVKit et la classe AVPictureInPictureController. Cette API est disponible sur iOS 14+ pour iPhone et iPad, mais avec des exigences différentes : sur iPad, PiP fonctionne via AVPlayerLayer ; sur iPhone, uniquement via AVPlayerViewController.

Exigences pour PiP sur iOS

Pour que PiP fonctionne sur iOS, plusieurs conditions doivent être remplies : l’application doit utiliser AVPlayer pour la lecture vidéo, la session audio doit être configurée sur la catégorie .playback ou .playAndRecord, et l’application doit avoir des droits pour l’audio en arrière-plan (UIBackgroundModes = audio). Sans ces configurations, PiP ne démarrera pas — le système rejettera la demande de session PiP car il ne peut pas garantir une lecture correcte après le passage en arrière-plan.

Sur iOS, la fenêtre PiP apparaît automatiquement lors de la réduction de l’application si la vidéo est activement lue et que l’utilisateur n’a pas désactivé cette fonction dans les réglages. L’utilisateur peut également réduire manuellement la vidéo en PiP via le bouton dans AVPlayerViewController. La taille de la fenêtre PiP sur iOS est fixe et déterminée par le système — le développeur ne peut pas la modifier. Le rapport hauteur/largeur de la fenêtre PiP correspond à celui de la vidéo d’origine, mais la taille maximale est limitée à 1/4 de la largeur de l’écran sur iPhone et 1/3 sur iPad.

Limitations de PiP sur iOS

Les principales limitations de PiP sur iOS : impossibilité d’interface personnalisée dans la fenêtre PiP, un seul flux PiP à la fois, et nécessité d’un AVPlayer actif pour le fonctionnement de PiP. Le multi-PiP — lecture simultanée de plusieurs fenêtres PiP — n’est pas pris en charge sur iOS. Si on tente de lancer un deuxième PiP, le premier se ferme automatiquement. C’est une limitation matérielle : le processeur vidéo ne peut pas gérer simultanément deux canaux PiP indépendants en raison des contraintes de DMA et de mémoire vidéo.

Une autre limitation importante est la durée de la lecture en arrière-plan. Si l’utilisateur n’interagit pas avec la fenêtre PiP, le système peut mettre la lecture en pause après un certain temps pour économiser l’énergie. La pause automatique de PiP sur iOS survient après 10 à 15 minutes d’inactivité si l’application n’a pas implémenté de mécanisme keep-alive via une tâche d’arrière-plan. Pour les appels vidéo et les streams, il est recommandé d’utiliser PushKit et les certificats VoIP, qui contournent cette limitation.

PiP sur Android : implémentation et limitations

Sur Android, PiP est implémenté comme un mode Activity intégré qui s’active via la méthode enterPictureInPictureMode. Depuis Android 8.0 (API 26), toute Activity peut passer en mode PiP, et depuis Android 12 (API 31), la prise en charge de PiP pour SurfaceView et TextureView est disponible sans utiliser MediaCodec.

Configuration du manifeste

Pour prendre en charge PiP dans le manifeste Android, l’attribut android:supportsPictureInPicture doit être spécifié pour l’Activity dans la section . Sans cet attribut, le système n’autorisera pas la transition vers PiP. De plus, il est recommandé de spécifier android:configChanges="screenSize|smallestScreenSize|screenLayout|orientation" pour que l’Activity ne soit pas recréée lors du changement de taille de la fenêtre pendant la transition vers PiP. La compilation doit avoir targetSdkVersion >= 26 (Android 8.0) pour que le PiP de base fonctionne.

Sur Android, la fenêtre PiP n’a par défaut aucun élément de contrôle. Le développeur peut ajouter des actions personnalisées via RemoteAction dans la méthode setPictureInPictureParams. Jusqu’à 3 actions sont disponibles (exemple : pause/lecture, rembobinage arrière/avant, fermeture). Chaque action apparaît dans la superposition système PiP sous forme d’icône. Contrairement à iOS, où tous les éléments d’interface sont strictement fixes, Android offre plus de flexibilité pour les contrôles de base.

Adaptation aux différentes versions

PiP sur Android a différentes capacités selon la version du système d’exploitation. Sur Android 8.0–8.1, PiP est disponible uniquement pour la vidéo lue via MediaPlayer ou MediaCodec avec SurfaceView. À partir d’Android 9, on peut utiliser PictureInPictureArgs.Builder pour configurer le rapport hauteur/largeur de la fenêtre PiP. Android 12 a ajouté la prise en charge de PiP pour SurfaceView et TextureView personnalisés, ainsi que des transitions améliorées entre le mode plein écran et PiP. Android 13+ permet d’afficher la fenêtre PiP même lorsque l’écran est verrouillé, si l’application dispose de l’autorisation appropriée.

Une différence clé de PiP sur Android par rapport à iOS est la capacité multi-PiP. Sur Android 12+, le système peut afficher plusieurs fenêtres PiP simultanément si les applications le prennent en charge et si les performances de l’appareil le permettent. Cependant, en pratique, le multi-PiP est limité par les capacités du SoC : la plupart des appareils ne prennent en charge qu’une seule fenêtre PiP en raison des limitations matérielles du décodeur, car chaque fenêtre PiP nécessite son propre flux vidéo et une session de décodage séparée.

Exemples de code PiP

Examinons une implémentation pratique de PiP sur les deux plateformes mobiles, en tenant compte des dernières modifications d’API.

PiP sur iOS avec 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
    ) {
        // Masquer les éléments d’interface, libérer la mémoire
    }
    
    func pictureInPictureControllerDidStop(
        _ pictureInPictureController: AVPictureInPictureController
    ) {
        // Restaurer l’interface, reprendre le rendu
    }
}

Dans cet exemple, AVPictureInPictureController est initialisé avec playerLayer après vérification de isPictureInPictureSupported (PiP n’est pas pris en charge sur iPhone SE 1re génération et certains iPad sans mémoire suffisante). Le délégué notifie l’application du début et de la fin de PiP — dans ces callbacks, les éléments d’interface doivent être masqués et restaurés, car l’interface de l’application n’est pas visible en mode PiP. Lors de la transition vers PiP, il est recommandé d’arrêter toutes les animations, de masquer les contrôles du lecteur et de libérer la mémoire inutilisée pour éviter le déchargement forcé de l’application par le système.

PiP sur Android avec 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) {
            // Masquer l’interface, se concentrer uniquement sur le média
            binding.controlsGroup.visibility = View.GONE
        } else {
            // Restaurer l’interface
            binding.controlsGroup.visibility = View.VISIBLE
        }
    }
}

L’exemple en Kotlin utilise PictureInPictureParams.Builder pour configurer PiP. La méthode setAspectRatio définit le rapport hauteur/largeur de la fenêtre PiP (16:9 pour une vidéo typique). setAutoEnterEnabled(true) active la transition automatique vers PiP lors de la réduction de l’application. Le callback onPictureInPictureModeChanged est invoqué lors de l’entrée et de la sortie de PiP — ici, les éléments d’interface doivent être masqués ou affichés. Pour la vidéo sur SurfaceView, un traitement supplémentaire de configuration est nécessaire en ajoutant android:configChanges="screenSize|smallestScreenSize" au manifeste pour éviter la recréation de l’Activity pendant la transition vers le mode PiP.

Quand utiliser Picture-in-Picture

PiP est un outil puissant pour améliorer l’expérience utilisateur dans les applications où le contenu reste pertinent même lors du passage à d’autres tâches. Cependant, l’implémentation de PiP doit être justifiée et ne pas distraire l’utilisateur.

Scénarios optimaux

Les appels vidéo et les conférences sont l’un des principaux scénarios de PiP. Dans Zoom, FaceTime, Google Meet, PiP permet de voir son interlocuteur tout en travaillant dans d’autres applications : lire des notes, regarder une présentation ou consulter ses e-mails. Le PiP pour les appels vidéo nécessite la prise en charge de la caméra en arrière-plan et une configuration appropriée de la session audio pour continuer la capture audio en arrière-plan. Sur iOS, cela se fait en utilisant AVSampleBufferDisplayLayer au lieu d’AVPlayerLayer, car les appels vidéo n’utilisent pas AVPlayer.

Les services de streaming (YouTube, Netflix, Twitch) utilisent activement PiP pour continuer la visualisation tout en recherchant du nouveau contenu. YouTube Premium propose PiP comme fonctionnalité payante, et Netflix restreint également PiP à certains plans d’abonnement en raison des restrictions de licence de contenu. Pour implémenter PiP dans une application de streaming, une intégration avec un système DRM (FairPlay, Widevine) prenant en charge un pipeline sécurisé en mode PiP est nécessaire.

Quand PiP n’est pas nécessaire

PiP n’est pas adapté aux applications avec du contenu vidéo interactif nécessitant une interaction de l’utilisateur : plateformes éducatives avec des tests dans le lecteur, streams de jeux avec chat, applications shopping avec des liens vers des produits dans la vidéo. Dans ces cas, la fenêtre PiP est trop petite pour afficher des informations supplémentaires, et les éléments interactifs ne sont pas pris en charge dans PiP. Il est recommandé d’utiliser PiP uniquement pour une visualisation passive, lorsqu’aucune interaction avec le contenu n’est requise.

Pour les applications de musique et de podcasts, PiP est excessif — l’audio en arrière-plan sans fenêtre visuelle suffit. PiP consomme des ressources GPU supplémentaires pour le rendu vidéo dans une fenêtre flottante, ce qui réduit l’autonomie de la batterie. Si le contenu est auditif (musique, podcasts, livres audio) — utilisez la lecture en arrière-plan sans PiP. S’il est visuel — implémentez PiP pour améliorer l’expérience utilisateur.