60fps dans le développement mobile : essence, principe de fonctionnement et impact sur les performances

Qu'est-ce que 60fps

60fps (60 images par seconde, frames per second) est une mesure de la fréquence d'images à laquelle l'écran rafraîchit l'image 60 fois chaque seconde. L'œil humain cesse de distinguer les images discrètes à environ 50–60 Hz grâce à l'effet de persistance rétinienne, faisant de 60fps un seuil naturel de fluidité pour la plupart des utilisateurs.

Chaque image à 60fps a un budget de temps fixe de 16,67 ms. Ce budget inclut tout : du traitement de l'entrée utilisateur au rendu et à l'affichage sur l'écran. Si une opération — physique, animation, rendu d'une scène complexe — dépasse cette limite, la fréquence d'images chute à 30fps ou moins, ce qui est perçu visuellement comme un bégaiement.

Dans le développement mobile, 60fps a longtemps été la limite en raison des contraintes matérielles : la plupart des écrans avant 2017 fonctionnaient à 60 Hz. Avec l'apparition des écrans 90 Hz et 120 Hz, 60fps est devenu la norme inférieure plutôt que l'objectif supérieur. Cependant, pour les applications d'interface, la vidéo et la plupart des jeux occasionnels, 60fps reste l'indicateur cible de performance.

Pourquoi 60 images par seconde

60 Hz est la fréquence du courant alternatif dans les réseaux électriques des États-Unis et du Japon, qui a historiquement déterminé la fréquence de rafraîchissement des premières normes de télévision NTSC. La norme PAL utilisait 50 Hz en raison du réseau européen de 50 Hz. Cette inertie historique s'est transmise aux moniteurs d'ordinateur puis aux écrans mobiles.

Physiologie de la vision et persistance

L'effet de persistance est une propriété de la vision humaine qui retient une image sur la rétine pendant environ 30–50 ms après la disparition du stimulus. À 60fps, une nouvelle image arrive toutes les 16,7 ms — avant que la trace persistante de la précédente ne disparaisse, créant l'illusion d'un mouvement continu. Des études de l'Université de Cardiff (2023) montrent que les pilotes de chasse peuvent distinguer une image individuelle à 220 Hz, mais pour l'utilisateur moyen, la différence entre 60 et 120 Hz est beaucoup moins perceptible qu'entre 30 et 60 Hz.

Normes de l'industrie

Apple a établi 60fps comme norme pour iOS en 2007 avec le premier iPhone et l'a maintenue jusqu'à l'iPhone 13 Pro (2021). Android a historiquement suivi la même norme, bien que les premiers appareils avec 90 Hz (OnePlus 7 Pro, 2019) et 120 Hz (Razer Phone, 2017) soient apparus plus tôt. Aujourd'hui, 60fps est le seuil minimum pour passer la revue de l'App Store et du Google Play pour les applications avec animation, bien que les exigences formelles ne soient pas documentées.

Comment mesurer et contrôler le FPS

La mesure du FPS est la première étape de l'optimisation. Sans métriques objectives, il est impossible de déterminer où la performance est perdue. Les plateformes mobiles fournissent des outils de profilage intégrés et des API logicielles pour mesurer la fréquence d'images en temps réel.

Outils de profilage

Android Studio Profiler et Xcode Instruments sont les principaux outils d'analyse du FPS. Android Profiler affiche le temps de rendu GPU, la fréquence d'images et le Jank (nombre d'images sautées). Xcode Instruments inclut le modèle Core Animation, qui affiche la fréquence d'images, le temps de rendu et le nombre d'appels de dessin. Pour les moteurs de jeu, Unity Profiler et Unreal Insights fournissent des ventilations détaillées du temps par module.

// Android — mesure du FPS via FrameMetrics
window.addOnFrameMetricsAvailableListener(
    { _, frameMetrics ->
        val duration = frameMetrics[FrameMetrics.TOTAL_DURATION]
        val fps = 1000f / (duration / 1_000_000f)
        Log.d("FPS", "Frame duration: ${duration / 1_000_000} ms, FPS: $fps")
    },
    Handler(Looper.getMainLooper())
)

Limitation programmatique du FPS

CADisplayLink sous iOS et Choreographer sous Android sont des mécanismes système qui synchronisent le rendu avec la fréquence de rafraîchissement de l'écran. CADisplayLink appelle une méthode à chaque nouvelle image, en passant un timestamp pour le calcul du délai. Choreographer sous Android fait de même mais prend en charge des callbacks pour différentes phases d'image : entrée, animation, traversée, rendu. Le développeur peut s'abonner à Choreographer.FrameCallback et mesurer le temps entre les images.

Optimisation pour des 60fps stables

60fps stables signifie qu'aucune image ne dépasse le budget de 16,7 ms. Même une image longue par seconde crée un bégaiement notable. L'optimisation se divise en trois niveaux : CPU, GPU et mémoire. Chacun d'eux peut devenir un goulot d'étranglement.

Optimisation CPU : Layout et Measure

La passe de layout est l'un des principaux consommateurs de temps CPU sur Android et iOS. Les hiérarchies de vues complexes, les ConstraintLayouts imbriqués et les drawables lourds créent de longues chaînes de measure et layout. Pour les applications d'interface, utilisez une hiérarchie de vues plate (profondeur ne dépassant pas 3–4 niveaux), remplacez les RecyclerViews imbriqués par ConcatAdapter, et pour les listes sous iOS — utilisez la compositionnalité avec préchargement.

Optimisation GPU : Overdraw et Appels de dessin

L'overdraw est le rendu répété des mêmes pixels. Chaque couche de vue, fond ou image sous un élément transparent augmente le nombre d'opérations de pixels. Sous Android, utilisez Debug GPU Overdraw dans les Options développeur ; sous iOS — Xcode Debug View Hierarchy. Réduisez l'overdraw en supprimant les fonds inutiles et en utilisant des indicateurs opaques : sous Android — @drawable avec android:opaque, sous iOS — isOpaque = true pour UIKit.View.

Les appels de dessin (draw calls) sont le nombre de commandes de rendu envoyées au GPU. Les GPU mobiles modernes gèrent 200–400 appels de dessin par image à 60fps. Dépasser ce nombre entraîne des chutes de performance. Combinez les sprites en atlas de textures, utilisez le regroupement par lots et évitez le rendu individuel de chaque élément via un appel de dessin séparé.

Mémoire et ramasse-miettes

Les gelés GC sont l'une des principales causes de FPS instable dans les applications JVM et Kotlin. Le ramasse-miettes sur Android peut prendre jusqu'à 30–50 ms, provoquant le saut de 2–3 images consécutives. Évitez les allocations dans les boucles d'animation, utilisez des pools d'objets et la pré-allocation de mémoire. Sous iOS, le problème est moins critique grâce à ARC, mais les cycles de rétention et les débordements du pool de libération automatique créent également des micro-bégaiements.

Pour les jeux, 60fps n'est pas seulement une norme mais un avantage concurrentiel. Des études de Newzoo (2024) montrent que les jeux avec un FPS instable inférieur à 60 reçoivent 40 % d'avis négatifs supplémentaires sur Google Play. Unity et Unreal Engine fournissent des profileurs intégrés pour surveiller le temps de rendu : dans Unity c'est Frame Debugger, dans Unreal — GPU Visualizer, qui affichent le temps exact de chaque appel de dessin et shader. Les 60fps stables sont particulièrement importants pour les jeux d'action, où chaque image sautée peut coûter au joueur la réussite d'un niveau.

Au-delà de 60fps et hautes fréquences

Les écrans 90 Hz et 120 Hz changent le niveau de performance cible. Pour les applications fonctionnant sur les appareils ProMotion, le FPS cible peut être de 120, et le budget d'image se réduit à 8,3 ms. Cela nécessite un code deux fois plus efficace, en particulier dans les appels de dessin et le rendu GPU.

L'avantage des hautes fréquences n'est pas seulement la fluidité : 120fps réduit le décalage d'entrée perceptible de 8 à 10 ms, ce qui est crucial pour les jeux et les applications interactives. Cependant, la différence entre 60 et 120fps nécessite une approche individuelle : pour les applications d'interface (défilement, animations), 90fps peut être un compromis optimal entre fluidité et consommation d'énergie, car le rendu de 120 images par seconde consomme 30 à 40 % d'énergie de plus que 60.

Apple fournit une API pour sélectionner la fréquence préférée : preferredFramesPerSecond dans CADisplayLink. Android avant l'API 30 n'offrait pas de contrôle direct sur la fréquence, mais à partir d'Android 12, le développeur peut définir le RefreshRate via WindowManager, en demandant 60, 90 ou 120 Hz selon le type de contenu.