我正在开发一个android应用程序代码库,其中程序员已正确记录了每种应用程序方法的开始和退出。我发现这很奇怪,但是同时了解应用程序流程非常有帮助。这种做法节省了我的大量调试工作,使他们可以理解现有的代码流以识别错误的方法。
所以,我很好奇,以上述方式记录每种方法是一种好习惯吗?(我们总是可以设置一个标记,以便仅在需要时/调试时启用此类日志)。>
谢谢
答案 0 :(得分:1)
这是非常有效的,但是在特定情况下,考虑到存在多个线程,这实际上会对系统资源造成毁灭性影响,尤其是如果您登录到单个文件。但这可以通过将日志记录减少到可以在运行时切换的特定线程来解决。
我的实现方式是:-
class Tracer{ void informCall(Object...callArgs){ meth=TraceUtils.getPreviousMethod(); if(noCondition||tracerCodition.trace(Trace.getCallerStackTraceElement())){ //since trace method can know which thread we are in that is not a necessary argument TraceLogger.inform(TraceType.Method,meth.traceString()+"/nargs:/n"+TraceUtils.argsString(callArgs)); } } }
注意:指定跟踪条件可以提高调试效率,并且可以将搜索集中在特定点,例如,可能将跟踪条件下的方法设置为执行,直到达到特定条件为止。方法终止太快,那么这将意味着跟踪将不会高效,特别是在存在资源的故意竞争条件或将日志写入文件但设置跟踪条件以仅跟踪方法或调用的特定数量的情况下在某些时间间隔内,这将有助于提高效率。
答案 1 :(得分:1)
所以,我很好奇,以上述方式记录每种方法是一种好习惯吗? (我们总是可以放一个标记,使其仅在需要时/调试时启用此类日志)。
总而言之,不是
这当然不是被广泛接受的优良作法 1 。
这里有一些优点和缺点:
是的:如果已实现,则跟踪日志记录信息将非常有用。
是的:您可以关闭跟踪记录。
否:对于非平凡的应用程序,跟踪日志记录的数量可能非常庞大。存储太多。太多分析。太多要求客户发送给您。
否:即使使用日志记录语句 2 上的运行时防护禁用了日志记录,也存在日志记录的运行时开销。
否:每个方法开头和结尾处的额外日志记录语句都是“混乱的”,使代码难以阅读。
否:假设手动添加了额外的日志记录语句,那就是额外的编程工作和额外的错误源。 (而且这些bug可能很难在测试中发现。您是否要编写单元测试/以检查跟踪是否已正确实施的任何内容?)
否:如果代码是多线程的,跟踪调试可以更改代码的行为。例如,在非线程安全的应用程序中,打开跟踪可能导致意外同步。这可能会导致错误应用程序的行为发生变化。 c.f. Heisenbug。
最后,您的IDE调试器可以允许您记录方法的进入和退出 自动执行,而无需在源代码级别执行任何操作。 (当然,这对解决Heisenbug问题没有帮助;请参见上文。)
1-如果是这样,您会在许多/大多数开源代码库中看到这种做法。我不记得曾经见过它。
2-如果您找到一种使用预处理器禁用它的方法,或者构建/加载时间代码注入或使用if (compileTimeConstFlag)
构造,则可以消除开销。但是,这样您就失去了打开和关闭跟踪的灵活性。而且对您的源代码的影响更大。