Détection des plantages dans l’application Android publiée – Tech @ IIitg

Dans le processus de construction d’une application Android, lors des tests, nous sommes confrontés à de nombreux plantages. Nous détectons un plantage, le corrigeons et ce cycle se répète jusqu’à ce que et à moins que notre application soit entièrement construite et sans plantage. Et puis, après des mois de dur labeur, nous avons finalement poussé notre application vers le Play Store.

«Les temps sont durs. Maintenant, détendons et binge series!

. . . Mais ce n’est pas le cas. « 

Pour élaborer la discussion, permet d’avoir une conversation entre moi et mon ami: –

Tony Stark:- Hé Sayantan, j’organise une soirée ce soir chez moi. Il est basé sur mon application Android enfin prête pour la production. Vous êtes cordialement invité.

Moi:- C’est une excellente nouvelle. Félicitations mon pote. Je vais certainement y assister.

Tony Stark:- Merci 🙂

Moi:- Alors, qui est responsable du maintien de l’application?

Tony Stark:- Entretien… Umm… Personne pour l’instant. Eh bien, je n’ai besoin d’aucune mise à jour récente et elle est complètement exempte de bogues pour l’instant.

Moi:- Eh bien Tony, ce n’est pas le cas. Il peut y avoir des cas où d’autres appareils peuvent faire face à CRASH, bien que votre appareil puisse être sans crash.

Tony Stark:- Maintenant, c’est horrible. Comment se fait-il qu’un autre appareil soit confronté à Crash?

Moi:- Eh bien, la principale raison en est différents fabricants présent dans le monde. De nombreux fabricants utilisent leur propre système d’exploitation personnalisé, personnalisation de différents aspects d’un appareil. Et ces personnalisations peuvent faire ressortir des problèmes avec l’application dans ces appareils, entraînant ainsi des problèmes de performances et enfin CRASH!

Tony Stark:- Jamais pensé comme ça. Un exemple où différents fabricants posent des problèmes?

Moi:- Filetage en arrière-plan nécessite plus de manipulation dans les appareils fabriqués en Chine que l’appareil Android Stock, car ils ont tendance à s’arrêter Prestations de service seul en raison de Optimisation de la batterie.

Tony Stark:- D’accord, c’est un bon exemple. Y a-t-il d’autres cas où différents appareils peuvent provoquer un crash?

Moi:- le changement de la version du SDK Android peut également conduire à CRASH, car il y avait peut-être une fonctionnalité qui fonctionne dans la nouvelle version du SDK, mais pas dans les versions précédentes du SDK et vice versa.

Tony Stark:- Oui, l’application créée peut ne pas être Rétrocompatible. Je m’en suis occupé à divers endroits mais je ne sais pas si je l’ai introduit dans tous les endroits.

Moi:- Oui Tony. Vous avez compris mon point.

Tony Stark:- Alors, comment pouvons-nous obtenir les rapports d’erreur sur n’importe quel appareil via mon application. Dois-je continuer et le vérifier dans tous les appareils possibles?

Moi:- Eh bien, c’est une solution mais c’est une mauvaise solution. Nous pouvons utiliser pour rassembler tous les rapports d’erreur et les afficher tous dans un tableau de bord convivial.

Tony Stark:- Wow, ça semble intéressant. Dis m’en plus sur le sujet. Est-ce difficile à gérer?

Moi:- En fait, c’est l’un des le plus simple choses à implémenter dans une application Android. Discutons-en en détail.

Pour résoudre le problème ci-dessus, apparaît dans l’image. Firebase fournit un tableau de bord où nous pouvons visualiser tous les plantages d’un utilisateur à l’aide d’une application.

Dans l’image que nous pouvons voir, nous avons un Graphique de statistiques sans crash (utilisateurs v-s sans crash date), Graphique des tendances des événements (Nombre d’accidents v / s jour). Sous le Problèmes domaine, nous pouvons obtenir la liste de tous les plantages avec ses métadonnées comme la version de l’application affectée, le nombre d’événements et le nombre d’utilisateurs concernés.

Nous voyons un Bouton de filtre en haut, où nous pouvons filtrer davantage les plantages en fonction du numéro de version, du modèle de système d’exploitation et du SDK Android. Ceux-ci peuvent être utiles dans le filtrage des manières suivantes: –

1. Numéro de version:- Cela nous aidera à comprendre quel type d’utilisateurs est confronté à ce plantage.
2. Modèle de système d’exploitation: – Plusieurs fois, les téléphones de certains fabricants peuvent empêcher d’effectuer une certaine action, ce qui peut entraîner un crash. Nous pouvons trier les données en fonction de cela.
3. SDK Android: – Il est très utile pour vérifier les plantages concernant la compatibilité descendante.

Analysons maintenant ce que nous obtiendrons lorsque nous cliquons sur un rapport de plantage. Par exemple, cliquons sur le premier crash affiché dans la section des problèmes ci-dessus.

• Dans cette image, nous pouvons voir une analyse graphique du nombre d’événements de crash qui ont eu lieu, ainsi que la répartition de la Fabricant, système d’exploitation et état de l’appareil dans lequel cela s’est produit.
• Ci-dessous, nous obtenons le résumé des sessions contenant le trace de pile entière de l’erreur. Ainsi, les développeurs pourront utiliser ces données pour tracer l’erreur dans le code et peuvent corriger l’erreur.
• En dehors de la trace de pile, les clés et les journaux externes peuvent être transmis pour recueillir plus de connaissances sur le CRASH.

Grâce à cela, nous pouvons suivre les accidents qui se produisent dans divers appareils. Pour cela, nous devons ajouter la dépendance dans le build.gradle (application) fichier.

Maintenant, nous pouvons avoir deux types de rapports de plantage: –

• Le premier est le accidents généraux, ces plantages qui arrêtent immédiatement l’application. Celles-ci sont suivies automatiquement par les Crashlytics avec toute la trace de la pile, les informations sur le périphérique, les utilisateurs concernés, etc. et rapportées au tableau de bord. Tous les graphiques et graphiques statistiques sont générés automatiquement côté serveur.
• L’autre étant accidents non mortels, qui n’arrête pas l’application, mais renvoie une erreur dans un bloc try-catch. Nous pouvons l’introduire à un bloc try-catch spécifique de notre codeet si la méthode lève une exception, nous pouvons enregistrer son rapport de plantage.

Accidents généraux sont suivis automatiquement, sans exigence supplémentaire. Pour le accidents non mortels, nous pouvons l’introduire à l’intérieur du Bloc d’exception d’un try-catch.

essayer {

// du code pouvant entraîner une exception

}

capture (exception: exception) {

Crashlytics.setUserIdentifier (« identifiant d’utilisateur »)

Crashlytics.log (« Message_To_Identify_this_TryCatch_Block »)

Crashlytics.logException (exception)

}

Or, ces exceptions ne sont pas généralisées à tout le monde dans la nature; c’est-à-dire peut causer des problèmes à certains utilisateurs spécifiques. Nous pouvons donc recevoir l’ID utilisateur en définissant un setUserIdentifier. nous pouvons enregistrer un message personnalisé pour identifier le bloc try-catch approprié. Enfin, nous appelons exception de journal (exception) pour enregistrer le crash dans Crashlytics.

Il peut y avoir des cas dans lesquels l’une des nombreuses façons peut lever l’exception. Donc, dans ce cas, nous pouvons mettre des clés pour analyser plus en détail la nature de l’exception. Nous pouvons définir des valeurs String, Int, Float, Double ou Bool.

Crashlytics.setString (nom_clé, « valeur »)

Selon l’organigramme, nous devons simplement introduire le crash non fatal (car les accidents mortels seront collectés automatiquement), et Firebase se chargera des rapports. L’avantage est donc, il reste hors ligne jusqu’à et à moins qu’il ne soit téléchargé, pendant une période plus longue. En outre, Firebase utilise la meilleure façon possible de stocker les données, donc le stockage n’est pas un problème ici. L’inconvénient qu’il a à offrir est que si un utilisateur désinstalle l’application après le crash, le crash ne serait pas téléchargé.

Une fois le SDK branché et activé dans le tableau de bord Firebase, il ne nécessite aucune configuration supplémentaire. Firebase Crashlytics commence à observer les plantages. À des fins de test, nous pouvons forcer un crash pour vérifier si tout fonctionne comme prévu ou non.

Crashlytics.getInstance (). Crash ()

Nous pouvons maintenant attacher la commande ci-dessus sur un clic de bouton, et en appuyant sur le bouton planterait l’application et nous pouvons vérifier son rapport dans le tableau de bord.

Ainsi, comme nous l’avions vu jusqu’à présent, Firebase Crashlytics propose un tas de fonctionnalités pour suivre les plantages survenus sur différents appareils. Il est très facile à mettre en œuvre et il est donc recommandé de l’intégrer dans l’application Android avant de la publier pour la production. De cette façon, nous apprenons à connaître les plantages au moment de l’exécution qui se produisent sur différents appareils et nous avons la possibilité de les corriger. Ainsi, avec la prochaine version, notre application est plus exempte de bogues et les utilisateurs aimeraient l’utiliser.

À votre santé. Bon développement. Merci 🙂