Les différentes méthodes sont des indications de priorité. Comme vous les avez énumérés, ils vont du moins au plus important. Je pense que la façon dont vous les mappez spécifiquement pour déboguer les journaux dans votre code dépend du composant ou de l'application sur laquelle vous travaillez, ainsi que de la façon dont Android les traite selon différentes versions de construction (eng, userdebug et user). J'ai fait pas mal de travail dans les démons natifs d'Android, et c'est ainsi que je le fais. Il peut ne pas s'appliquer directement à votre application, mais il peut y avoir un terrain d'entente. Si mon explication semble vague, c'est parce que certaines choses relèvent davantage d'un art que d'une science. Ma règle de base est d'être aussi efficace que possible, de vous assurer que vous pouvez raisonnablement déboguer votre composant sans tuer les performances du système, et toujours vérifier les erreurs et les enregistrer.
V - Impressions d'état à différents intervalles, ou lors de tout événement survenu que mon composant traite. Également des impressions très détaillées des charges utiles des messages / événements que mon composant reçoit ou envoie.
D - Détails des événements mineurs qui se produisent dans mon composant, ainsi que les charges utiles des messages / événements que mon composant reçoit ou envoie.
I - L'en-tête de tous les messages / événements que mon composant reçoit ou envoie, ainsi que tous les éléments importants de la charge utile qui sont essentiels au fonctionnement de mon composant.
W - Tout ce qui se produit est inhabituel ou suspect, mais pas nécessairement une erreur.
E - Erreurs, ce qui signifie des choses qui ne sont pas censées se produire lorsque les choses fonctionnent comme elles le devraient.
La plus grande erreur que je vois est que les gens abusent de choses comme V, D et I, mais n'utilisent jamais W ou E. Si une erreur n'est, par définition, pas censée se produire, ou ne devrait se produire que très rarement, alors c'est extrêmement pas cher pour vous d'enregistrer un message quand il se produit. D'un autre côté, si chaque fois que quelqu'un appuie sur une touche, vous effectuez un Log.i (), vous abusez de la ressource de journalisation partagée. Bien sûr, utilisez votre bon sens et soyez prudent avec les journaux d'erreurs pour les choses hors de votre contrôle (comme les erreurs de réseau), ou celles contenues dans des boucles serrées.
Peut-être mauvais
Log.i("I am here");
Bien
Log.e("I shouldn't be here");
Avec tout cela à l'esprit, plus votre code se rapproche de la "production prête", plus vous pouvez restreindre le niveau de journalisation de base pour votre code (vous avez besoin de V en alpha, D en bêta, I en production, ou peut-être même W en production ). Vous devez parcourir quelques cas d'utilisation simples et afficher les journaux pour vous assurer que vous pouvez toujours comprendre la plupart du temps ce qui se passe lorsque vous appliquez un filtrage plus restrictif. Si vous exécutez avec le filtre ci-dessous, vous devriez toujours être en mesure de dire ce que fait votre application, mais peut-être pas obtenir tous les détails.
logcat -v threadtime MyApp:I *:S
Verbose
journalisation. C'est ce que vous utilisez lorsque vous souhaitez générer toutes les opérations logiques possibles.