Les applications lentes frustrent les utilisateurs, ce qui entraîne de mauvaises critiques ou des clients qui se tournent vers la concurrence. Malheureusement, voir et résoudre les problèmes de performances peut prendre beaucoup de temps.
La plupart des développeurs utilisent des profileurs dans des IDE comme Android Studio ou Xcode pour rechercher les goulots d’étranglement et des tests de performances automatisés pour détecter les régressions de performances dans leur code pendant le développement. Cependant, tester une application avant sa livraison ne suffit pas.
Pour détecter les problèmes de performances les plus frustrants, vous devez explorer ce qui se passe sur les appareils de vos utilisateurs. Cela signifie un aperçu de la vitesse de démarrage de votre application, de la durée des requêtes HTTP, du nombre d’images lentes et figées, de la vitesse de chargement de vos vues, etc.
Mobile Vitals
Nous pensons qu’il existe quatre mesures que chaque équipe mobile doit suivre pour mieux comprendre les performances de son application : les démarrages à froid, les démarrages à chaud, les images lentes et les images gelées. Ces quatre mesures, qui font partie intégrante de la surveillance des performances de Sentry, vous donnent les détails dont vous avez besoin non seulement pour hiérarchiser les problèmes de performances critiques, mais aussi pour retracer le problème jusqu’à la cause première pour les résoudre plus rapidement.
Démarrage de l’application de mesure
Lorsqu’un utilisateur appuie sur l’icône de votre application, celle-ci devrait démarrer rapidement. Sur iOS, Apple recommande que votre application prenne au plus 400 ms pour rendre la première image. Sur Android, la console Google Play vous avertit lorsqu’un démarrage à froid dure plus de cinq secondes ou un démarrage à chaud plus de deux secondes.
- Démarrage à froid: Application lancée pour la première fois, après un redémarrage ou une mise à jour
- Démarrage à chaud: L’application a été lancée au moins une fois et est partiellement en mémoire
Les définitions exactes diffèrent légèrement par plate-forme. Pour plus de détails, veuillez consulter nos docs iOS et Android.
Quelle que soit la plate-forme, il est crucial que votre application démarre rapidement pour offrir une expérience utilisateur agréable. C’est pourquoi sur iOS, Mac Catalyst, tvOS et Android, nous suivons le temps nécessaire à votre application pour dessiner votre première image. Nous récupérons ces informations et ajoutons des durées pour différentes phases du démarrage de l’application. Voici un exemple d’iOS :
Sur Android, il est plus difficile de se connecter aux phases d’initialisation du démarrage de l’application, et nous ajoutons donc actuellement une période du lancement de l’application à la première transaction d’interface utilisateur générée automatiquement. Pourtant, ces informations sont très utiles et peuvent vous aider à améliorer la durée de démarrage de votre application.
Images lentes et figées
L’interface utilisateur qui ne répond pas, les problèmes d’animation ou tout simplement les désagréments agacent les utilisateurs et dégradent l’expérience utilisateur. Deux mesures pour suivre cette expérience indésirable sont les images lentes et gelées. Un téléphone ou une tablette affiche généralement 60 images par seconde (fps).
La fréquence d’images peut également être plus élevée, d’autant plus que les écrans à 120 ips deviennent de plus en plus populaires. Avec 60 ips, chaque image a 16,67 ms à restituer. Si votre application a besoin de plus de 16,67 ms pour une trame, il s’agit d’une trame lente.
Les trames gelées sont des trames d’interface utilisateur qui durent plus de 700 ms. Une application qui fonctionne correctement ne devrait pas non plus en faire l’expérience. C’est pourquoi le SDK ajoute ces deux mesures à toutes les transactions capturées. La vue détaillée de la transaction affiche les images lentes, figées et totales à droite.
Surveillance des performances mobiles
Le but de la surveillance des performances de Sentry est de suivre les performances de votre application sur plusieurs services. Pour mesurer les Mobile Vitals, les SDK capturent des traces distribuées constituées de transactions et de délais.
Le traçage distribué est une technologie standard utilisée pour comprendre ce qui se passe dans les services distribués, mais il est encore relativement nouveau pour les applications mobiles. Une trace représente une opération que vous souhaitez mesurer, comme la connexion ou le chargement d’une vue dans votre application. Les deux opérations mentionnées n’impliquent pas seulement votre application, mais également des actions backend. Chaque trace se compose d’une ou plusieurs transactions, qui peuvent contenir une ou plusieurs étendues. Par exemple, la trace d’une connexion pourrait alors inclure une transaction de votre application et deux transactions de vos services backend.
Chaque transaction contient plusieurs tranches représentant une seule unité de travail, comme la lecture d’un fichier ou l’interrogation de la base de données. Les étendues ont une relation parent-enfant, ce qui signifie qu’une étendue peut avoir plusieurs enfants et petits-enfants. Voici un exemple de trace, décomposé en transactions et délais :
Si vous souhaitez approfondir ces concepts, consultez Distributed Tracing 101 pour les développeurs Full Stack. Pour cet article de blog, concentrons-nous sur les transactions et examinons un exemple de création d’une transaction avec deux intervalles enfants dans Swift :
let transaction =
SentrySDK.startTransaction(name: "Load Messages", operation: "ui.load")
let getMessagesSpan =
transaction.startChild(operation: "http", description: "GET /my/api/messages")
getMessages()
getMessagesSpan.finish()
let renderMessagesSpan =
transaction.startChild(operation: "ui", description: "Render Messages")
renderMessages()
renderMessagesSpan.finish()
// Finishes the transaction and sends it to Sentry
transaction.finish()Après avoir exécuté le code, nous pouvons jeter un œil à la transaction dans Sentry :
La création manuelle de transactions riches nécessiterait l’écriture de beaucoup de code. C’est pourquoi nous avons simplifié les choses avec l’instrumentation automatique. Vous pouvez vous épargner le casse-tête de l’écriture et de la maintenance du code tout en continuant à accéder aux informations sur les performances dont vous avez besoin.
Instrumentation automatique
L’instrumentation automatique vous permet d’explorer combien de temps vos vues prennent pour s’afficher et combien de temps les requêtes HTTP doivent se terminer. Le SDK pour Apple génère des transactions pour UIViewControllers sur iOS, tvOS et Mac Catalyst et crée des intervalles pour les requêtes HTTP sortantes sur toutes les plateformes. Le SDK pour Android capture les transactions pour les activités et les fragments et fournit une intégration pour OkHttp. Le SDK Sentry pour React Native peut capturer automatiquement les transactions lors de l’utilisation du routeur de navigation React et s’étend à la fois aux requêtes XHR et d’extraction.
Voici un exemple de transaction générée automatiquement sur iOS pour un UIViewController. Comme nous pouvons le voir dans la capture d’écran ci-dessous, le SDK crée des délais pour chaque méthode de cycle de vie. Dans viewWillAppear, nous lançons une requête HTTP pour laquelle un span est ajouté. Nos SDK n’ajoutent pas automatiquement de délais pour interroger la base de données (pour l’instant), mais je suis intéressé par la durée d’exécution de ma requête. Par conséquent, je dois ajouter une étendue manuellement. Nous pouvons y parvenir en utilisant SentrySDK.span pour accéder à la durée active actuelle et à l’appel SentrySDK.span.startChild pour créer l’étendue enfant souhaitée.
Avec la transaction ci-dessus, j’apprends où mes goulots d’étranglement dans le UIViewController sommes. Les viewDidLoad La méthode semble suspecte car elle prend environ 70 ms, je devrais donc l’étudier. Après avoir regardé le code, je me rends compte que je fais des E/S remarquables sur le thread principal, ce qui, bien sûr, est interdit et doit être corrigé immédiatement. De plus, le chargement de certaines entrées de la base de données prend beaucoup plus de temps que la requête HTTP, ce qui semble également douteux et nécessite une enquête plus approfondie.
Après avoir déplacé les E/S dans viewDidLoad à un fil d’arrière-plan et en ajoutant un index pour accélérer ma requête de base de données, la transaction semble bien meilleure maintenant. Bien sûr, la vitesse de la requête HTTP variera en fonction des conditions du réseau, mais j’ai éliminé les goulots d’étranglement contrôlables, ce qui accélère ma transaction de 250 ms à environ 20 ms. C’est une énorme amélioration.
La durée d’une transaction peut varier considérablement en raison de nombreuses circonstances. Parcourir les transactions individuelles ne vous donne pas une image claire pour comprendre si votre application s’accélère ou ralentit. Par conséquent, nous fournissons des graphiques pour explorer comment la durée d’une transaction change au fil du temps.
Sentry offre également la possibilité d’explorer les transactions lentes, rapides, aberrantes ou récentes pour trouver rapidement la misère ou le plaisir que vivent vos utilisateurs.
Avec de nombreuses autres possibilités d’explorer vos transactions, Sentry relie les erreurs connexes capturées lors d’une transaction au bas de la page de résumé de la transaction.
Les transactions générées automatiquement combinées à des transactions manuelles déverrouillent des données riches afin que vous puissiez voir Mobile Vitals ainsi que d’autres mesures, telles que User Misery, pour vous donner une vue complète des performances de votre application.