Aussi intéressantes que soient les applications Web, elles ne sont pas le seul jeu en ville. De nos jours, les applications mobiles font partie intégrante du paysage de développement logiciel. Comme pour les applications Web, nous voulons que notre code d'application mobile soit performant..
Heureusement, depuis un an ou deux, New Relic s’est efforcée de mettre au point une solution permettant de surveiller les performances de vos applications mobiles. Aujourd'hui, nous allons voir comment vous pouvez commencer à utiliser New Relic pour surveiller les performances d'une application Android..
Pourquoi surveiller les applications mobiles du tout?
La grande chose à propos de la création d’une application Web est que vous pouvez toujours déployer une nouvelle version, instantanément. forçant toute votre base d’utilisateurs à utiliser votre nouveau code. Ainsi, si vous ne surveilliez pas votre code auparavant, vous pouvez facilement connecter New Relic ou modifier quelque chose de personnalisé, le transférer et commencer à obtenir des métriques en quelques minutes..
Avec les applications mobiles, vous n'êtes pas si chanceux. Vous pouvez, bien sûr, publier une nouvelle version à tout moment, mais le processus est potentiellement une approbation plus longue pour un magasin d'applications, par exemple. Et même lorsque votre nouvelle version est disponible, vous ne pouvez pas forcer vos utilisateurs à effectuer une mise à niveau. Il est donc important de penser à tout type de surveillance à effectuer avant de publier la première version de votre application..
Même si vous n'avez pas à vous soucier des performances de votre application pendant un moment, une fois que vous l'aurez fait, votre solution de surveillance sera déjà en place, il vous suffira de commencer à interpréter les métriques..
De plus, il s’agit d’une application mobile rare qui n’a pas non plus de composant Web. De nos jours, presque toutes les applications adressent des requêtes HTTP à une API et souvent à de nombreuses API différentes..
Comme nous le savons, les appels réseau ne sont pas toujours les plus fiables. Ce serait formidable si nous pouvions savoir à quelle fréquence les appels d'API échouent pour nos utilisateurs et, plus important encore, à quel point nos appels d'API sont lents en moyenne. C'est le seul moyen de savoir si nos utilisateurs ont une bonne expérience de notre application ou s'ils sont frustrés par le retard..
Si vous ne surveillez pas votre application, vous ne pouvez que deviner ce genre de choses. Je ne sais pas pour vous, mais je suis généralement beaucoup plus à l'aise avec les données froides et dures.
Une bonne solution de surveillance peut nous aider à répondre à de nombreuses autres questions importantes, mais nous pouvons les aborder pendant que nous travaillons avec notre application Android..
Construire une application Android basique
Normalement, pour un article d'introduction comme celui-ci, j'aime bien me concentrer sur le sujet à l'étude (dans ce cas, Nouvelle relique pour mobile) et conserver le reste du code comme suit. Bonjour le monde comme possible.
Il est facile de construire un Bonjour le monde Android app, Google a même un tutoriel à ce sujet. Malheureusement, cette application est juste un peu aussi de base. Il ne fait aucun appel réseau, ce qui signifie que nous ne serions pas en mesure d’examiner une grande partie des offres de New Relic pour la surveillance des applications mobiles. Donc, nous allons légèrement modifier notre application de base.
Notre application aura deux écrans, sur le premier écran, nous pourrons entrer un pseudo Twitter et le soumettre. À ce stade, notre application affiche le deuxième écran et affiche du texte de substitution. En attendant, notre application ira sur Twitter et récupérera le dernier tweet correspondant à ce pseudonyme. Une fois le tweet disponible, nous mettrons à jour le deuxième écran pour l'afficher. L'application est encore assez basique, mais heureusement, elle est suffisamment complexe pour que nous puissions obtenir des données intéressantes de New Relic..
Je ne vais pas passer en revue l'installation complète de l'application, mais voici les parties intéressantes. Selon le tutoriel de Google, lorsque nous appuierons sur le bouton du premier écran, la valeur du champ de texte sera transmise au deuxième écran, mais dans notre cas, il s'agira d'un pseudo Twitter:
public void sendMessage (Vue d'affichage) Intentive = nouvelle intention (this, DisplayMessageActivity.class); EditText editText = (EditText) findViewById (R.id.edit_message); Message de chaîne = editText.getText (). ToString (); intent.putExtra (EXTRA_MESSAGE, message); startActivity (intention);
Sur le deuxième écran, nous voulons récupérer le dernier tweet pour cette poignée. Mais nous ne pouvons pas le faire sur le UIThread, nous avons besoin d'un AsyncTask. Nous allons en créer un et le lancer à l'intérieur du onCreate méthode de la deuxième activité:
@Override protected void onCreate (Bundle savedInstanceState) super.onCreate (savedInstanceState); setContentView (R.layout.activity_display_message); setupActionBar (); String handle = getIntent (). GetStringExtra (MainActivity.EXTRA_MESSAGE); TextView textView = new TextView (this); textView.setTextSize (40); new FetchLatestTweetTask (textView, handle) .execute (); // Définir la vue de texte en tant que structure d'activité setContentView (textView);
La tâche réelle ressemble à ceci:
Classe publique FetchLatestTweetTask étend AsyncTask privé TextView textView; poignée privée de chaîne; public FetchLatestTweetTask (TextView textView, String handle) this.textView = textView; this.handle = handle; @Override protected String doInBackground (Void… args) Twitter Twitter = new TwitterFactory (). GetInstance (); Statut de la chaîne = null; try User user = twitter.showUser (handle); status = user.getStatus (). getText (); catch (Exception e) e.printStackTrace (); état de retour; protected void onPreExecute () textView.setText (String.format ("Récupération du tweet de @% s…", descripteur)); protected void onPostExecute (String tweet) textView.setText (tweet);
Nous affichons du texte de substitution avant d'extraire le tweet et le mettons à jour avec le contenu du tweet après l'avoir récupéré. Nous utilisons Twitter4J pour parler à l'API Twitter. Pour que la bibliothèque d’API fonctionne, j’ai vidé un fichier twitter4j.properties déposer dans le / src dossier du projet afin qu'il se termine sur le chemin de classe selon la documentation.
Le fichier de propriétés contient la clé de consommateur OAuth, le secret de consommateur, la clé de jeton d'accès et le secret de jeton d'accès de l'application Twitter que j'ai configurée uniquement pour cela..
C’est tout le code intéressant dans notre application, le reste n’est que du passe-partout générique, conformément au tutoriel d’introduction de Google..
Configurer une nouvelle application pour vous
Configurer New Relic pour commencer à surveiller votre application Android est très facile. Dans votre compte New Relic, cliquez sur Mobile dans le menu. C’est là que vivront toutes vos applications mobiles, tout comme les applications Web vivent sous le Applications élément du menu.
Maintenant, cliquez sur le Ajouter une nouvelle application bouton:
Cela vous mènera à un autre écran où New Relic vous guidera à travers la configuration d'une nouvelle application:
Nous cliquons sur Android et donnez un nom à notre application. Une fois que vous avez donné un nom à votre application, vous devez appuyer sur Continuer afin que New Relic génère une nouvelle clé API pour votre application.
Ensuite, nous devons installer l'agent New Relic. J'utilise Eclipse alors je vais à Aide> Installer un nouveau logiciel… et ajoutez New Relic en tant que site:
Cliquez sur Suivant et attendez qu'Eclipse fasse son travail. Une fois que c'est fait, vous devez redémarrer Eclipse. À ce stade, vous devriez pouvoir cliquer avec le bouton droit de la souris sur votre projet dans Eclipse. Installer une nouvelle relique option de menu. Lorsque nous cliquons dessus, le pot de l'agent New Relic se retrouvera dans le / libs dossier de notre projet.
Incidemment, si une nouvelle version de l'agent New Relic arrive, vous la mettez à jour de la même manière. Tout d'abord, faire Aide> Rechercher les mises à jour pour obtenir les dernières mises à jour. Après cela, faites un clic droit sur votre projet et il devrait y avoir un Mettre à jour une nouvelle relique Option de menu, qui mettra à jour le fichier jar New Relic lorsque vous cliquerez dessus:
Maintenant, nous devons donner à notre application des autorisations pour L'INTERNET et ACCESS_NETWORK_STATE New Relic devra renvoyer les données à leurs serveurs. Notre AndroidManifest.xml ressemblera à ceci:
…
Il ne nous reste plus qu'à lancer l'agent. Dans notre MainActivity.java nous importons New Relic:
import com.newrelic.agent.android.NewRelic;
Nous démarrons ensuite l'agent à l'intérieur du onCreate méthode:
Notez le jeton d'application. Si vous avez appuyé sur Continuer lorsque vous avez donné un nom à votre demande, celle-ci devrait déjà être pré-remplie pour vous. Une fois que votre application est opérationnelle, vous pouvez toujours la consulter à nouveau dans le menu déroulant. Réglages menu pour votre application.
Après cette étape, nous construisons le projet et le déployons sur un émulateur ou un périphérique physique. Je préfère utiliser un périphérique de test car je le trouve plus rapide, plus réactif et plus facile à utiliser. Je vais utiliser mon Nexus 4.
Si nous examinons l'onglet LogCat lors du déploiement de l'application, nous devrions voir une sortie similaire à celle-ci:
02-23 17: 25: 17.004: I / com.newrelic.agent.android (25592): Configuration chargée: HarvestConfiguration collect_network_errors = true, cross_process_id = "null", data_report_period = 60, data_token = [0, 0], error_limit La classe est à côté de la classe. : 17.054: I / com.newrelic.agent.android (25592): Le moniteur d'état de l'application a démarré. 02-23 17: 25: 17.104: I / com.newrelic.agent.android (25592): Le moteur de mesure a été initialisé. 02-23 17: 25: 17.114: I / com.newrelic.agent.android (25592): New Relic Agent v3.264.0
C'est ainsi que nous savons que New Relic a été chargé. Après cela, si nous continuons à regarder LogCat, nous verrons quelque chose comme ceci toutes les minutes environ:
02-23 17: 55: 40.410: I / com.newrelic.agent.android (31413): Abatteur: connecté 02-23 17: 55: 40.410: I / com.newrelic.agent.android (31413): Abatteur: Envoi 2 transactions HTTP. 02-23 17: 55: 40.410: I / com.newrelic.agent.android (31413): Harvester: envoi de 0 erreurs HTTP. 02-23 17: 55: 40.410: I / com.newrelic.agent.android (31413): Harvester: Envoi de 0 trace d'activité.
C'est New Relic qui appelle chez lui pour envoyer des données. Si nous revenons maintenant à l'interface utilisateur de New Relic, nous devrions commencer à voir les données.
Explorer les tableaux de bord
Quand vous allez regarder votre application dans New Relic, vous frapperez d’abord le Vue d'ensemble écran. Semblable à l’écran de présentation de l’application Web, il affiche plusieurs indicateurs importants concernant votre application, tels que Temps de réponse Http, Interactions les plus lentes, etc.
L’activité sur ces graphiques est sporadique puisqu’un seul client renvoie des données et que nous n’avons effectué que quelques interactions..
Alors, quelles sont les choses les plus intéressantes que vous pouvez voir dans New Relic pour votre application mobile? Eh bien, il y a le App> Appareils onglet qui vous indique les appareils sur lesquels les utilisateurs utilisent votre application. C’est intéressant car vous pouvez voir en un coup d’œil quel type de téléphones / tables la plupart des utilisateurs utilisent. Les gens utilisent-ils principalement des appareils plus anciens ou plus récents? Sont-ils principalement sur des tablettes ou des téléphones? Ce sont des données précieuses.
Vous pouvez explorer chaque appareil et voir si votre application y va bien. Le temps d’interaction pour ce périphérique est-il plus lent que prévu? Qu'en est-il du temps de réponse Http? Combien d'utilisateurs actifs utilisent actuellement votre application sur ce type d'appareil? Dans notre cas:
Il n'y a qu'un seul appareil, il n'y a donc pas grand chose à voir. Mais si un pourcentage important de votre base d'utilisateurs se trouvait sur un appareil où votre application ne fonctionnait pas très bien, vous le verriez tout de suite et pourrez résoudre le problème..
Semblable à la Dispositifs onglet, il y a le Versions d'OS Onglet, qui décompose l'utilisation de votre application par la version d'Android que vos utilisateurs ont installée:
Vous pouvez dire si vous devez vous concentrer davantage sur les nouvelles versions d'Android ou si la plupart de vos utilisateurs se trouvent toujours dans une version antérieure..
Puis il y a le Réseau Onglet et ses enfants. dans le Carte onglet, vous pouvez voir les API auxquelles votre application se connecte et l’état de chacune d’elles. Quel est le débit, le temps de réponse et le taux d'erreur:
Dans notre cas, nous n’avons que l’API de Twitter et c’est plutôt lent. Peut-être pourrions-nous envisager de mettre en cache certaines des réponses pendant un certain temps.
dans le Réseaux> Requêtes Http onglet, nous pouvons explorer chaque ordinateur d'extrémité de chaque API que nous utilisons de la même manière que nous analysons les périphériques et les versions de système d'exploitation. Nous pouvons déterminer quels points de terminaison sont les plus utilisés et quels sont les plus lents. Cela nous donne de solides pistes quant à l'orientation de nos efforts d'optimisation. Cela est particulièrement vrai si nous contrôlons également les API utilisées.
dans le Réseau> Géographie onglet, vous pouvez dire d'où viennent la plupart de vos utilisateurs et dans le Transporteurs Dans l'onglet, vous pouvez voir le type de connexion Internet de vos utilisateurs. Dans notre cas, je suis en Wi-Fi:
Il est très utile de savoir si votre base d'utilisateurs utilise le Wi-Fi, la 3G ou la 4G, car vos efforts d'optimisation peuvent être complètement différents selon la panne..
Sous Paramètres> Alertes, vous pouvez également définir certaines conditions pour vos API externes pour que New Relic vous avertisse si les temps de réponse dépassent un certain seuil ou si les taux d'erreur dépassent un certain pourcentage.
C'est potentiellement moins intéressant pour les API que vous ne contrôlez pas, mais cela reste un bon indicateur si une API que vous utilisez est instable ou peu performante..
Les deux derniers sont intéressants Utilisation> Versions et Utilisation> Uniques mensuelles. Le premier vous indique quelles versions de votre application sont utilisées à l'état sauvage. Cela vous permet de savoir avec quel empressement les utilisateurs téléchargent les mises à jour de votre application. Il vous indique également les performances de chaque version de votre application sur l'appareil. La nouvelle version utilise-t-elle plus de mémoire que la version précédente??
Les uniques mensuels vous donnent essentiellement une idée si des personnes interagissent réellement avec votre application. Vous avez peut-être 10 millions de téléchargements, mais si le nombre de uniques mensuels est faible, les choses ne sont pas aussi bonnes qu'elles semblent l'être..
Conclusion
Ceci est un aperçu de base de certaines fonctionnalités de New Relic for Android, mais pas toutes intéressantes. En soi, aucune de ces fonctionnalités n’est époustouflante, mais il s’agit de bonnes données solides que, pour une application mobile, vous ne pouvez obtenir aucun autre moyen..
Comment votre application est utilisée et sur quels appareils, comment vos appels réseau fonctionnent-ils avec une connexion lente? C’est le type de données qui vous oblige à cesser de deviner et à prendre des décisions éclairées sur la manière d’améliorer votre application et de donner à vos utilisateurs meilleure expérience.
N'oubliez pas que les performances sont tout aussi importantes pour les applications mobiles que pour les applications Web, et il n'y a aucune raison de deviner ce qui ralentit votre application s'il existe un meilleur moyen facilement disponible..
Share
Accentsconagua
