Journal Android.v (), Log.d (), Log.I (), Log.w (), Log.e () - quand utiliser chacun?

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 lequel vous travaillez, ainsi que de la façon dont Android les traite sur différentes saveurs de construction (eng, userdebug et user). J'ai fait beaucoup de travail dans les démons natifs dans Android, et c'est ainsi que je le fais. Il peut ne pas s'appliquer directement à votre application, mais il peut y avoir de commun terrain. Si mon explication semble vague, c'est parce que certaines de ces choses sont plus un art qu'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 de toujours vérifier les erreurs et les enregistrer.

V-impressions d'État à différents intervalles, ou sur tout événement survenant que mon composant traite. Aussi peut-être 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 des charges utiles des messages/événements que mon composant reçoit ou envoie.

I-l'en-tête des messages / événements que mon composant reçoit ou envoie, ainsi que des éléments importants de la charge utile qui sont essentiels au fonctionnement de mon composant.

W-Tout ce qui se passe qui est inhabituel ou suspect, mais pas nécessairement une erreur.

E - erreurs, ce qui signifie des choses qui ne sont pas censé se produire quand les choses fonctionnent comme ils le devraient.

La plus grande erreur que je vois les gens faire est qu'ils abusent des choses comme V, D, et I, mais n'utilisent jamais W ou E. Si une erreur est, par définition, pas censé se produire, ou ne devrait se produire que très rarement, alors il est extrêmement bon marché pour vous de consigner un message quand il se produit. D'autre part, si chaque fois que quelqu'un appuie sur une touche vous faire un Journal.i (), vous abusez de la ressource de journalisation partagée. Bien sûr, utilisez le bon sens et soyez prudent avec des journaux d'erreurs pour des choses en dehors de votre contrôle (comme les erreurs réseau), ou celles contenues dans des boucles serrées.

Peut-Être Mauvais

Log.i("I am here");

Bon

Log.e("I shouldn't be here");

Avec tout cela à l'esprit, plus votre code est proche de "production ready", 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 peut encore la plupart du temps comprendre 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

Le code source fournit quelques conseils de base:

L'ordre en termes de verbosité, du moins au plus est ERROR, WARN, INFO, DEBUG, VERBOSE. Verbose ne doit jamais être compilé dans une application, sauf pendant le développement. Les journaux de débogage sont compilés mais supprimés lors de l'exécution. Les journaux d'erreurs, d'avertissements et d'informations sont toujours conservés.

Pour plus de détails, la réponse de Kurtis est morte. Je voudrais juste ajouter: Ne connectez pas d'informations personnellement identifiables ou privées à INFO ou supérieur (WARN/ERROR). Sinon, les rapports de bogues ou toute autre chose qui inclut la journalisation peuvent être pollués.

Je pense que le point de ces différents types de journalisation est si vous voulez que votre application filtre essentiellement ses propres journaux. Donc, Verbose pourrait être de consigner absolument tout ce qui est important dans votre application, alors le niveau de débogage enregistrerait un sous-ensemble des journaux verbeux, puis Info level enregistrera un sous-ensemble des journaux de débogage. Lorsque vous arrivez aux journaux D'erreurs, vous voulez simplement enregistrer toute sorte d'erreurs qui ont pu se produire. Il y a aussi un niveau de débogage appelé Fatal pour quand quelque chose frappe vraiment le ventilateur dans votre application.

En général, vous avez raison, c'est fondamentalement arbitraire, et c'est à vous de définir ce qui est considéré comme un journal de débogage par rapport à informationnel, par rapport et erreur, etc. etc.

Le site Web Android Studio {[2] } a récemment (je pense) fourni des conseils sur le type de messages à attendre de différents niveaux de journal qui peuvent être utiles avec la réponse de Kurtis:

• Verbose - affiche tous les messages du journal (par défaut).
• Debug - affiche les messages du journal de débogage qui sont utiles uniquement pendant le développement, ainsi que les niveaux de message plus bas dans cette liste.
• Info - Afficher les messages de journal attendus pour une utilisation régulière, ainsi que les niveaux de message sont plus bas dans cette liste.
• Warn - affiche les problèmes possibles qui ne sont pas encore des erreurs, ainsi que les niveaux de message plus bas dans cette liste.
• Error - affiche les problèmes qui ont causé des erreurs, ainsi que le niveau de message inférieur dans cette liste.
• Assert - Afficher les problèmes que le développeur attend ne devrait jamais se produire.

Vous pouvez utiliser le journal tel que:

Log.e(String, String) (error)
Log.w(String, String) (warning)
Log.i(String, String) (information)
Log.d(String, String) (debug)
Log.v(String, String) (verbose)

Exemple de code:

private static final String TAG = "MyActivity";
...
Log.i(TAG, "MyClass.getView() — get item number " + position);