Lorsqu'une animation est lancée dans Android, l'écran passe souvent à la fréquence d'actualisation maximale pour garantir une expérience fluide. Pour les petites animations telles que les barres de progression et les visualiseurs audio, ce taux de rafraîchissement élevé est inutile et entraîne une consommation d'énergie élevée.
À partir d'Android 15, avec la fonctionnalité de taux de rafraîchissement adaptatif (ARR), les appareils compatibles peuvent réduire la durée de résidence à un taux de rafraîchissement élevé sur deux fronts:
- Grâce aux nouvelles optimisations de gestion de la fréquence d'images de la plate-forme, les applications peuvent afficher une fréquence d'images inférieure par défaut et n'augmenter la fréquence d'images que si nécessaire.
- La fréquence d'actualisation de l'écran correspond dynamiquement au taux de rendu du contenu sans à-coups.
Bien que la plupart des applications devraient bénéficier de l'ARR sans aucune modification, vous pouvez également remplacer le comportement par défaut du frame rate si nécessaire.
Cette page décrit les éléments suivants:
- Méthode permettant de déterminer la fréquence d'images de chaque vue.
- Règle générale sur la façon dont l'ARR détermine la fréquence d'images.
- Comment remplacer manuellement le comportement par défaut de la fréquence d'images.
Mécanisme de vote pour les vues
Dans le système de vues d'Android, chaque vue de la hiérarchie de l'UI peut exprimer sa fréquence d'images préférée. Ces préférences sont collectées et combinées pour déterminer une fréquence d'images finale pour chaque frame. Cela se fait via un mécanisme de vote où chaque vue vote en fonction de son attribut de fréquence d'images, qui peut être une catégorie ou un taux spécifique. Les vues votent généralement lorsqu'elles sont dessinées ou mises à jour. Ces votes sont combinés pour déterminer un taux de trames final, qui est ensuite envoyé à la couche de niveau inférieur en tant qu'indice de rendu.
Actuellement, la plupart des vues utilisent par défaut une fréquence d'images "Normale", qui est souvent définie sur 60 Hz. Pour des fréquences d'images plus élevées, vous pouvez utiliser des API spécifiques pour personnaliser vos préférences, le système sélectionnant généralement la fréquence d'images la plus élevée. Pour en savoir plus sur l'utilisation de ces API, consultez la section Définir la fréquence d'images ou la catégorie. Les règles générales concernant les fréquences d'images sont décrites dans la section Règle générale d'ARR.
Catégories de fréquence d'images
Dans la classe View
, différentes catégories de fréquence d'images peuvent être utilisées dans le vote. Voici la description de chaque catégorie:
REQUESTED_FRAME_RATE_CATEGORY_DEFAULT
: cette valeur peut être définie pour rétablir le comportement par défaut, ce qui indique que cette vue ne contient aucune donnée sur la fréquence d'images.REQUESTED_FRAME_RATE_CATEGORY_NO_PREFERENCE
: la vue n'a aucune influence explicite sur la fréquence d'images. Cela signifie que, même si la vue est active, le framework ne la tiendra pas compte pour déterminer la fréquence d'images.REQUESTED_FRAME_RATE_CATEGORY_NORMAL
: indique une fréquence d'images moyenne adaptée aux animations qui ne nécessitent pas de fréquence d'images plus élevée ou qui ne bénéficient pas d'une fluidité élevée. Il s'agit généralement de 60 Hz ou d'une fréquence proche.REQUESTED_FRAME_RATE_CATEGORY_HIGH
: indique un débit d'images adapté aux animations qui nécessitent un débit d'images élevé, ce qui peut améliorer la fluidité, mais aussi augmenter la consommation d'énergie.
Une vue ne vote que si elle doit être redessinée. Le débit d'images final est déterminé par le vote le plus élevé. Par exemple, si tous les votes sont pour "Normal", "Normal" est sélectionné. Lorsque les votes "Normal" et "Élevé" sont effectués, "Élevé" est choisi.
Fréquence d'images
En plus des catégories de fréquence d'images, une vue peut également spécifier une fréquence d'images préférée, par exemple 30, 60 ou 120 Hz. Lorsque plusieurs votes sont exprimés pour la fréquence d'images, la fréquence d'images finale est déterminée par les règles suivantes:
- Multiples les uns des autres: si les fréquences d'images votées sont des multiples les unes des autres, la valeur la plus élevée est choisie. Par exemple, si deux votes sont exprimés (30 Hz et 90 Hz), 90 Hz est sélectionné comme fréquence d'images finale.
- Ne sont pas des multiples l'un de l'autre :
- Si l'un des votes est supérieur à 60 Hz, il est considéré comme un vote "Élevé".
- Si tous les votes sont de 60 Hz ou moins, ils sont comptabilisés comme un vote "Normal".
De plus, si les valeurs et les catégories de fréquence d'images sont combinées, la valeur la plus élevée détermine généralement la fréquence de rendu finale. Par exemple, avec une combinaison d'un vote à 60 Hz et d'un vote "Élevé", ou d'un vote à 120 Hz et d'un vote "Normal", le taux de rendu est généralement défini sur 120 Hz.
En plus des votes d'une application, d'autres indices peuvent également être envoyés à la couche de niveau inférieur à partir de différents composants du même frame. Beaucoup d'entre eux peuvent provenir de composants d'UI système, tels que la nuance de notification, la barre d'état, la barre de navigation, etc. Les valeurs de fréquence d'images finales sont déterminées en fonction des votes de plusieurs composants.
Définir la fréquence d'images ou la catégorie
Dans certains cas, vous pouvez définir une fréquence d'images préférée pour une vue. Par exemple, vous pouvez définir la fréquence d'images préférée sur "Élevée" pour une vue afin d'augmenter la fréquence d'images si une animation semble saccadée. De plus, si une animation lente ou statique est appliquée à une vidéo (généralement lue à 24 ou 30 Hz), vous pouvez préférer que l'animation s'exécute à une fréquence inférieure à "Normal" pour réduire la consommation d'énergie.
Vous pouvez utiliser les API setRequestedFrameRate()
et getRequestedFrameRate()
pour désigner la fréquence d'images ou la catégorie préférée d'une vue donnée.
Kotlin
// Set the preferred frame rate category to a View // set the frame rate category to NORMAL view.requestedFrameRate = View.REQUESTED_FRAME_RATE_CATEGORY_NORMAL // set the frame rate category to HIGH view.requestedFrameRate = View.REQUESTED_FRAME_RATE_CATEGORY_HIGH // reset the frame rate category view.requestedFrameRate = View.REQUESTED_FRAME_RATE_CATEGORY_DEFAULT // Set the preferred frame rate to a View // set the frame rate to 30 view.requestedFrameRate = 30f // set the frame rate to 60 view.requestedFrameRate = 60f // set the frame rate to 120 view.requestedFrameRate = 120f
Java
// Set the preferred frame rate category to a View // set the frame rate category to NORMAL view.setRequestedFrameRate(View.REQUESTED_FRAME_RATE_CATEGORY_NORMAL); // set the frame rate category to HIGH view.setRequestedFrameRate(View.REQUESTED_FRAME_RATE_CATEGORY_HIGH); // reset the frame rate category view.setRequestedFrameRate(View.REQUESTED_FRAME_RATE_CATEGORY_DEFAULT); // Set the preferred frame rate to a View // set the frame rate to 30 view.setRequestedFrameRate(30); // set the frame rate to 60 view.setRequestedFrameRate(60); // set the frame rate to 120 view.setRequestedFrameRate(120);
Pour voir un exemple d'utilisation, consultez la section sur la fonction TextureView
.
Règles générales concernant les ARR
Dans la section précédente, nous avons expliqué que la plupart des animations sont affichées à 60 Hz par défaut, car la fréquence d'images par défaut de chaque vue est "Normal". Toutefois, il existe des exceptions où la fréquence d'images est augmentée à "Élevé" pour assurer des animations plus fluides.
La règle générale d'ARR est la suivante:
- Amélioration de la réactivité tactile: lorsqu'un événement tactile (
MotionEvent.ACTION_DOWN
) est détecté, la fréquence d'actualisation est définie sur "Élevé" pendant un certain temps après la libération de l'écran tactile pour maintenir la réactivité. - Mouvements de balayage: les mouvements de balayage sont traités différemment. La fréquence d'actualisation diminue progressivement à mesure que la vitesse de balayage ralentit. Pour en savoir plus sur ce comportement, consultez la section Amélioration du défilement.
- Lancement de l'application et transitions de fenêtre: la fréquence d'actualisation est également augmentée pendant un certain temps lors des lancements d'applications, de l'initialisation des fenêtres et des transitions de fenêtre pour garantir une expérience visuelle fluide.
- Animations: les animations impliquant des mouvements ou des changements de taille reçoivent automatiquement une fréquence d'actualisation plus élevée pour améliorer la fluidité lorsque la position ou la taille d'une vue change.
SurfaceView
etTextureView
: les fréquences d'images définies explicitement pourTextureView
etSurfaceView
sont respectées et appliquées en conséquence.
Activer et désactiver l'amélioration tactile
Vous pouvez activer et/ou désactiver l'amélioration tactile au niveau de Window
. Par défaut, lorsqu'un utilisateur appuie sur l'écran et le retire, le taux de rendu augmente pendant un certain temps. Les API setFrameRateBoostOnTouchEnabled()
et getFrameRateBoostOnTouchEnabled()
vous permettent d'empêcher l'augmentation de la fréquence de rendu lorsqu'un Window
spécifique est touché.
Kotlin
// disable touch boost on a Window window.isFrameRateBoostOnTouchEnabled = false // enable touch boost on a Window window.isFrameRateBoostOnTouchEnabled = true // check if touch boost is enabled on a Window val isTouchBoostEnabled = window.isFrameRateBoostOnTouchEnabled
Java
// disable touch boost on a Window window.setFrameRateBoostOnTouchEnabled(false) // enable touch boost on a Window window.setFrameRateBoostOnTouchEnabled(true) // check if touch boost is enabled on a Window window.getFrameRateBoostOnTouchEnabled()
Amélioration du défilement
L'un des principaux cas d'utilisation de l'optimisation dynamique de la fréquence d'images est d'améliorer l'expérience de défilement (fling). De nombreuses applications s'appuient fortement sur le balayage vers le haut pour afficher du nouveau contenu. L'amélioration du défilement ARR ajuste dynamiquement la fréquence d'actualisation à mesure que le geste de balayage ralentit, réduisant progressivement la fréquence d'images. Cela permet un rendu plus efficace tout en conservant un défilement fluide.
Cette amélioration s'applique spécifiquement aux composants d'interface utilisateur à défilement, y compris ScrollView
, ListView
et GridView
, et n'est pas nécessairement disponible pour toutes les implémentations personnalisées.
La fonctionnalité de défilement ARR est disponible pour RecyclerView
et NestedScrollView
. Pour activer cette fonctionnalité dans votre application, passez aux dernières versions de AndroidX.recyclerview
et AndroidX.core
. Pour en savoir plus, consultez le tableau suivant.
Bibliothèque |
Version |
|
1.4.0 |
|
1.15.0 |
Définir les informations de vitesse
Si vous disposez d'un composant à faire défiler personnalisé et que vous souhaitez profiter de la fonctionnalité de défilement, appelez setFrameContentVelocity()
sur chaque frame lors du défilement fluide ou du glissement d'un geste vif. Voici un exemple:
Kotlin
// set the velocity to a View (1000 pixels/Second) view.frameContentVelocity = 1000f // get the velocity of a View val velocity = view.frameContentVelocity
Java
// set the velocity to a View view.setFrameContentVelocity(velocity); // get the velocity of a View final float velocity = view.getFrameContentVelocity()
Pour obtenir d'autres exemples, consultez RecyclerView
et ScrollView
. Pour définir correctement la vitesse, calculez manuellement la vitesse du contenu (pixels par seconde) si les informations requises ne peuvent pas être obtenues à partir de Scroller
ou de OverScroller
.
Notez que si setFrameContentVelocity()
et getFrameContentVelocity()
sont appelés sur des vues qui ne sont pas des composants à faire défiler, ils n'auront aucun effet, car le mouvement déclenche automatiquement une augmentation de la fréquence d'images en fonction de la stratégie actuelle.
Les informations sur la vitesse sont essentielles pour ajuster le taux de rendu. Prenons l'exemple du geste de balayage. Au début, la vitesse d'un fling peut être élevée, ce qui nécessite un taux de rendu plus élevé pour assurer la fluidité. À mesure que le geste progresse, la vitesse diminue, ce qui permet de réduire la fréquence de rendu.
Activer et désactiver l'ARR
L'ARR est activé par défaut pour améliorer l'efficacité énergétique. Vous pouvez désactiver cette fonctionnalité, mais nous vous déconseillons de le faire, car l'application consommerait plus d'énergie. N'envisager de désactiver cette fonctionnalité que si vous rencontrez des problèmes ayant un impact significatif sur l'expérience utilisateur.
Pour activer ou désactiver l'ARR, utilisez l'API setFrameRatePowerSavingsBalanced()
sur un Window
ou l'API isFrameRatePowerSavingsBalanced()
via votre fichier styles.xml
.
L'extrait de code suivant montre comment activer ou désactiver l'ARR sur un Window
:
Kotlin
// disable ARR on a Window window.isFrameRatePowerSavingsBalanced = false // enable ARR on a Window window.isFrameRatePowerSavingsBalanced = true // check if ARR is enabled on a Window val isAdaptiveRefreshRateEnabled = window.isFrameRatePowerSavingsBalanced
Java
// disable ARR on a Window window.setFrameRatePowerSavingsBalanced(false) // enable ARR on a Window window.setFrameRatePowerSavingsBalanced(true) // check if ARR is enabled on a Window window.isFrameRatePowerSavingsBalanced()
Pour désactiver l'ARR via le fichier styles.xml
, ajoutez l'élément suivant à votre style dans res/values/styles.xml
:
<style name="frameRatePowerSavingsBalancedDisabled">
<item name="android:windowIsFrameRatePowerSavingsBalanced">false</item>
</style>