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

Після оновлення до 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в схемі збірки.

Співробітники Apple дали наступну відповідь:

TIC розширюється до "TCP з'єднання вводу / виводу", що є підсистемою в CFNetwork, яка працює за допомогою TCP-з'єднання

1і 57- домен та код CFStreamError відповідно; домен 1 - kCFStreamErrorDomainPOSIX, а в межах цього домену 57- ENOTCONN

Коротше кажучи, зчитування TCP не вдалося здійснити за допомогою ENOTCONN.

Оскільки підсистема підключення вводу-виводу TCP не має загальнодоступного API, ви обов'язково повинні використовувати її через оберток високого рівня (наприклад, NSURLSession).

джерело: https://forums.developer.apple.com/thread/66058

РЕДАКТУВАННЯ / ОНОВЛЕННЯ:

Оскільки у нас все ще є такі докучливі журнали, я попросив того самого спеціаліста 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.

Ось як TIC Read Status [11:0x0]: 1:57розбивається:

TIC розширюється до "TCP з'єднання вводу / виводу", що є підсистемою в CFNetwork, яка працює за допомогою TCP-з'єднання

11 номер ідентифікатора з'єднання в TIC

0x0 є вказівником на сам об’єкт TIC

1і 57- домен та код CFStreamError відповідно; домен 1 - kCFStreamErrorDomainPOSIX, а в межах цього домену 57 - ENOTCONN

Джерело: https://forums.developer.apple.com/thread/66058

Примітка. Як і те, що @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

Найкращий спосіб, який я знайшов, стосовно цього повідомлення журналу та деяких інших (наприклад, помилок 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] в консолі панелі внизу праворуч, і все.

Зауважте, що, викликаючи друк на головній черзі, він дозволяє використовувати ваш реєстратор з потоків, не змішуючи консоль.

Готові до вдосконалення та налаштування для ваших потреб :)

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

Використання:

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

після подання мого запиту URL-адреси та скидання об'єкта URLSession після отримання відповіді як:

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

Вирішив мою проблему.

Цю проблему ведення журналу нам вдалося вирішити, відключивши HTTP / 2 на веб-сервері; в нашому випадку ми перейшли з класичного ELB до додатка ELB, який додав підтримку HTTP / 2 на AWS, і ми почали отримувати "TIC Read Status [11: 0x0 ]: 1:57 "на консолі XCode 10.1 / iOS 12. Це виглядає як тимчасове рішення, поки Apple не виправить проблему з HTTP / 2, якщо така є. Це рішення може працювати не для всіх, особливо якщо ви використовуєте сторонні інтерфейси API, але воно дає деяку інформацію про проблему.

Це журнал, який вказує на те, що TCP-з'єднання втрачене / закрите / не_дійсне чи інше. Це може статися, якщо у вашому додатку працює підключення tcp і додаток на деякий час перебуває у фоновому режимі або ви вимкнули екран свого телефону. ОС вирішує зупинити якомога більше ресурсів, щоб зменшити витрату акумуляторів. Якщо ви виведете додаток на перший план, tcp-з'єднання, які ви мали раніше, більше не працюватимуть. Вам потрібно відтворити нове tcp-з'єднання.

Якщо це вас не турбує, просто проігноруйте це.