iOS11/Xcode 9中的TIC Read Status 1:57是什么?

159

更新为Xcode 9后,使用Swift 3和iPhone X模拟器时,我的控制台充满了以下内容:

TIC Read Status [11:0x0]: 1:57
TIC Read Status [11:0x0]: 1:57
TIC Read Status [11:0x0]: 1:57
...

那是什么,我该如何修复它?非常感谢您的帮助。

附注:我不想仅通过在构建方案中使用“环境变量”来“消音”它。


1
可能是 https://dev59.com/rJvga4cB1Zd3GeqP9OgZ 的重复问题。 - timgcarlson
5
好的,我会尽力做到以下翻译:嗯,我也找到了这个帖子。但它是关于OSX的,而且比较老,没有得到很好的回答... - David Seek
你找到解决方案了吗? - Kodr.F
@Jack。不,一点也不。 - David Seek
2
讨厌的事情不仅仅是它在控制台上记录了日志,而且似乎还挂起了主线程。 - Hogdotmac
1
是的,我注意到它只在调试模式下才有效。 - David Seek
7个回答

183

苹果员工给出了以下答案:

TIC 是 “TCP I/O connection” 的缩写,是 CFNetwork 中的一个子系统,用于运行 TCP 连接

157 是 CFStreamError 域和代码,分别表示域为 1 的 kCFStreamErrorDomainPOSIX,而在该域中,57 表示 ENOTCONN

简而言之,TCP 读取失败并显示 ENOTCONN。

由于 TCP I/O 连接子系统没有公共 API,因此您必须通过一些高级封装器(如NSURLSession)使用它。

来源: https://forums.developer.apple.com/thread/66058

编辑/更新:

由于我们仍然有这些烦人的日志记录,我向上面链接中的同一位苹果专家询问了我们的情况,现在已经特定于 Xcode 9 和 Swift 4。下面是他的回答:

许多人抱怨这些日志,自从我升级到Xcode 9 / iOS 11以来,我所有的应用程序都有这些日志。

2017-10-24 15:26:49.120556-0300 MyApp[1092:314222] TIC Read Status [55:0x0]: 1:57  
2017-10-24 15:26:49.120668-0300 MyApp[1092:314222] TIC Read Status [55:0x0]: 1:57  
2017-10-24 15:26:49.626199-0300 MyApp[1092:314617] TIC Read Status [56:0x0]: 1:57

他的回答:

需要认识到,这个 ENOTCONN 并不一定意味着出现了问题。在所有版本的HTTP中,关闭的TCP连接都是预期的。因此,除非与此错误有其他症状相关联,否则我的建议是忽略它。

来源:https://forums.developer.apple.com/message/272678#272678

解决方案:只需等待Xcode 9的更新版本即可。


30
这并不仅限于Swift。我在使用Objective-C时也会遇到这个问题。 - Victor Engel
8
你真的超出了预期来得到这个答案。 - G. LC
7
您的解决方法似乎没有生效,因为它仍然存在于XCode10中。 - Gennadii Tsypenko
2
我们必须找到一种方法来摆脱这个问题,因为在运行时打印日志会影响应用程序的性能。目前我们只能希望,在非 #DEBUG 构建中不会打印这些日志。 - Stoyan
6
希望有一些设置,这样我们就可以真正地“忽略它”。 - Zaporozhchenko Oleksandr
既然看起来是要忽略它,那我就把这个留在这里。基本上,你可以通过设置一个环境变量 OS_ACTIVITY_MODE = disable 来忽略所有奇怪的系统控制台输出。链接:https://forums.developer.apple.com/thread/51196#thread-message-182684 - AverageHelper

41

以下是 TIC Read Status [11:0x0]: 1:57 的详细信息:

TIC 表示“TCP I/O connection”,是 CFNetwork 中运行 TCP 连接的子系统。

11 是 TIC 内部的连接 ID 编号。

0x0 是指向 TIC 对象本身的指针。

157 分别是 CFStreamError 的域和代码;域为 1 表示 kCFStreamErrorDomainPOSIX,在这个域内,57 表示 ENOTCONN 错误。

来源:https://forums.developer.apple.com/thread/66058


好的。到目前为止都很好。这是什么坏消息还是只是一些信息?我需要修复什么吗? - David Seek
我相信这与iOS11.0有关,可能会在未来的版本中得到修复。 - 0rt
8
为什么会发生这种情况?为什么它突然从iOS 11开始出现? - Lane Rettig
我也在日志中收到了很多这样的信息,但我的所有网络调用都正常工作 :L - user8193429
这个问题我该怎么办? - Genevios
显示剩余3条评论

35
注意:正如@David在评论中提到的那样,这是一种隐藏警告的方法,因此请使用此启动参数以避免获得许多重复的消息并使控制台保持干净。调试完成后,请将其禁用,因为启用时控制台不提供有用的信息。例如libc++abi.dylib: terminating with uncaught exception of type NSException
对于想知道如何消除警告的人,直到更好的解决方案出现,您可以将下面的变量随时准备好并进行切换。
在产品方案的参数下使用OS_ACTIVITY_MODE = disable环境变量以避免控制台被此类警告淹没。
注B:启用它以查看效果。
来源:https://medium.com/@adinugroho/disable-os-logging-in-xcode-8-ec6d38502532

enter image description here


13
我实际上已经说过,我不想要他的建议^^ 仅仅将其压制并不能解决问题。 - David Seek
23
人们需要停止建议禁用所有日志记录语句。像这样的回答应该被删除。 - Claus Jørgensen

6

针对这种类似日志消息以及其他(例如不一定是错误的NSURLSession错误)问题,我发现最好的方法是使用自己的日志函数。

class Logger {
    static var project: String = "MyProject"

    static func log(_ string: String, label: String = "") {
        DispatchQueue.main.async {
            print("[\(Logger.project)] \(label) : \(string)")
        }
    }

    static func info(_ string: String) {
        Logger.log(string)
    }

    static func warning(_ string: String) {
        Logger.log(string, label: "WARNING")
    }

    static func error(_ string: String) {
        Logger.log(string, label: "ERROR")
    }
}

然后我只需在控制台底部的过滤器中输入[MyProject],就完成了。

请注意,通过在主队列上调用print,可以使您的记录器在不混淆控制台的情况下从线程中使用。

准备好根据您的需求进行改进和调整 :)


检查 "os_log"。这是苹果推荐用于高级日志记录的方式。 - user1105951

0
我曾经遇到过同样的问题,当我调用REST(GET)服务时,响应中会出现'}'。
使用:
URLCache.shared.removeCachedResponse(for: request as URLRequest)

在进行URL请求后,当我收到响应后重置我的URLSession对象:

session.reset(completionHandler: {
  // print(\(data))                          
})

问题已解决。


1
即使我的应用程序只是调用 Firebase,这也无法解决我的问题。而且我无法操纵框架。但我会将此转发给 Firebase 开发团队。也许他们可以对此做些什么。 - David Seek

0

这是一个日志,表示TCP连接丢失/关闭/无效或其他情况。如果您的应用程序有一个运行中的tcp连接,并且该应用程序在一段时间内被放置在后台,或者您关闭了手机屏幕,这可能会发生。操作系统决定尽可能停止资源以减少电池耗电量。如果您将应用程序带到前台,则之前的tcp连接将不再起作用。您需要创建一个新的tcp连接。

如果它不影响您,请忽略它。


0
我们通过在 Web 服务器上禁用 HTTP/2 来解决了此日志记录问题。 在我们的情况下,我们已经从传统的 ELB 迁移到了支持 AWS 上的 HTTP/2 的应用程序 ELB,并开始在 XCode 10.1 / iOS 12 控制台上获取“TIC Read Status [11:0x0]: 1:57”的报错。如果 Apple 修复了 HTTP/2 的问题,则这似乎是一个临时解决方案。对于每个人来说,该解决方案可能都不适用,特别是如果您正在使用第三方 API ,但它可以让您更好地了解问题。

4
现在距离苹果推出这个...我们称之为...功能已经有1.5年了,我不认为这会很快被“修复”。 - David Seek

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接