When logging in production using timber, you can easily exclude certain log levels to prevent sensitive debug data from transmitting online.
private inner class CrashReportingTree : Timber.Tree() {
override fun log(priority: Int, tag: String?, logMessage: String, throwable: Throwable?) {
if (priority == Log.ERROR || priority == Log.INFO) {
FirebaseCrashlytics.getInstance().log(logMessage)
if (throwable != null) {
FirebaseCrashlytics.getInstance().recordException(throwable)
}
} else return
}
}
What this doesnt do is ignore the said logs. If timber comes across a debug log in the above case, it will still be processed completely until the time comes to actually log it, for e.g. operations like formatting and splitting. This can create a performance overhead in production if the logging is being done generously and with potentially large data like network request results.
There is a way where you can tell Timber if it should ignore certain log types completely and not process the log message at all.
private class CrashReportingTree : Timber.Tree() {
override fun log(priority: Int, tag: String?, logMessage: String, throwable: Throwable?) {
if (!isLoggable(tag, priority)) {
return // Skip logging if not loggable
} else {
FirebaseCrashlytics.getInstance().log(logMessage)
if (throwable != null) {
FirebaseCrashlytics.getInstance().recordException(throwable)
}
}
}
// Overridden to stop processing of all logs less then info level within Timber
override fun isLoggable(tag: String?, priority: Int): Boolean {
return priority >= Log.INFO
}
}
Overriding isLoggable tells the Timber api to match and process only allowed log types internally before it does any processing
timber/timber/src/main/java/timber/log/Timber.kt
Hope this brings some finer performance boost to your apps
Top comments (4)
Hey, it's nice raising awareness about thte
isLoggablefunction. But like you mention yourself, Timber already usesisLoggableinternally inprepareLogto avoid processing some logs, so there's no need to call it yourself again in yourTree'slogmethod, as its redundant at that point.Hey Eduard,
I know what you are saying. I also thought about it. Thing is overriding
isLoggablewill stop the processing but I wanted to ensure that nothing unwanted gets sent to Crashlytics. I could probably do a test to verify the redundancy of theisLoggablebut I got lazy there.Timber already has unit tests for this here, so I don't think that there's more testing you would need to do. Unless you don't trust the library, that is.
Thanks for pointing out the Unit test. Im still in process of learning testing and it's not really a second nature to me.