android调试记录
调试是la脚的。 您应该调试日志。
如果您的代码是结构化的,则不需要调试日志记录。
这是该行两端的两种观点。 我通常会站在中间,我会告诉你为什么。
首先,调试和日志记录之间没有主要区别。 它们只是同一件事的两个不同实现:在时间维度上观察执行引擎状态。
调试问题
调试时,您可以按时向前推进程序,并且在任何时候执行停止时,您都可以检查任何变量的值。 短缺之处在于您无法退后。 在某些时候,您意识到您只是想看看某个变量的值在调用某个方法,创建某个对象或系统中发生任何事情之前是什么。 在这种情况下,您实际要做的是重新启动代码,并希望它能按确定性的方式尝试在您感兴趣的较早阶段捕获执行。这是调试的另一个不足。 您不能有效地调试不具有确定性的代码。 相信我:大多数错误的行为都是不确定的。
记录问题
对于日志,主要问题不同。 这不是时间,而是状态的广度,您可以查看的变量就是问题。 您将日志语句插入代码中,并在特定执行点将变量的值转储到日志文件中。 当您检查日志文件时,可以来回滚动。 但是,如果您没有在某个执行点上打印出某个变量的值,则无法从日志文件中获取它。 解决方案与调试相同:再次执行代码,这次使用新的log语句进行扩展。 但是,如果您的日志文件中包含足够的信息,那么即使不确定,但您将仅获得足够的信息来跟踪错误。 只有“如果有”……
解决方案:始终记录所有状态?
理想的解决方案是在执行的每个状态下将所有变量都转储到可能的二进制日志文件中,然后再检查文件的内容。 除了变量的更改来自记录的日志文件而不是动态计算之外,检查基本上看起来像是调试器。 这就像回放已录制的执行,因此您可以将其重播几次。 我不知道是否有用于JVM的工具。
您只是无法在像JVM这样的多线程执行环境中有效定义什么是“每个状态”。 这是问题之一。 另一件事是,如果要在每个命令之后开始转储JVM内存(忘记多线程问题),则将需要大量带宽和磁盘空间。
梦想无法交付的理想解决方案是没有用的。 实际上可以执行的解决方案是什么?
实用方法
您可以在适当的时候进行调试。 句号 到目前为止,您只是这样做,请继续这样做。 即使在调试某些代码时,我也倾向于使用日志语句,如果环境允许,我会即时执行。 当我找到问题的根本原因时,我正在检查日志语句并删除它们。 他们在调试时完成了工作,不再需要它们。 至少那是我的练习单元,我发现自己正在写以前已经创建的日志语句。 为什么? 因为修复一个错误并不意味着我已经修复了所有错误。 没有像所有已修复的错误一样的东西。 但是日志项散乱了日志文件,这增加了寻找下一个错误所需的信息的工作。 换句话说,日志文件充满了噪音,这就是为什么我首先删除这些项目的原因。 但是出于同样的原因,我也可以删除已经通过的单元测试。 这样可以节省很多时间,不是吗? 我们不这样做。
一句话总结? 记录并调试适合您的方式以及您要寻找的问题。
翻译自: https://www.javacodegeeks.com/2014/03/logging-or-debugging.html
android调试记录