This week we spoke with
Py from Square and heard about the new logcat library! Py gave some excellent explanations and discussions into the decisions behind
logcat. I’ll outline them below in a Question/Answer format:
Q: What are some challenges that are faced with logging at scale?
- A: Scale can mean many things so in this case we’ll consider it as many engineers and many lines of code. There needs to be a way to handle logging in debug and release builds. Its not usually useful in release builds so logcat helps with this in a performant way. No need for
if (DEBUG) { Log.d() }
- There can also be some performance improvements. Timber captures a stacktrace to figure out the tag of the log and this was happening in production. logcat uses lambdas to evaluate only when needed.
Q: What are some benefits to using logcat?
- A: You can use Kotlin’s String interpolation for your logs! Much nicer than needing to use formatted Strings.
Q: Because of the lambda approach to logging are there any problems with issue reproduction because a debug builds will have different code paths than a release build?
- A: Yes there is an impact to logging but we don’t dynamically handle logging for different contexts. We could have logging on all the time to have the same code paths. We are generally okay with having a bit more lag in a debug build.
- However, this is interesting because with logcat using lambdas we could evaluate how long lambdas take to run and then call out any lambdas that take longer to run than expected.
Q: How is tagging handled?
- A: It’s a bit of a hack but it’s pretty cool. I made logcat an extension on
Any and therefore have access to this. Then I can call this::class.java.name to get the class name! It’s not perfect because sometimes you won’t have a this and sometimes your this might not be a class in different contexts, but it should work for most cases. In cases where it doesn’t work you can supply your own tag as a parameter.
- We are looking into what a Kotlin Compiler plugin would look like for this and be able to get even more information for the tag here.
Q: What happens if you log from a background thread? Does this cause any memory issues?
- A: It shouldn’t cause any memory issues. Its always a final reference so
this will never change on different threads.
Q: One of my favorite features from Timber is being able to plant different trees to log to different services, is this something that is supported in logcat?
- A: Yes and no. Yes you can do this but we don’t really want you to.
- Yes you can do that because you can set one logger that would delegate to whatever.
- No because we really just want this to log to Android’s Logcat. When you add this feature logging at scale can become tricky because people start forgetting the rules. What logger will log to what? I recommend having different APIs for logging to where you want to log. This way it is explicit where your logs will end up.
Q: Why was log priority removed?
- A: Most engineers just want to log to debug so why make it required? If you want to log to something else then you can use the priority parameter.
Q: Why was Throwable removed from the supported parameters?
- A: I never remember the order of the parameters. So to make logging easier there is an extension function
Throwable.asLog() and you no longer need to think about which function to use.
Q: Is there any future plans for Kotlin Multiplatform compatibility?
- A: Not really, but not against it. The name wouldn’t really make much since because there is a chance it wont run on Android!
Q: What’s coming next from you Py?
- A: I’m primarily focused on performance right now and I have a bunch of articles written about it. There’s also a new library from Google for performance coming soon that can be found in the source and I’m looking into to see if it’s something that can help measure jank.
