Partage de technologie

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Présentation des outils liés à la collecte et à l'analyse des performances

Il existe de nombreux outils pour collecter, analyser et afficher les données de performances des applications mobiles, qui peuvent être grossièrement divisées dans les catégories suivantes. Par exemple, les outils de performances mobiles capables de collecter plusieurs indicateurs de performances, perfdog et Solopi, parmi lesquels Solopi est open source et pefdog est un outil commercial. Des outils capables d'effectuer une analyse de crash, tels que l'outil commercial Firebase Crashlytics et l'outil open source Sentry. Si vous devez analyser des données liées au réseau, vous pouvez utiliser Charles ou Wireshark. Il existe également des outils complets de gestion des performances, tels que Dynatrace. D'une manière générale, les capacités, la précision et l'expérience utilisateur des outils commerciaux sont nettement meilleures que celles des outils open source. En tant qu'étude et recherche personnelles, je ne peux partir que d'outils open source. Par conséquent, lors de la rédaction de ce blog, nous utiliserons également des outils open source comme exemples.

Outil de test de performances mobiles：
PerfDog : Un outil pour surveiller les performances des applications, le processeur, la mémoire, la consommation d'énergie et d'autres données, prenant en charge les tests de performances et la surveillance en temps réel des applications mobiles.
Solopi : se concentre sur les tests et la surveillance des performances des applications mobiles, y compris la surveillance en temps réel de la fréquence d'images, du processeur, de la mémoire et d'autres indicateurs.

Outil d'analyse des accidents：
Firebase Crashlytics : un puissant outil de reporting et d'analyse des plantages fourni par Google qui peut surveiller les plantages des applications en temps réel.
Sentry : un outil open source de suivi des erreurs qui prend en charge plusieurs plates-formes, y compris le rapport d'erreurs et la surveillance des performances des applications mobiles.

Outils de test des performances du réseau：
Charles Proxy : un outil proxy de débogage réseau qui capture et analyse les données de demande et de réponse réseau pour les applications mobiles.
Wireshark : un outil d'analyse de réseau open source qui prend en charge la capture et l'analyse des paquets réseau des applications mobiles.

Outils APM(Gestion des performances des applications) :
Dynatrace : une solution cloud native de surveillance des performances complète qui prend en charge la surveillance des performances des applications mobiles et l'analyse de l'expérience utilisateur.

Quelles mesures de performance sont collectées et comment

  Avant d'effectuer une analyse des performances, vous devez d'abord comprendre la signification de chaque indicateur de performance. En prenant comme exemple les indicateurs de performance collectés par Solopi, examinons les indicateurs courants de performance des applications mobiles et comment ces indicateurs peuvent être collectés.

Fréquence d'images

La formule de calcul de la fréquence d'images est la suivante :Fréquence d'images = nombre d'images dessinées/période de temps,La fréquence d'images cible pour la plupart des développeurs d'applications et de jeux est60 images par seconde ( images/seconde), pourquoi la fréquence d'images cible est-elle de 60 FPS ? Étant donné que le taux de rafraîchissement de l'écran de la plupart des smartphones et tablettes modernes est de 60 Hz, tant que la fréquence d'images atteint 60 FPS, c'est-à-dire que le nombre d'images dessinées par seconde est de 60, les effets visuels de l'utilisateur seront plus fluides et il n'y aura pas de décalage. Le minimum ne peut pas être inférieur à 30 FPS. En effet, le moniteur affiche à plusieurs reprises l'image de l'image précédente en attendant une nouvelle image, ce qui rend l'image floue. Les valeurs élevées peuvent atteindre 90 FPS (par exemple, pour les appareils avec des taux de rafraîchissement élevés).

Comment collecter des informations sur la fréquence d'images

  Il existe deux manières de collecter la fréquence d'images. La première consiste à utiliser la classe Choreographer pour collecter des statistiques de fréquence d'images. Cela nécessite l'écriture de code dans l'application et ne peut collecter que les informations de fréquence d'images de l'application.Une autre façon est d'utiliser outil gfxinfo. En prenant Solopi comme exemple, le délai d'attente d'une seconde est également calculé via les informations de l'outil gfxinfo, et la fréquence d'images réelle est déduite. Par conséquent, lorsqu'elle est proche de l'arrêt, une partie de la fréquence d'images peut être affichée de manière incorrecte. Il est recommandé d'effectuer des tests de fréquence d'images dans des scénarios dynamiques tels que le glissement ou le changement de page. La méthode gfxinfo peut collecter des informations sur la fréquence d'images de toutes les applications et est très appropriée comme outil de collecte de données de performances. Par conséquent, nous nous concentrons également ici sur la façon de collecter des informations sur la fréquence d'images via gfxinfo.

Il existe deux étapes principales pour collecter des informations sur la fréquence d'images.la première étape: Obtenez les informations gfxinfo via la commande adb,Étape 2 : Analysez les informations et calculez les informations de fréquence d'images. Le contenu des informations de gfxinfo est à peu près le suivant :

Statistiques depuis : heure de début des statistiques, l'unité est la nanoseconde.
Nombre total d'images rendues : nombre total d'images rendues.
Images janky : nombre d'images janky, c'est-à-dire le nombre d'images dépassant 16 ms (intervalle de rafraîchissement de 60 images par seconde).
Pourcentage d’images janky : le rapport entre les images janky et le nombre total d’images.
90e centile : 90e centile, indiquant que 90 % des images ont des temps de rendu inférieurs à cette valeur (en millisecondes).
95e centile : 95e centile, indiquant que 95 % des images ont des temps de rendu inférieurs à cette valeur (en millisecondes).
99e centile : 99e centile, indiquant que 99 % des images ont des temps de rendu inférieurs à cette valeur (en millisecondes).
Number Missed Vsync : nombre de synchronisations verticales non synchronisées, c'est-à-dire le nombre de pertes d'images causées par un échec de rendu dans le temps.
Nombre Latence d'entrée élevée : le nombre de retards d'entrée élevés indique le nombre de retards causés par un temps de traitement des événements d'entrée trop long.
Nombre de threads d'interface utilisateur lents : nombre de fois où le thread d'interface utilisateur a répondu lentement, c'est-à-dire le nombre de fois où le thread d'interface utilisateur a mis trop de temps à traiter.

En prenant Solopi comme exemple, la fréquence d'images est déduite du délai d'expiration dans les informations gfxinfo. Pour le code du projet spécifique, vous pouvez afficher le code source de Solopi.

taux de décalage/nombre de décalages

Nombre de gels : Pendant la période de test, le nombre de périodes pendant lesquelles la fréquence d'images est détectée comme étant inférieure au seuil. Chaque fois que la fréquence d’images tombe en dessous du seuil pendant un certain temps, cela est considéré comme un bégaiement. Le seuil ici peut être personnalisé. Par exemple, s'il est inférieur de 60 FPS à la fréquence d'images cible, il peut être enregistré comme un gel. Autrement dit, si le temps de rendu de l'image est supérieur à 16 ms, il est calculé comme étant bloqué.

taux de décalage : Le pourcentage du temps de congélation par rapport à la durée totale du test. Supposons que lors d'un test, l'application ait fonctionné pendant 120 secondes, pendant lesquelles la fréquence d'images était inférieure à 16 FPS 4 fois au total, et le temps de latence total était de 8 secondes, alors : le nombre de latences : 4 fois. Taux de bégaiement : 8/120*100 %=6,7 %. Dans le gfxinfo ci-dessus, vous trouverez également des informations sur le taux de décalage.

processeur/mémoire

  En prenant Solopi comme exemple, le processeur inclut le pourcentage d'utilisation du processeur du processus où se trouve l'activité de niveau supérieur de l'application et le pourcentage d'utilisation global du processeur pour les applications à processus unique, ces données représentent l'utilisation du processeur de l'application. Dans les applications de processus multi-processus, ces données représentent l'utilisation du processeur de l'interface utilisateur de niveau supérieur. Lorsqu'un changement de processus se produit, Soloπ peut automatiquement basculer vers de nouvelles données de processus.

import subprocess
 
def get_memory_info(pid):
    try:
        # Run adb shell command to read /proc/<pid>/statm
        command = f"adb shell cat /proc/{pid}/statm"
        result = subprocess.check_output(command, shell=True)
        statm_data = result.decode('utf-8').strip().split()
        
        # Parse statm data
        size, resident, shared, text, lib, data, dt = map(int, statm_data)
        
        memory_info = {
            'size': size,         # total program size (pages)
            'resident': resident, # resident set size (pages)
            'shared': shared,     # shared pages (pages)
            'text': text,         # text (code) size (pages)
            'lib': lib,           # library (unused since Linux 2.6; always 0)
            'data': data,         # data + stack (pages)
            'dt': dt              # dirty pages (unused since Linux 2.6; always 0)
        }
        
        return memory_info
    except subprocess.CalledProcessError as e:
        print(f"Error executing command: {e}")
        return None
    except Exception as e:
        print(f"Error: {e}")
        return None
 
# Replace with your application's PID
pid = '12345'
memory_info = get_memory_info(pid)
if memory_info:
    print(f"Memory info for PID {pid}:")
    print(f"Size: {memory_info['size']} pages")
    print(f"Resident set size (RSS): {memory_info['resident']} pages")
    print(f"Shared pages: {memory_info['shared']} pages")
    print(f"Text (code) size: {memory_info['text']} pages")
    print(f"Data + stack size: {memory_info['data']} pages")

Temps de réponse

  Prenons Solopi comme exemple, Contient les données de temps de réponse et de temps d'actualisation pour les clics sur les applications. Appartient aux données de dimension d'application. Le temps écoulé entre le clic de l'utilisateur et la première fois que le système émet une mise à jour de l'interface est le temps de réponse, et le temps jusqu'à ce que le système arrête de rafraîchir l'interface est le temps de rafraîchissement. La logique du comptage du temps de réponse est de diviser l'enregistrement d'écran en images. Selon le site officiel de Solopi, il reconnaît automatiquement l'image de début et l'image de fin pour compter le temps de réponse. Lorsque vous utilisez réellement Solopi, vous constaterez que la page statistique. le temps de réponse n'est pas correct. Par exemple, lorsque l'utilisateur clique sur Démarrer, lorsque vous cliquez sur la page de l'application, le temps de fonctionnement de la vitesse manuelle de quelqu'un au milieu est inclus et cette partie est comptée dans le temps de réponse. Par conséquent, si vous souhaitez calculer le temps de réponse de la page préparée, il est plus précis d'enregistrer uniquement l'écran et d'identifier manuellement les images de début et de fin de la page. Les étapes spécifiques à l'enregistrement des images d'écran sont les suivantes :

Ce qui précède est une compréhension de la signification des indicateurs de performance courants dans les applications mobiles, ainsi que des instructions détaillées sur la manière de les collecter. Concernant les crashs, etc., nous le présenterons en détail dans un prochain blog.