Что такое статус чтения TIC 1:57 в iOS11 / Xcode 9?


158

После обновления до 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
...

Что это такое и как мне это исправить? Помощь очень ценится.

PS: я предпочитаю не просто "замолчать" это с помощью Environment Variableсхемы сборки.


1
Возможный дубликат stackoverflow.com/questions/40226104/…
Тимгкарлсон

5
хорошо. я также нашел эту тему. но это osx, старый и не очень ответил ...
Дэвид Seek

ты уже нашел решение?
Khodour.F

2
раздражает не то, что это входит в консоль, но также кажется, что он зависает в главном потоке
Hogdotmac

1
Да, это так. но только в режиме отладки, насколько я заметил.
Дэвид Сик

Ответы:


182

Сотрудники Apple дали следующий ответ:

TIC расширяется до «TCP I / O connection», которая является подсистемой в CFNetwork, которая запускает TCP-соединение

1и 57являются доменом и кодом CFStreamError соответственно; домен 1 равен kCFStreamErrorDomainPOSIX и в этом домене 57ENOTCONN

Короче говоря, чтение TCP не удалось с ENOTCONN.

Поскольку подсистема соединений TCP I / O не имеет общедоступного API, вы должны обязательно использовать его через какую-то высокоуровневую оболочку (например, NSURLSession).

источник: https://forums.developer.apple.com/thread/66058

EDIT / UPDATE:

Поскольку у всех нас по-прежнему есть эти надоедливые журналы, я попросил того же специалиста Apple по приведенной выше ссылке рассказать о нашей ситуации , которая теперь специфична для 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 не обязательно означает, что что-то пошло не так. Закрытые соединения TCP ожидаются во всех версиях HTTP. Поэтому, если с этой ошибкой не связаны другие симптомы, я рекомендую вам ее игнорировать.

источник: https://forums.developer.apple.com/message/272678#272678

РЕШЕНИЕ: просто дождитесь новых версий / обновлений Xcode 9.


30
Это не относится к Swift. Я получаю это и с Objectiv-C.
Виктор Энгель

8
Вы действительно сделали все возможное, чтобы получить этот ответ
Г. ЛК

7
Ваше решение, похоже, не сработало, поскольку оно все еще есть в XCode10.
Геннадий Цыпенко

2
мы должны найти способ избавиться от этого, потому что печать журналов влияет на производительность приложения во время выполнения, а сейчас мы можем надеяться, что для сборок, отличных от #DEBUG, это не будет напечатано
Stoyan

6
было бы неплохо иметь некоторые настройки, чтобы мы могли на самом деле «игнорировать это»,
Запорожченко Александр

40

Вот как TIC Read Status [11:0x0]: 1:57ломается:

TIC расширяется до «TCP I / O connection», которая является подсистемой в CFNetwork, которая запускает TCP-соединение

11 это идентификационный номер соединения в TIC

0x0 указатель на сам объект TIC

1и 57являются доменом и кодом CFStreamError соответственно; домен 1 равен kCFStreamErrorDomainPOSIX, а в этом домене 57 равен ENOTCONN

Источник: https://forums.developer.apple.com/thread/66058


Ладно. Все идет нормально. это что-то плохое или просто информация? мне нужно что-нибудь исправить?
Дэвид

Я считаю, что это как-то связано с iOS11.0 и может быть исправлено в будущих версиях
0

8
Но почему это на самом деле происходит? И с чего это вдруг началось с iOS 11?
Лейн Реттиг

Я тоже получаю их тональные сигналы в своем журнале, но все мои сетевые вызовы работают нормально: L

Та же проблема, что я должен сделать с этим?
Женевиос

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

введите описание изображения здесь


13
Также я буквально сказал, что я не хочу его вариант ^^ Просто заставить его замолчать, это не избавит от проблемы.
Дэвид

23
Люди должны перестать предлагать отключить все записи журнала. Подобные ответы должны быть удалены.
Клаус Йоргенсен

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". Именно так Apple рекомендует использовать для расширенной регистрации
user1105951

0

У меня возникла та же проблема, когда я получал '}' в ответ на сервис REST (GET).

С помощью:

URLCache.shared.removeCachedResponse(for: request as URLRequest)

после выполнения моего запроса URL-адреса и сброса объекта URLSession после получения ответа в виде:

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

Решил мою проблему.


1
Не решит мою проблему, так как это даже происходит, если все, что делает мое приложение, это звонки в Firebase. И я не могу манипулировать рамками. Но я передам это команде разработчиков Firebase. Может быть, они могут что-то сделать с этим.
Дэвид Сик

0

Нам удалось решить эту проблему журналирования, отключив HTTP / 2 на веб-сервере, в нашем случае мы перешли с классического ELB на приложение ELB, которое добавило поддержку HTTP / 2 на AWS, и мы начали получать «TIC Read Status [11: 0x0» ]: 1:57 "на консоли XCode 10.1 / iOS 12. Это выглядит как временное решение, пока Apple не решит проблему с HTTP / 2, если таковая имеется. Это решение может не работать для всех, особенно если вы используете сторонние API, но оно дает вам некоторое представление о проблеме.


4
Прошло 1,5 года с тех пор, как Apple представила эту ... давайте назовем это ... функцию ... Я не вижу, чтобы это было "исправлено" в ближайшее время.
Дэвид

0

Это запись, указывающая, что соединение TCP потеряно / закрыто / not_valid или что-то еще. Это может произойти, если ваше приложение имеет работающее tcp-соединение и приложение какое-то время находится в фоновом режиме, или вы выключили экран своего телефона. ОС решает остановить как можно больше ресурсов, чтобы уменьшить разрядку аккумулятора. Если вы выведете приложение на передний план, то tcp-соединения, которые у вас были раньше, больше не будут работать. Вам необходимо воссоздать новое tcp-соединение.

Если вас это не беспокоит, просто игнорируйте это.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.