什么是 iOS11/Xcode 9 中的 TIC 读取状态 1:57?
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/46352735/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What is TIC Read Status 1:57 in iOS11/Xcode 9?
提问by David Seek
After updating to Xcode 9, using Swift 3 and the iPhone X simulator, my console is full of:
更新到 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
...
What is that and how do I fix it? Help is very appreciated.
那是什么,我该如何解决?非常感谢帮助。
PS: I prefer not to just "silence" it with an Environment Variable
in the build scheme.
PS:我不喜欢Environment Variable
在构建方案中使用一个“沉默”它。
回答by rgoncalv
Apple staff gave the following answer:
苹果工作人员给出了如下回答:
TIC
expands to “TCP I/O connection”, which is a subsystem within CFNetwork that runs a TCP connection
TIC
扩展为“TCP I/O 连接”,它是 CFNetwork 中运行 TCP 连接的子系统
1
and 57
are the CFStreamError domain and code, respectively; a domain of 1 is kCFStreamErrorDomainPOSIX and, within that domain, 57
is ENOTCONN
1
和57
分别是 CFStreamError 域和代码;1 的域是 kCFStreamErrorDomainPOSIX 并且在该域内57
是 ENOTCONN
In short, a TCP read has failed with ENOTCONN.
简而言之,使用 ENOTCONN 的 TCP 读取失败。
As the TCP I/O connection subsystem has no public API, you must necessarily be using it via some high-level wrapper (like NSURLSession).
由于 TCP I/O 连接子系统没有公共 API,您必须通过一些高级包装器(如 NSURLSession)使用它。
source: https://forums.developer.apple.com/thread/66058
来源:https: //forums.developer.apple.com/thread/66058
EDIT/UPDATE:
编辑/更新:
Since we are all still having these annoying logs, I asked to the same Apple specialist from the above link about our situation, which is now specific for Xcode 9 and Swift 4. Here it is:
由于我们仍然有这些烦人的日志,我从上面的链接向同一位 Apple 专家询问了我们的情况,现在特定于 Xcode 9 和 Swift 4。这里是:
A lot of people are complaining about these logs, which I am having as well in all my apps since I upgraded to Xcode 9 / iOS 11.
很多人都在抱怨这些日志,自从我升级到 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
His answer:
他的回答:
It's important to realise that this ENOTCONN does not necessarily mean that anything has gone wrong. Closed TCP connections are expected in all versions of HTTP. So, unless there's some other symptom associated with this error, my recommendation is that you ignore it.
重要的是要意识到这个 ENOTCONN 并不一定意味着出现任何问题。所有版本的 HTTP 都需要关闭的 TCP 连接。因此,除非存在与此错误相关的其他症状,否则我的建议是您忽略它。
source: https://forums.developer.apple.com/message/272678#272678
来源:https: //forums.developer.apple.com/message/272678#272678
SOLUTION: Just wait for newer versions/updates of Xcode 9.
解决方案:等待 Xcode 9 的更新版本/更新。
回答by 0rt
Here is how TIC Read Status [11:0x0]: 1:57
breaks down:
以下是TIC Read Status [11:0x0]: 1:57
分解的方式:
TIC
expands to “TCP I/O connection”, which is a subsystem within CFNetwork that runs a TCP connection
TIC
扩展为“TCP I/O 连接”,它是 CFNetwork 中运行 TCP 连接的子系统
11
is a connection ID number within TIC
11
是 TIC 中的连接 ID 号
0x0
is a pointer to the TIC object itself
0x0
是指向 TIC 对象本身的指针
1
and 57
are the CFStreamError domain and code, respectively; a domain of 1 is kCFStreamErrorDomainPOSIX and, within that domain, 57 is ENOTCONN
1
和57
分别是 CFStreamError 域和代码;1 的域是 kCFStreamErrorDomainPOSIX,在该域中,57 是 ENOTCONN
回答by lal
Note: Like what @David mentioned in the comment, it's a way to hide the warnings, so use this launch argument to avoid getting many repetitive messages and have a clean console. Once done debugging, keep it disabled as console doesn't provide useful information when it's enabled. For example libc++abi.dylib: terminating with uncaught exception of type NSException
.
注意:就像@David 在评论中提到的那样,这是一种隐藏警告的方法,因此使用此启动参数可以避免收到许多重复消息并拥有干净的控制台。完成调试后,请将其禁用,因为控制台在启用时不会提供有用的信息。例如libc++abi.dylib: terminating with uncaught exception of type NSException
。
For people who are wondering how to silence the warning and until a better fix is available you may keep following variable handy and toggle as needed.
对于想知道如何消除警告并直到有更好的修复可用的人,您可以随时关注变量并根据需要进行切换。
Use OS_ACTIVITY_MODE = disable
environment variable under Arguments in the product schemes to avoid console getting flooded with such warnings.
OS_ACTIVITY_MODE = disable
在产品方案中的 Arguments 下使用环境变量,以避免控制台被此类警告淹没。
Note B: Enable it to see the effect.
注B:开启即可看到效果。
Source: https://medium.com/@adinugroho/disable-os-logging-in-xcode-8-ec6d38502532
来源:https: //medium.com/@adinugroho/disable-os-logging-in-xcode-8-ec6d38502532
回答by Moose
The best way I found, concerning this log message and some others ( like NSURLSession errors that are not necessarily errors ) is to have my own log functions.
我发现,关于此日志消息和其他一些(如 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")
}
}
Then I simply type [MyProject]in the console pane bottom-right filter, and that's it.
然后我只需在控制台窗格右下角的过滤器中输入[MyProject],就可以了。
Note that by calling print on the main queue, it allows your logger to be used from threads without mixing up your console.
请注意,通过在主队列上调用 print,它允许从线程使用您的记录器而不会混淆您的控制台。
Ready to be improved and tweaked for your needs :)
准备好根据您的需要进行改进和调整:)
回答by Anuj Nigam
I was having this same issue where I was getting '}' in response to a REST(GET) service.
我遇到了同样的问题,我收到 '}' 以响应 REST(GET) 服务。
Using:
使用:
URLCache.shared.removeCachedResponse(for: request as URLRequest)
after making my URL request, and resetting my URLSession object after getting the response as:
发出我的 URL 请求后,并在获得响应后重置我的 URLSession 对象:
session.reset(completionHandler: {
// print(\(data))
})
Solved my problem.
解决了我的问题。
回答by Starkode
We manage to solved this logging problem by disabling HTTP/2 on the web server, in our case we have migrated from classic ELB to application ELB that added support to HTTP/2 on AWS and we started getting "TIC Read Status [11:0x0]: 1:57" on XCode 10.1 / iOS 12 console. This looks like a temporary solution until Apple fix the problem with HTTP/2 if any. This solution may not work for everybody, specially if you are using third party APIs, but it gives you some insights on the problem.
我们设法通过在 Web 服务器上禁用 HTTP/2 来解决此日志记录问题,在我们的案例中,我们已从经典 ELB 迁移到在 AWS 上增加了对 HTTP/2 支持的应用程序 ELB,并且我们开始获得“TIC 读取状态 [11:0x0 ]:1:57" 在 XCode 10.1 / iOS 12 控制台上。这看起来像是一个临时解决方案,直到 Apple 解决了 HTTP/2 的问题(如果有的话)。此解决方案可能不适用于所有人,尤其是在您使用第三方 API 时,但它可以让您对问题有一些了解。