Vitesse de défilement

FPS moyen

Une fréquence d'images fluide et stable est essentielle pour offrir une expérience de jeu de haute qualité sur les appareils Android. Lorsque vous mesurez les performances d'un jeu, vous devez mesurer le FPS moyen comme point de référence pour obtenir une compréhension de base de l'expérience. Vous devez optimiser votre jeu pour atteindre une fréquence d'images moyenne de 60 FPS afin de garantir une expérience de jeu optimale.

FPS P90 et P99 pour la stabilité

Même avec une moyenne de 60 FPS, un jeu peut toujours subir des problèmes intermittents, des micro-saccades et un décalage d'entrée imprévisible, ce qui nuit à l'expérience du joueur.

La stabilité des images est donc tout aussi essentielle que le suivi de la fréquence d'images moyenne. C'est là que vous devez mesurer les métriques de fréquence d'images P90 et P99 comme point de référence cohérent et indicateur de saccades, respectivement. Ces métriques capturent la "fin" des performances pour vous permettre d'optimiser la fluidité de l'expérience du joueur.

Métriques

  • FPS moyen (point de référence) : cette métrique fondamentale fournit un point de référence général pour les performances de votre jeu. Bien qu'il s'agisse d'un benchmark standard, le calcul moyen signifie que les baisses de fréquence d'images intermittentes et les micro-saccades ne peuvent pas être détectées, ce qui le rend insuffisant pour représenter l'expérience du joueur à lui seul.
  • FPS P90 (point de référence cohérent au 10e centile) : cela indique que 90 % de vos images ont dépassé ce point de référence cohérent et que seules les 10 % d'images les plus lentes ont mis plus de temps à s'afficher. Si votre fréquence d'images P90 est élevée et proche de votre moyenne, le jeu fonctionne de manière cohérente pour la grande majorité de la session.
  • FPS P99 (indicateur de saccades au 1er centile) : cela indique que 99 % de vos images ont dépassé cet indicateur de saccades, isolant spécifiquement les 1 % d'images les plus lentes. Cette métrique est essentielle pour détecter les micro-saccades, les retards de chargement des assets et les pics soudains de rendu d'assets lourds qui provoquent des problèmes visibles.

Exemples

En comparant votre FPS moyen aux métriques P90 et P99, vous pouvez diagnostiquer avec précision le comportement sous-jacent d'un jeu.

Scénario 1 : courbe optimale (jeu optimisé)

  • Moyenne : 60 FPS (16,6 ms)
  • P90: 58 FPS (17,2 ms)
  • P99: 52 FPS (19,2 ms)
  • Analyse : les métriques sont étroitement regroupées. Le jeu est incroyablement fluide et cohérent. Il n'y a pas de micro-saccades, et même les 1% d'images les plus lentes sont à peine perceptibles à l'œil nu.

Scénario 2 : goulot d'étranglement de la charge (lié au processeur/GPU)

  • Moyenne : 45 FPS (22,2 ms)
  • P90: 40 FPS (25,0 ms)
  • P99: 38 FPS (26,3 ms)
  • Analyse : la fréquence d'images moyenne est inférieure, mais de manière cohérente. Le P99 ne baisse pas de manière drastique par rapport à la moyenne. Cela indique que le système est essentiellement submergé par les paramètres graphiques ou les contraintes de résolution. Le jeu ne semble pas saccader, mais plutôt lent. La réduction des paramètres graphiques permet généralement d'augmenter ces métriques de manière uniforme.

Scénario 3 : 60 FPS instables (compilation de nuanceurs / saccades de streaming d'éléments) )

  • Moyenne : 60 FPS (16,6 ms)
  • P90: 45 FPS (22,2 ms)
  • P99: 15 FPS (66,6 ms)
  • Analyse : il s'agit du pire scénario. Bien que la fréquence d'images moyenne semble excellente, le P99 révèle un problème critique. Un P99 de 66,6 ms signifie que le jeu se fige complètement pendant plusieurs images à la fois. Cela indique des valeurs aberrantes importantes, généralement causées par des goulots d'étranglement du processeur, des retards de streaming d'assets (par exemple, une RAM ou un stockage lents) ou des problèmes causés par la compilation de shaders.

Mesure

Pour mesurer efficacement le FPS moyen, le P90 et le P99, vous pouvez utiliser les deux méthodes suivantes. La première consiste à analyser les traces système à l'aide de l'Android Performance Analyzer (APA), un outil de profilage des performances. La deuxième consiste à utiliser la commande adb dumpsys SurfaceFlinger --timestats existante.

1. Mesurer à l'aide de l'APA

À l'aide de l'APA, vous pouvez enregistrer une trace système et analyser précisément les données d'images à l'aide de requêtes SQL. Pour mesurer vos métriques, procédez comme suit :

  1. Capturer la trace avec l'APA : exécutez votre jeu et utilisez l'APA pour capturer une trace système pendant le segment que vous souhaitez analyser (par exemple, un point pendant le jeu où vous soupçonnez des baisses de fréquence d'images). Une fois l'appareil connecté et l'enregistrement de la trace terminé, les données de trace se chargent dans l'interface de l'APA.

    Écran de capture de trace ou écran de trace chargé

  2. Cliquez sur l'onglet SQL dans l'APA : une fois l'écran d'analyse de trace ouvert, cliquez sur l'onglet SQL dans la zone de navigation supérieure ou latérale de l'interface utilisateur pour ouvrir l'environnement du processeur de trace, où vous pouvez interroger directement les données.

  3. Collez la requête SQL dans l'onglet SQL de l'APA : copiez la requête SQL suivante et collez-la dans le champ de saisie de la requête. Cette requête identifie le processus SurfaceFlinger, calcule les intervalles d'images en fonction des codes temporels de mise à jour de l'affichage réels et dérive le FPS moyen, le FPS des 10 % inférieurs (P90) et le FPS des 1 % inférieurs (P99).

    WITH target_process AS (
-- 1. Get SurfaceFlinger process ID where frames were identified in debugging step 3
SELECT upid
FROM process
WHERE name = '/system/bin/surfaceflinger'
),
actual_present_times AS (
-- 2. Calculate the hardware display timestamps when SurfaceFlinger actually updated the screen
SELECT
    (ts + dur) AS present_ts
FROM actual_frame_timeline_slice
WHERE upid IN (SELECT upid FROM target_process)
    AND dur > 0
),
present_intervals AS (
-- 3. Calculate intervals between physical screen refreshes
SELECT
    (LEAD(present_ts) OVER (ORDER BY present_ts ASC) - present_ts) / 1000000.0 AS p2p_ms
FROM actual_present_times
),
valid_intervals AS (
-- 4. Filter for valid frame intervals
SELECT p2p_ms
FROM present_intervals
WHERE p2p_ms IS NOT NULL AND p2p_ms > 0
),
ordered_frames AS (
-- 5. Sort in ascending order to calculate percentiles
SELECT
    p2p_ms,
    ROW_NUMBER() OVER (ORDER BY p2p_ms ASC) AS row_num,
    COUNT(1) OVER () AS total_frames
FROM valid_intervals
)
-- 6. Output final metrics
SELECT
(SELECT COUNT(1) FROM valid_intervals) AS total_presented_frames,
ROUND(1000.0 / NULLIF((SELECT AVG(p2p_ms) FROM valid_intervals), 0), 2) AS average_fps,
ROUND(1000.0 / NULLIF((SELECT p2p_ms FROM ordered_frames WHERE row_num = CAST(total_frames * 0.90 AS INT)), 0), 2) AS low_10_fps,
ROUND(1000.0 / NULLIF((SELECT p2p_ms FROM ordered_frames WHERE row_num = CAST(total_frames * 0.99 AS INT)), 0), 2) AS low_1_fps;

  4. Cliquez sur "Exécuter la requête" : cliquez sur le bouton Exécuter la requête (ou sur l'icône d'exécution) à côté du champ de saisie de la requête. Une fois l'exécution de la requête terminée, le nombre total d'images mesurées (total_presented_frames), la fréquence d'images moyenne (average_fps), le FPS des 10% inférieurs (low_10_fps) et le FPS des 1% inférieurs (low_1_fps) s'affichent dans un tableau du volet des résultats.

    Écran affichant la requête SQL exécutée et les quatre métriques résultantes affichées dans un tableau

2. Mesurer à l'aide d'adb (dumpsys SurfaceFlinger)

Pour mesurer efficacement le FPS moyen, le P90 et le P99, vous pouvez utiliser la commande Android dumpsys surfaceflinger timestats. Cet outil fournit le FPS moyen et un histogramme de timing presentToPresent pour toutes les couches en cours de rendu. Le temps presentToPresent d'une image correspond à l'intervalle entre l'image actuelle et l'image précédente en cours de dessin.

Voici les instructions détaillées pour collecter et calculer ces métriques pour votre jeu :

  1. Commencer la capture : exécutez la commande suivante avec les indicateurs d'activation et d'effacement pour commencer à capturer des informations :

    adb shell dumpsys SurfaceFlinger --timestats -clear -enable

  2. Vider les informations : lorsque le jeu a été joué suffisamment longtemps, exécutez à nouveau la commande avec l'indicateur de vidage pour afficher les informations :

    adb shell dumpsys SurfaceFlinger --timestats -dump

  3. Filtrer par couche : les informations vidées fournissent des données pour toutes les couches rendues par SurfaceFlinger. Vous devez trouver la section correspondant à votre jeu en filtrant en fonction de layerName (par exemple, layerName = SurfaceView[com.example.yourgame...]).

    layerName = SurfaceView[com.google.test/com.devrel.MainActivity]@0(BLAST)#132833

  4. Identifier le FPS moyen : le FPS moyen de chaque couche est calculé automatiquement et s'affiche directement dans la sortie de vidage (par exemple, averageFPS = 30.179).

    ...
averageFPS = 30.179
...

  5. Calculer le FPS P90 et P99 : pour trouver les métriques P90 et P99, vous devez analyser le totalFrames et l'histogramme de timing presentToPresent fournis dans le vidage.

    totalFrames = 1000
...
presentToPresent histogram is as below:
0ms=0 1ms=0 2ms=0 3ms=0 4ms=0 5ms=0 6ms=0 7ms=0 8ms=0 9ms=0 10ms=0 11ms=0 12ms=0
13ms=0 14ms=0 15ms=0 16ms=850 17ms=0 18ms=0 19ms=0 20ms=0 21ms=0 22ms=0 23ms=0
24ms=0 25ms=0 26ms=0 27ms=0 28ms=0 29ms=0 30ms=0 31ms=0 32ms=0 33ms=100 34ms=0
36ms=0 38ms=0 40ms=0 42ms=0 44ms=0 46ms=0 48ms=0 50ms=35 54ms=0 58ms=0 62ms=0
66ms=10 70ms=0 74ms=0 78ms=0 82ms=0 86ms=0 90ms=0 94ms=0 98ms=0 102ms=5 106ms=0
110ms=0 114ms=0 118ms=0 122ms=0 126ms=0 130ms=0 134ms=0 138ms=0 142ms=0 146ms=0
150ms=0 200ms=0 250ms=0 300ms=0 350ms=0 400ms=0 450ms=0 500ms=0 550ms=0 600ms=0
650ms=0 700ms=0 750ms=0 800ms=0 850ms=0 900ms=0 950ms=0 1000ms=0

    A. Exemple conceptuel (tableau de distribution cumulée) Supposons que votre session de jeu ait enregistré un nombre totalFrames de 1 000. Pour trouver le P90 et le P99, vous calculez les seuils en millisecondes où le nombre d'images cumulé atteint respectivement 900 images (90%) et 990 images (99%), en comptant à partir du bucket de millisecondes le plus bas.

    Temps de rendu (ms) Nombre d'images (histogramme) Nombre d'images cumulé État / Calcul du centile
    16ms 850 850 85,0%
    33ms 100 950 95,0%
    (Objectif P90 de 900 atteint ! → 1 000/33 = 30,3 FPS)
    50ms 35 985 98,5%
    66ms 10 995 99,5%
    (Objectif P99 de 990 atteint ! → 1 000/66 = 15,1 FPS)
    102ms 5 1 000 100%

    B. Logique d'implémentation (pseudocode) Si vous automatisez cette analyse à l'aide d'un script Python ou d'un analyseur de journaux, la logique d'extraction des valeurs P90 et P99 de l'histogramme peut être implémentée comme suit :

    # Define target thresholds based on total frame count
p90_target = totalFrames * 0.90
p99_target = totalFrames * 0.99

cumulative_frames = 0
p90_fps = None
p99_fps = None

# Iterate through the parsed SurfaceFlinger histogram data (sorted by millisecond)
for ms_bucket, frame_count in present_to_present_histogram:
    cumulative_frames += frame_count

    # Capture P90 when cumulative frames cross the 90% threshold
    if p90_fps is None and cumulative_frames >= p90_target:
        p90_fps = 1000 / ms_bucket

    # Capture P99 when cumulative frames cross the 99% threshold
    if p99_fps is None and cumulative_frames >= p99_target:
        p99_fps = 1000 / ms_bucket
        break # Optimization: stop iterating once both targets are found

  6. Arrêter la capture : après avoir collecté toutes les informations nécessaires, vous devez désactiver les statistiques temporelles à l'aide de l'indicateur de désactivation :

    adb shell dumpsys SurfaceFlinger --timestats -disable

Sessions lentes

Les sessions lentes identifient les problèmes de performances réels et généralisés. Une session est "lente" si plus de 25% des images passent en dessous d'un seuil (par exemple, 20 FPS). Bien qu'utile pour détecter les problèmes critiques de compilation, cette métrique seule ne peut pas garantir une expérience durable et de haute qualité. Un jeu peut éviter le seuil de session lente, mais toujours souffrir de micro-saccades qui compromettent une expérience fluide à 60 FPS.

Bien que les deux soient dérivés des temps de rendu, les termes "Session lente" et "Fréquence d'images" ont des rôles différents. Les métriques FPS moyen, P90 et P99 mesurent la qualité et la durabilité des performances, en détectant les baisses instantanées et le rythme incohérent que la métrique de session lente peut ignorer.

Conclusion

Une optimisation réussie des performances nécessite une stratégie complète. Les développeurs doivent utiliser les sessions lentes comme radar principal pour détecter les dégradations importantes des performances, puis examiner le FPS moyen, le P90 et le P99 pour diagnostiquer les causes sous-jacentes et vérifier la fluidité réelle du jeu. En intégrant ces métriques, vous pouvez vous assurer que votre application offre une expérience utilisateur durable et exceptionnelle.

Ressources supplémentaires

Pour en savoir plus sur les techniques de profilage avancées, l'implémentation de l'API Frame Pacing et les stratégies d'optimisation spécifiques au moteur, consultez la documentation officielle pour les développeurs Android :

  • Android Vitals : sessions lentes : découvrez comment Google Play mesure et signale les périodes prolongées d'affichage lent, ce qui a un impact direct sur l'expérience utilisateur. Une "session lente" est définie comme une session utilisateur où plus de 25% des images sont lentes (par exemple, plus de 50 ms, ce qui équivaut à 20 FPS).
  • Développeurs Android : optimiser les performances des jeux : explorez le hub central pour l'optimisation des jeux Android. Ce guide complet couvre les bonnes pratiques, les outils de profilage (comme l'APA et Perfetto) pour vous aider à maximiser les performances globales de votre jeu.