[JAVA] Richtige Protokollausgabemethode unter Android (Standardprotokollklasse vs AnkoLogger)

Hintergrund

Einführung von AnkoLogger, entwickelt von JetBrains als OSS für die Java-> Kotlin-Migration. Ich habe es versucht, aber selbst wenn ich ein ausführliches Protokoll und ein Debug-Protokoll ausgegeben habe, wurde es nicht in logcat von Android Studio ausgegeben. Bei der Untersuchung der Ursache habe ich festgestellt, dass ich das Verhalten der Standard-Log-Klasse "android.util.Log" und nicht das Problem von AnkoLogger falsch verstanden habe. ..

Protokollstufe und Verhalten jeder Bibliothek

Wenn ich nach meiner eigenen Erkenntnis "Log.d (TAG," foo ")" schreibe, wird das Protokoll ausgegeben, wenn die Protokollstufe debuggt oder niedriger ist (dh debuggen, ausführlich) und sich ausführlich in der Entwicklungsumgebung befindet. Ich habe mich gefragt, ob ich mir das Debug-Protokoll angesehen habe, weil die Protokollebene ausführlich war. Zusammenfassend war die Erkennung von ↑ falsch und die Standardprotokollstufe war info. Der Grund, warum das ausführliche / Debug-Protokoll ausgegeben wird, ist, dass selbst wenn Sie ** Log.d (TAG," foo ") schreiben, das Protokoll unabhängig von der Protokollstufe ** tatsächlich ausgegeben wird **. Es ist notwendig, die Protokollebene nach einer anderen Methode zu beurteilen und sie zu trennen. Sie muss mit der if-Anweisung wie folgt gesteuert werden. (Übrigens wird die Protokollstufe für jedes Tag festgelegt)

if ( Log.isLoggable(TAG, DEBUG) ) Log.d(TAG, "foo");

Warum ist es so eine redundante Spezifikation? ..

Auf der anderen Seite Anko Logger

debug("foo") //Das Tag ist standardmäßig der Name der aufrufenden Aktivität

Wenn Sie schreiben, wird die Protokollstufe intern bestimmt. Die Benutzerseite wird gemäß der Protokollebene ausgegeben, ohne eine if-Anweisung zu schreiben. Persönlich ist dies definitiv intuitiver. Dieselbe Frage wurde zum Thema Github gestellt, daher bin ich nicht der einzige, der die Spezifikationen der Standard-Log-Klasse missverstanden hat.

Zusammenfassung

Wenn Sie es erneut organisieren,

• Standard Log Klasse

• Wenn Sie nicht explizit mit "Log.isLoggable" steuern, werden alle Protokolle auch in der Produktion ausgegeben (Protokollebene: Info), was zu Leistungseinbußen führt. --Wenn Sie nicht explizit mit Log.isLoggable steuern, können Sie das Protokoll mit logcat überprüfen, ohne etwas zu tun. Bedeutung Einfach während der Entwicklung
• Die korrekte Verwendung ist hier
• Es scheint eine andere Möglichkeit zu geben, um zu verhindern, dass ProGuard nur Release-Builds protokolliert.

• AnkoLogger

• In der Produktion (Protokollstufe: Info) werden nur Protokolle ausgegeben, die höher als Info sind, sodass keine unnötigen Leistungseinbußen auftreten.
• Wenn Sie die Protokollstufe mit adb usw. während der Entwicklung nicht ändern, können Sie das Protokoll mit logcat nicht sehen, was ein wenig problematisch ist. ex. $ adb shell setprop log.tag.MainActivity VERBOSE

Aufgrund der Klarheit und Sicherheit des Codes bevorzuge ich persönlich die Verwendung von AnkoLogger. Wenn Sie Java verwenden oder keine nutzlosen abhängigen Bibliotheken einschließen möchten, möchten Sie möglicherweise eine AnkoLogger-ähnliche Standard-Log-Wrapper-Klasse erstellen.