Does Log.i () affect Android app performance?

Question

I am an old school developer (well, I'm 20, I'm not an old school, I just need to print it, and not use a step-by-step debugger: P), and I have a lot of Log.i () in the Android application. I was wondering if this will affect application performance?

I know that I should use a step-by-step debugger, it just debugs several threads, it can be a little cumbersome.

Thank you for your help!

Answer 1

I don’t think that the log will affect the performance of the application, because when you release the application, you disable it in Android Manifest by setting debuggable :

 <application android:icon="@drawable/icon" android:label="@string/app_name" android:debuggable="false"> 

Answer 2

I am still looking at Android coding, but from what I have seen so far, I would suggest that Android logging suffers from the same problems that most Java logging mechanisms suffer (a notable exception is SLF4J), and exactly

• Logging affects performance because:
  • This means calls to additional methods. (Not a problem for 99% of applications).
  • This often means string assembly (big impact)
  • It uses an extra IO (big hit)

Developers usually deal with this by adding protection blocks.

 if (log.isDebugEnabled()) { log.debug("..."); } 

I think the Android SDK can do this too. it closes # 2 and # 3, but still leaves your release code containing unused logging code. assuming, of course, that you never want to enable debug logging in a release situation.

SFL4J BTW does not require protective blocks because it used type C calls that delay the assembly of the String until it is needed. Unfortunately, it seems that Android has not taken this path. IOS does not have this problem either because it has a pre-compiler. Something that I often desire Java is preserved.

In any case, I would not advocate deleting the log in favor of the debugger. IMHO they serve two different purposes. Logging I find it very useful (if done correctly) in understanding the flow of the application. I often found problems by looking at logs that I would not find in the debugger. I.e. unnecessary code execution for several classes (especially in user interface classes), problems with odd data that do not actually lead to errors, etc. In these situations, using a debugger will resemble trying to lay concrete with a spoon. Debuggers, on the other hand, are ideal for analyzing the subtle details of a problem highlighted by a log.

Thus, in my code, I tend to have enough records that are designed to tell me what the application does in English so that I can easily read and understand what is happening. But I'm strict enough to keep levels as low as possible. I.e. do not record material at the information level, if this is not what you want to see even in release mode. I found that many developers tend to break this.

UPDATE: just read Delete all debugging error messages before posting: are there any tools for this? , which talks about how you can use ProGuard to prohibit registration from the release code. A great idea means that you can’t worry about blocking locks when you log in and bet as many as you want, but rest assured that your release code will be fast.

Answer 3

If you switch to Log.d, you can debug your application and when creating the release version, none of these calls will be compiled or executed.

Answer 4

Yes, he has a performance penalty. check it out: Log.d and performance impact

Answer 5

Answer: yes and no.

It depends on how many log calls you have, and how you talk about debugging in steps, I assume that you are not worried about issuing code at this point (when you obviously remove the excessive logging).

I used excessive logging before it overflowed logcat, but only when I tried to track a particularly elusive problem in my debugging code - this message was deleted as soon as I tracked the problem.

In short, register as much as you want in development, but do not force it on the user.