objective-c - iOS-应用程序日志记录测试和生产代码

Question

在测试应用程序时，我会进行大量日志记录，这对于获取有关变量状态等信息非常有用。

但是，我读到您应该在生产代码中稀疏地使用日志记录(因为它可能会减慢您的应用程序的速度)。但是现在我的问题是:如果我的应用正在生产中并且人们正在使用它，那么无论何时发生崩溃(上帝禁止)，如果删除了日志记录语句，我将如何解释崩溃信息？然后我想我只有一个堆栈跟踪信息供我解释？

这是否意味着我只应该保留登录生产代码的位置，对我来说解释发生的事情真的很重要吗？

日志记录语句也将与崩溃报告相关联吗？他们会合并吗？我正在考虑将Flurry用作分析和崩溃报告...

Answer 1

您绝对应该在已发布的应用程序中包含大量日志记录。如您所怀疑，它可以在调试时极大地帮助您，甚至在您确保日志消息用词正确，合理地自我解释并包括所有相关详细信息时，甚至可以帮助高级用户进行自我调试。

一个好的日志系统有很多方面。有一些常见的模式通常很容易遵循(尽管在iOS上，某些特定模式比其他模式更适用):

按严重性区分您的日志。例如，错误，警告，提示，调试。另一个示例是Syslog。除了可以帮助您首先关注更严重的问题外，还可以为发布版本的“信息性”设置最低级别，例如，从而排除更冗长的调试代码，同时保留所有您在事情发生时需要的所有代码。出错。这样，您就可以剪掉可能非常冗长或频繁的日志消息(因此可能会降低应用程序的运行速度)，而留下重要的消息。

允许在运行时配置日志记录级别(通常通过命令行标志完成，尽管显然不在iOS上)。例如，默认情况下，您可以只显示警告和错误，但可以选择通过标志将其扩展。

至少在调试版本中，在所有日志消息中包括文件名和行号。您可能会对在发行版本中包含文件名有所保留，但至少要包含行号-这将有助于确保在调试时使用正确的代码；您可能(偶然或有意地)在同一文件的多个位置具有相似的日志语句。

用简单的英语写出您的日志消息，语法好，缩写少，并包括所有相关变量的值。在错误或警告的情况下，还应包括有关状况后果的声明。例如“无法连接到someserver:1234-错误-18(ETIMEOUT)。无法确定是否有可用的应用程序更新。”。

最小化日志中用户敏感的数据，并非常小心处理包含该日志的任何日志。永远不要记录密码或类似性质的信息-甚至不要记录诸如长度或哈希值之类的辅助信息。请注意，即使他们提供的网站地址之类的看起来不错的东西也可以被认为是敏感的(他们可能不希望知道他们经常访问www.lumberjacksandpressedwildflowers.com)。如果您可以传输这些日志，则这尤其重要-您将需要采用SSL等。

您可以从预建的日志记录系统中获得很多这些功能，例如 CocoaLumberjack和 NSLogger(或 both)。毫无疑问，还有其他人。