我可以在发布版本中保留日志记录吗?

发布于 2024-09-17 19:08:13 字数 290 浏览 4 评论 0原文

我已阅读 这个问题提倡将 NSLog 语句从发布版本中取出。

是否可以接受,而不是用垃圾扰乱主日志,而是将其写入 Apple 系统日志,然后将其从主日志中隐藏?

或者我只是把事情复杂化了?在某些情况下,日志记录对于您在发布后查明应用程序中的错误很有用吗?

I've read this question which advocates taking NSLog statements out of Release builds.

Is it acceptable to, instead of cluttering the main log up with junk, write it to Apple System Log instead, then it'd be hidden from the main log?

Or am I just overcomplicating things? Are there any instances where logging has been useful to you in pinpointing a bug in an app after release?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

神仙妹妹 2024-09-24 19:08:13

我发现我在开发过程中添加的日志消息通常会执行以下三件事之一:

  1. 帮助调试和测试新的、未完成的功能和代码路径
  2. 提供有关程序正常运行的信息,例如任务完成和常见错误情况(例如没有互联网连接) )。
  3. 提供有关异常或意外事件的详细信息,包括危险或未专门处理的错误情况、软件更新以及来自服务器连接或文件的格式错误的数据

第一类消息 我通常在功能完成后删除 第二类消息我使用类似链接问题中的宏来过滤掉,以及我在版本中留下的第三类消息。

显然,界限是模糊的,但我认为这归根结底是尊重日志。如果您的应用程序充斥着无用的信息,则可能很难注意到其他应用程序的错误,并且会造成(小)资源消耗。

对于处于灰色区域的消息来说,使用 ASL 函数来记录大多数用户看不到的优先级较低的消息(例如 debuginfo)是一个好主意。

I find that log messages I add during development generally do one of three things:

  1. Aid in debugging and testing new, unfinished features and code paths
  2. Provide information about the normal operation of the program such as task completion and common error conditions (e.g. no internet connection).
  3. Provide detailed information about unusual or unexpected events, including error conditions that are dangerous or not specifically handled, software updates, and malformed data coming from a server connection or file

Messages in category one I usually remove when the feature is complete, messages in category two I filter out with a macro like the one in the linked question, and messages in category three I leave in the release.

Obviously the lines are blurry, but I think it comes down to respecting the log. If your application floods it with information that isn't useful, it could make it difficult to notice errors from other applications, and will be a (small) resource drain.

Using ASL functions to log messages with lower priorities like debug and info that won't be visible to most users is a great idea for messages that fall in a grey area.

み青杉依旧 2024-09-24 19:08:13

还有这个问题询问任何性能通过删除陈述来获得优势。陪审团似乎仍然没有确定任何硬性数字,但传统观点认为,可以通过以宏为条件包含它们来删除它们。您仍然可以获得调试信息,并且用户可以获得一个没有混乱的应用程序。

There is also this question that asks about any performance advantage by taking the statements out. The jury looks to still be out on any hard numbers, but conventional wisdom says to remove them by making their inclusion conditional with a macro. You still get your debugging info, and the user gets an app free of clutter.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文