在调试构建的每种方法中添加日志的优缺点是什么？ [关闭]

Question

我正在开发一个程序员已正确记录每个方法的 android 应用程序代码库。我发现了解应用程序流程非常有帮助。这种做法节省了许多调试工作，以了解当前的代码流以识别有问题的方法。

所以，我很好奇记录每种方法的优缺点（日志仅用于调试构建类型）。

谢谢

Answer 1

所以，我很好奇，以上述方式记录每个方法是否是一种好习惯？ （我们总是可以设置一个标志，仅在需要/调试时启用此类日志）。

总的来说，没有。

这当然不是被广泛接受作为良好做法¹。

以下是一些优点和缺点：

1. 是的：如果你已经实现了，那么跟踪日志信息很有用。

2. 是的：您可以关闭跟踪日志记录。

3. 否：对于一个重要的应用程序，跟踪日志记录的数量可能会很大。存储太多。太多了，无法分析。要求客户寄给您太多了。

4. 否：日志记录存在运行时开销...即使在日志记录语句² 上使用运行时保护禁用了日志记录。

5. 否：每个方法开头和结尾的额外日志记录语句“杂乱无章”，使代码更难阅读。

6. 否：假设额外的日志语句是手动添加的，那就是额外的编程工作和额外的错误来源。 （而且这些错误在测试中可能很难发现。您是否要编写单元测试/任何东西来检查跟踪是否已正确实施？）

7. 否：如果代码是多线程的，跟踪调试可以改变代码的行为。例如，打开跟踪可能会导致非线程安全应用程序中的偶然同步。这可能会导致错误应用程序的行为发生变化；参考文献Heisenbug。

最后，您的 IDE 的调试器可能允许您记录方法的进入和退出 自动在源代码级别不做任何事情。 （当然，这对解决 Heisenbug 问题没有帮助；见上文。）

---

^{1 - 如果是这样，您会在许多/大多数开源代码库中看到这种做法。我不记得曾经见过它。}

^{2 - 如果您找到使用预处理器禁用它的方法，或者构建/加载时间代码注入，或if (compileTimeConstFlag) 构造，您可以消除开销。但是，您将失去打开和关闭跟踪的灵活性。而且对你的源代码的影响更大。}

Answer 2

它非常有效，但在特定情况下，假设有多个线程，它实际上会对系统资源造成破坏性影响，尤其是在您登录到单个文件时。但这可以通过将日志记录减少到可以在运行时切换的特定线程来解决。
我的实现是：-

类示踪{ 无效通知调用（对象...callArgs）{ meth=TraceUtils.getPreviousMethod(); if(noCondition||tracerCodition.trace(Trace.getCallerStackTraceElement())){ //因为跟踪方法可以知道我们在哪个线程中，所以不是必要的参数 TraceLogger.inform(TraceType.Method,meth.traceString()+"/nargs:/n"+TraceUtils.argsString(callArgs)); } } }

注意： 指定跟踪条件可以提高调试效率，也可以将搜索集中在特定点，例如，如果某个特定的跟踪方法被设置为执行直到达到某个条件方法终止太快，则意味着跟踪效率不高，特别是在存在故意的资源竞争条件或将日志写入文件但设置跟踪条件以仅跟踪特定数量的方法调用或在特定的时间间隔，这将有助于提高效率。