Log.i（）是否会影响Android应用程序的性能？

我是一个老派的开发者（好吧，我20岁了，我不是老派的，我只是喜欢打印出来，而不是使用一步一步的调试器：p），我在Android应用程序中有很多Log.I（）调用。我想知道这是否会对应用程序的性能产生影响

我知道我应该使用一个循序渐进的调试器，只是调试多个线程可能有点麻烦

---

谢谢你的帮助

是的，它确实有性能损失。选中此项：

如果切换到Log.d，则可以调试应用程序，并且在构建发布版本时，不会编译或执行这些调用。

答案是“是”和“否”

这取决于您有多少个日志调用，并且当您谈论步骤调试时，我猜您在这个阶段并不担心发布代码（当您显然要删除过多的日志时）

我使用了过多的日志记录，以至于它溢出了logcat，但只有在我试图跟踪调试代码中一个特别难以捉摸的问题时，日志记录才在我跟踪问题时被删除

---

简而言之，在开发过程中尽可能多地记录日志，但不要强加给用户。

我认为日志不会影响应用程序的性能，因为在发布应用程序时，您可以在Android清单中通过设置

可调试

将其关闭：

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

---

我自己仍在研究Android编码，但根据我目前所看到的情况，我认为Android日志与大多数Java日志框架面临的问题相同（SLF4J是一个显著的例外），即：

• 日志记录不会影响性能，因为：
• 它意味着额外的方法调用。（对于99%的应用程序来说，这不是一个问题）
• 这通常意味着管柱组装工作（大影响）
• 它需要额外的IO（大影响）

开发人员通常通过添加保护块来处理这个问题

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

我认为Android SDK也可以做到这一点。它覆盖了#2和#3，但仍然让您的发布代码包含未使用的日志代码。当然，假设您永远不希望在发布环境中启用调试日志记录

SFL4J BTW不需要保护块，因为它使用了类似C的方法调用来延迟字符串组装，直到实际需要为止。不幸的是，Android似乎没有走上这条道路。iOS也没有这个问题，因为它有一个预编译器。我经常希望Java能保留一些东西

无论如何，我不主张为了调试器而删除日志记录。我认为它们有两个不同的用途。我发现日志记录对于理解应用程序的流程非常有用（如果做得好的话）。我经常通过查看在调试器中找不到的日志来发现问题。例如，跨多个类执行不必要的代码（特别是在UI类中）、不会导致实际错误的奇怪数据问题等。在这些情况下，使用调试器就像是试图用勺子浇筑混凝土。另一方面，调试器非常适合分析日志突出显示的问题的细节

因此，在我的代码中，我倾向于有大量的日志记录，这些日志记录旨在以类似英语的方式告诉我应用程序正在做什么，这样我就可以轻松阅读并理解正在发生的事情。但我对保持尽可能低的水平相当严格。不要在信息级别记录东西，除非你想在发布模式下看到。我发现很多开发人员倾向于打破这一点

---

更新：请阅读关于如何使用ProGuard从发布代码中删除日志记录的内容。好主意，这意味着您不必费心在日志上设置保护块，并且可以随心所欲地添加保护块，但仍然可以确保您的发布代码会很快。

我需要稍微编辑一下，您的Log.d函数当然仍然预编译到dalvik vm中；但是，它永远不会完全执行日志函数。您仍在执行方法调用，但此调用的影响最小，特别是对于2.2的缓存功能。清单中的可调试语句将影响Log.d语句，但Log.i、Log.e仍将存在，如果应用程序中的语句太多，则会影响应用程序的性能。