Share
Dans le monde hyperconnecté d'aujourd'hui, les gens veulent des résultats rapides. En tant que développeurs mobiles, nous en sommes plus conscients que la plupart. Nos utilisateurs ne s'assoient pas devant un bureau. Ils sont actifs et utilisent nos applications tout en essayant de marcher, de parler et de conduire. Ils s'attendent donc à des expériences captivantes. Entrer, sortir.
Plusieurs études d’Akamai, de Google et d’autres ont établi une corrélation entre la vitesse des sites Web et la rétention des utilisateurs. Et jusqu'à présent, les preuves suggèrent que les utilisateurs sont au moins aussi exigeants lorsqu'ils utilisent des applications natives. Dans une enquête menée par Apigee auprès des utilisateurs mobiles, la plainte principale concernant les applications mobiles est le blocage et plus de 44% des utilisateurs interrogés ont déclaré qu'ils supprimeraient immédiatement une application peu performante..
Demandez à Facebook sur l'importance des applications mobiles rapides. Mark Zuckerberg a déclaré que fonder son application sur HTML5 était la plus grande erreur qu’il avait commise en tant qu’entreprise. Pourquoi? Parce que c'était lent. Trois semaines après la sortie de la nouvelle application native plus rapide de Facebook, la note de l’application avait grimpé de 1,5 étoile à 4 étoiles. Les applications lentes causent des difficultés considérables aux entreprises. Utilisateurs perdus. Dollars perdus.
Lors de la première discussion avec les développeurs sur la surveillance des performances de leur application en production, la réponse la plus fréquente était: "Mon application est déjà rapide."
Le problème est que, dans le monde des fragments mobiles, il est difficile de fournir une expérience toujours rapide. Comment votre application fonctionne-t-elle en Chine sur un ancien téléphone et un réseau lent? Je suis prêt à parier que vous n'en avez aucune idée. Ce n'est certainement pas la même chose que sur votre tout nouvel iPhone connecté à votre bureau Wi-Fi.
Les performances dépendent entièrement du contexte dans lequel votre application s'exécute. Voici une liste rapide, mais certainement pas complète, des pièges liés à la performance:
Nous sommes habitués à penser aux problèmes d’Internet en termes de limitations de bande passante, mais dans les réseaux cellulaires, la latence est souvent le facteur dominant. Sur un réseau 3G, il faut environ 2,5 secondes pour passer d’un mode inactif à un mode connecté avant la transmission d’un seul octet. Et Sprint indique que la latence moyenne sur leur réseau 3G est de 400 ms. Peu importe la rapidité avec laquelle votre serveur traite une demande si la réponse tarde à arriver au téléphone.
En tant que geeks, nous développons souvent en utilisant les technologies les plus récentes et les plus performantes, mais la plupart des pays du monde, y compris les marchés énormes que vous souhaitez pénétrer, renoncent à la vitesse pour être abordables. Nos tests montrent que le code lié au processeur sur un iPod 4G prend environ quatre fois plus longtemps que sur un iPhone 5S. Sur Android, la disparité est encore plus significative.
Si votre application utilise trop de mémoire, celle-ci est détruite par le système d'exploitation. Pour l'utilisateur, cela ressemble à une exception de pointeur nul. Même si votre code est d'une propreté irréprochable sans une seule fuite de mémoire, la limite supérieure de votre mémoire peut entraîner des pannes sur les téléphones moins puissants mais populaires des marchés importants.
Les batteries sont l’une des premières choses à réduire leur taille lorsque les fabricants tentent de gagner de la place et de l’argent. Mais cela ne rendra pas les utilisateurs plus compréhensifs lorsque votre application draine toute leur puissance.
Supposons un instant que vous soyez convaincu que vous avez besoin d'une application rapide, qui devrait être rapide partout, pas seulement pour vous lorsque vous exécutez votre application via le profileur de processeur Instruments d'Apple. Qu'est-ce qu'un développeur à faire? À l'heure actuelle, vous avez deux options de base:
Une API rapide signifie une application rapide. Droite? C'est la mentalité d'un développeur web, et si vous êtes un développeur mobile, c'est faux.
Le Web est une architecture de client léger. En mettant de côté les applications Web lourdes JavaScript, la plupart du code intéressant derrière les sites Web est exécuté sur le serveur. Le client, le navigateur, n'est en réalité qu'un moteur de rendu sans état. Lorsque les performances diminuent, il s'agit généralement d'un problème de dimensionnement dans votre infrastructure backend..
Les applications mobiles et natives, en revanche, sont des clients lourds. Ils ont de grandes bases de code multithreads. Ils maintiennent l'état. Et ils doivent fonctionner sur une grande variété de combinés, de systèmes d'exploitation et de réseaux. Votre équipe de serveurs peut toujours gâcher l'expérience de l'utilisateur, mais de nouveaux problèmes ne se retrouveront pas dans les alertes de votre serveur..
Bien. Vous l'obtenez. Vous devez vous assurer de tester vos applications dans un tas de monde réel scénarios. Vous allez donc créer un laboratoire d’assurance qualité avec 100 combinés différents. Ensuite, vous allez les enfermer dans une cage de Faraday pour pouvoir simuler des conditions de réseau défavorables, et engager une armée de spécialistes de l'assurance qualité pour exécuter chaque nouvelle version dans toutes les actions possibles de votre application..
J'admets que si vous pouvez vous le permettre, ce n'est pas une mauvaise idée. Mais les combinaisons deviennent vite écrasantes. Imaginez que vous vous souciez des 100 meilleurs téléphones, des 10 vitesses de réseau, de 20 marchés étrangers différents avec des latences différentes et de 5 versions de système d'exploitation différentes. Maintenant, imaginez que vous avez 50 actions distinctes dans votre application. En ignorant l'interdépendance entre les actions et les différentes données utilisateur, vous avez 1 million de combinaisons à tester. Aie!
C'est un problème de QA classique. L’assurance qualité signifie faire de votre mieux pour tester les cas d’utilisation les plus courants. Mais ce n’est jamais censé remplacer la surveillance. Il est tout simplement impossible de rester au courant de tous les cas d'échec possibles.
Nous avons besoin d’un nouvel ensemble d’outils, conçu de toutes pièces pour mesurer spécifiquement les problèmes de performances des applications mobiles. Quelles mesures ces nouveaux outils devraient-ils capturer??
Rien ne dérange plus un utilisateur qu'un écran figé. En capturant chaque fois que votre application met plus de temps que prévu à restituer une image, vous pouvez avoir une idée de la fréquence à laquelle ils constatent un arrêt perceptible..
Si vous suivez de bonnes pratiques d’UI / UX, chaque fois que vous devez effectuer un travail qui prendra plus que quelques millisecondes, vous devriez le faire en arrière-plan et lancer une spinner. Mais même si vous êtes au-dessus de vos threads, la patience des utilisateurs reste limitée.
Après 1 seconde, les utilisateurs changent de contexte mental et après 10 secondes, ils abandonnent leur tâche. Si vous capturez chaque fois que vous affichez un spinner, vous disposez d'un bon indicateur générique de la durée pendant laquelle l'utilisateur type attend votre application..
Les bugs de mémoire sont l’une des choses les plus difficiles à dénicher, d’autant plus que la Mémoire insuffisante Le tueur sur iOS ne génère pas de trace de pile. Il est trop onéreux de suivre chaque allocation, mais enregistrer de la mémoire résidente sur iOS ou VM utiliser des tas sur Android est une bonne mesure, avec un temps système réduit.
La latence et la bande passante varient fortement sur les réseaux cellulaires et jouent un rôle clé dans l'expérience de l'utilisateur. Pour chaque demande d'API, vous pouvez enregistrer le temps nécessaire pour obtenir la réponse initiale (latence), le temps nécessaire pour obtenir la réponse complète (temps de téléchargement) et les octets téléchargés (octets / le temps de téléchargement est égal à la bande passante)..
L'une des rares raisons pour lesquelles je désinstalle les applications est une utilisation intensive de la batterie. Il y a évidemment des problèmes de batterie, comme utiliser le GPS de l'appareil, mais d'autres pièges inattendus, tels que l'activation trop fréquente de l'antenne sans fil. IOS et Android proposent des API pour la surveillance du niveau de charge de la batterie.
Dans le mobile, le contexte est tout. En cas de problème, vous devez au minimum connaître la version de l'application, son emplacement, le réseau de l'opérateur, la version du système d'exploitation et le périphérique..
Si vous êtes ambitieux, vous pouvez avoir une instrumentation de performance maison dans votre application. Vous avez probablement quelques minuteries de base pour les actions clés dans votre application, puis appelez les données à la maison via un journal ou un paquet spécialisé de JSON..
Si oui, tapotez-vous dans le dos. Vous avez fait beaucoup plus que la plupart. Mais cette approche présente de nombreux inconvénients. Que faire si vous rencontrez des problèmes de performances dans des endroits inattendus de votre application? Si vous avez un problème, comment savez-vous ce qui l’a causé? S'agissait-il d'un long appel de méthode, d'une requête d'API lente ou de trop de données sur le réseau??
Et une fois que vous avez obtenu les données de performance brutes, comment les analysez-vous et les visualisez-vous? Si vous écrivez un script unique, à quelle fréquence l'exécutez-vous? Et, Dieu nous garde, que se passera-t-il si votre instrumentation de performance pose des problèmes de performance??
Au Pulse.io, nous avons travaillé dur au cours de l’année écoulée pour créer un SDK bourré d’options de surveillance. Nous capturons toutes les mesures répertoriées ci-dessus tout en maintenant une empreinte très faible. Nous consommons moins de 3% de la CPU, envoyons nos données par lots pour éviter d'allumer la radio et limitons notre utilisation de la mémoire en supprimant les informations de priorité basse..
La meilleure partie de Pulse.io est qu’il capture tout cela automatiquement. C'est une chose d'instrumenter manuellement votre application avec votre solution maison. C’est une autre chose de convaincre tous les ingénieurs de votre équipe de le faire et d’appliquer la même méthodologie d’instrumentation de manière cohérente dans le temps..
Avec Pulse.io, vous déposez simplement le SDK qui détecte automatiquement toutes les interactions de l'utilisateur au sein de votre application et enregistre lorsque ces interactions sont à l'origine d'un comportement incorrect, tel que le gel de l'écran ou de longues tâches asynchrones..
L'installation de Pulse.io vous prendra moins de temps que la lecture de cet article. Nous sommes actuellement en version bêta privée, mais si vous nous envoyez un e-mail sur beta [at] pulse [dot] io et mentionnez que vous avez entendu parler de nous sur Tuts +, nous vous créerons un compte..
Une fois le SDK téléchargé, l’installation est extrêmement simple. Placez le SDK dans votre application, ajoutez quelques dépendances et appelez [Moniteur PulseSDK: @ "YOUR_APP_KEY"] dans votre application main.m. Vous avez terminé.
J'espère que je vous ai convaincu de trois choses:
Je vous encourage à rechercher les performances réelles de votre application. Essayez Pulse.io. Il n'y a pas grand chose à perdre et beaucoup de performances à gagner.
Accentsconagua