Quelle structure de journalisation Android utiliser?

Ma question semble être facile à répondre, mais il y a plusieurs bonnes solutions. J’aime choisir le meilleur.

Frameworks disponibles (n’hésitez pas à suggérer plus):

  • Androlog
  • SLF4J Android
  • Log4J – Android

Avantages / inconvénients:

Androlog:

  • Pro: similaire au framework de journalisation Android, il n’y a donc que de petites modifications dans le code existant. Capable d’envoyer des rapports d’erreur avec plus de détails dans le rapport d’erreur (les journaux autour de l’exception); Beaux journaux
  • Con: Pas d’approche java “getLogger” standard; Configuration de production réalisable en téléchargeant le fichier de propriétés sur sdcard; Je dois appeler init logging manuellement; Nécessité de créer des constantes de type LOG_TAG, ou de les pirater pour créer des constantes de balises de journal par Aspect afin d’atteindre le comportement standard: les balises sont les noms de classes; Lorsque la journalisation est une exigence métier, nous devons la tester. Tester les appels statiques sur Android est presque impossible. Logger ne peut pas être injecté par framework

Log4J-Android:

  • Pro: manière standard de se connecter à Java; Compatible avec SLF4J; Capable d’parsingr les fichiers de propriétés;
  • Con: Pas de système de rapport de crash intégré; Il me semble que ce n’est pas communément utilisé, il pourrait donc être dangereux de l’utiliser;

SLF4J-Android:

  • Pro: semble être développé par plus de gens comme Log4J-Android; Le logger.debug("Some log message. Details: {}", someObject.toSsortingng()); est un bon et efficace moyen de sauter des concaténations de chaînes si le consignateur est désactivé; enregistreur de journal léger qui délègue à android.util.Log .
  • Con: Les balises de journal générées automatiquement sont de <= 23 caractères en raison d'une restriction de longueur des balises de journal sur la plate-forme Android (par exemple, balise com.example.myapp.MyClass traduite en c*.e*.m*.MyClass ), ce qui peut avoir pour résultat la même balise de journal pour différentes classes (par exemple, com.example.app.MyClass et com.example.anotherapp.MyClass traduisent tous les deux en c*.e*.a*.MyClass ); Pas de système intégré de rapports de crash.

En plus de cela, j’aime le comportement d’Androlog, mais je suis un développeur Java, familier de log4j / slf4j. Nous aurons certainement besoin d’un système de rapports de crash, mais il existe plusieurs frameworks pour les rapports de plantage (à côté du rapport de panne par défaut d’Android).

Je peux combiner certains d’entre eux, par exemple, utiliser Log4J android, mais créer un appender pour utiliser le framework androlog, mais tôt ou tard ce sera un désordre, qui devrait être évité.

Merci pour vos suggestions, j’espère que les résultats aideront à en décider d’autres à l’avenir.

Edit: Comme mentionné ci-dessous, je peux combiner pour ex: log4j-android avec slf4j (ce que je préfère faire si j’utilise log4j, parce que le formatage du journal prend en charge (“{}”, …)) ne répond pas à la question. Je dois choisir un cadre, puis je peux le décorer avec la façade SLF4J.

Le meilleur moyen Je pense, est d’utiliser l’API SLF4J + une partie de son implémentation.

Pour les applications Android, vous pouvez utiliser les éléments suivants:

  1. Android Logger est l’implémentation légère mais facile à configurer de SLF4J (<50 Kb).
  2. LOGBack est l’ implémentation la plus puissante et la plus optimisée, mais sa taille est d’environ 1 Mo.
  3. Tout autre à votre goût: slf4jandroid , slf4j-android .

S’il vous plaît vérifier cette première réponse

Ça dit:

SLF4J est essentiellement une couche d’abstraction. Ce n’est pas une implémentation de journalisation. Cela signifie que si vous écrivez une bibliothèque et que vous utilisez SLF4J, vous pouvez donner cette bibliothèque à quelqu’un d’autre à utiliser et choisir quelle implémentation de journalisation utiliser avec SLF4J, par exemple log4j ou l’API de journalisation Java. Cela permet d’éviter que les projets dépendent de nombreuses API de journalisation, simplement parce qu’ils utilisent des bibliothèques qui en dépendent.

Donc, pour résumer: SLF4J ne remplace pas log4j, ils travaillent ensemble. Il supprime la dépendance de log4j de votre bibliothèque / application.

J’ai essayé l’ original slf4j.org-android mais malheureusement ce pot n’a pas pu enregistrer les messages de débogage / verbose, car il utilise en interne LOG.isDebugEnabled () pour la sortie de débogage qui semble toujours être fausse.

Actuellement, j’utilise l’ implémentation alternative lp0-slf4j-android qui utilise un fichier de propriétés avec les parameters de journalisation où je peux également obtenir des messages de débogage / verbose si activé.