Co to jest stan odczytu TIC 1:57 w iOS11 / Xcode 9?

Po aktualizacji do Xcode 9, używając Swift 3 i symulatora iPhone'a X, moja konsola jest pełna:

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

Co to jest i jak to naprawić? Pomoc jest bardzo ceniona.

PS: Wolę nie tylko „wyciszać” go za pomocą Environment Variableschematu kompilacji.

Pracownicy Apple'a udzielili następującej odpowiedzi:

TIC rozwija się do „połączenia TCP I / O”, czyli podsystemu w ramach CFNetwork, który uruchamia połączenie TCP

1i 57są odpowiednio domeną i kodem CFStreamError; domena 1 to kCFStreamErrorDomainPOSIX, aw ramach tej domeny 57to ENOTCONN

Krótko mówiąc, odczyt TCP nie powiódł się z ENOTCONN.

Ponieważ podsystem połączeń TCP I / O nie ma publicznego interfejsu API, koniecznie trzeba go używać za pośrednictwem jakiegoś opakowania wysokiego poziomu (np. NSURLSession).

źródło: https://forums.developer.apple.com/thread/66058

EDYCJA / AKTUALIZACJA:

Ponieważ wszyscy nadal mamy te irytujące dzienniki, zapytałem tego samego specjalistę Apple z powyższego linku o naszą sytuację , która jest teraz specyficzna dla Xcode 9 i Swift 4. Oto ona:

Wiele osób narzeka na te dzienniki, które mam również we wszystkich moich aplikacjach od czasu aktualizacji do 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

Jego odpowiedź:

Ważne jest, aby zdać sobie sprawę, że ten ENOTCONN niekoniecznie oznacza, że ​​coś poszło nie tak. Zamknięte połączenia TCP są oczekiwane we wszystkich wersjach protokołu HTTP. Tak więc, jeśli nie ma innych symptomów związanych z tym błędem, radzę zignorować go.

źródło: https://forums.developer.apple.com/message/272678#272678

ROZWIĄZANIE: Po prostu poczekaj na nowsze wersje / aktualizacje Xcode 9.

Oto, jak się TIC Read Status [11:0x0]: 1:57psuje:

TIC rozwija się do „połączenia TCP I / O”, czyli podsystemu w ramach CFNetwork, który uruchamia połączenie TCP

11 to numer ID połączenia w TIC

0x0 jest wskaźnikiem do samego obiektu TIC

1i 57są odpowiednio domeną i kodem CFStreamError; domena 1 to kCFStreamErrorDomainPOSIX, aw tej domenie 57 to ENOTCONN

Źródło: https://forums.developer.apple.com/thread/66058

Uwaga: Podobnie jak @David wspomniał w komentarzu, jest to sposób na ukrycie ostrzeżeń, więc użyj tego argumentu uruchamiania, aby uniknąć wielu powtarzających się komunikatów i mieć czystą konsolę. Po zakończeniu debugowania wyłącz je, ponieważ konsola nie dostarcza przydatnych informacji, gdy jest włączona. Na przykład libc++abi.dylib: terminating with uncaught exception of type NSException.

Dla osób, które zastanawiają się, jak wyciszyć ostrzeżenie i dopóki nie będzie dostępna lepsza poprawka, możesz podążać za zmienną i przełączać ją w razie potrzeby.

Użyj OS_ACTIVITY_MODE = disablezmiennej środowiskowej w obszarze Argumenty w schematach produktów, aby uniknąć zalewania konsoli takimi ostrzeżeniami.

Uwaga B: Włącz, aby zobaczyć efekt.

Źródło: https://medium.com/@adinugroho/disable-os-logging-in-xcode-8-ec6d38502532

Najlepszym sposobem, jaki znalazłem, w odniesieniu do tego komunikatu dziennika i kilku innych (takich jak błędy NSURLSession, które niekoniecznie są błędami), jest posiadanie własnych funkcji dziennika.

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")
    }
}

Następnie po prostu wpisuję [MyProject] w prawym dolnym filtrze panelu konsoli i to wszystko.

Zauważ, że wywołując print w głównej kolejce, pozwala to na użycie twojego loggera z wątków bez mieszania konsoli.

Gotowy do ulepszenia i dostosowania do Twoich potrzeb :)

Miałem ten sam problem, w którym otrzymywałem znak „}” w odpowiedzi na usługę REST (GET).

Za pomocą:

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

po wysłaniu żądania adresu URL i zresetowaniu obiektu URLSession po otrzymaniu odpowiedzi jako:

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

Rozwiązał mój problem.

Udało nam się rozwiązać ten problem z logowaniem wyłączając HTTP / 2 na serwerze WWW, w naszym przypadku dokonaliśmy migracji z klasycznego ELB do aplikacji ELB, która dodała obsługę HTTP / 2 na AWS i zaczęliśmy otrzymywać "TIC Read Status [11: 0x0 ]: 1:57 "na konsoli XCode 10.1 / iOS 12. Wygląda to na tymczasowe rozwiązanie, dopóki Apple nie naprawi problemu z HTTP / 2, jeśli taki istnieje. To rozwiązanie może nie działać dla wszystkich, szczególnie jeśli korzystasz z interfejsów API innych firm, ale zapewnia wgląd w problem.

Jest to rejestracja wskazująca, że ​​połączenie TCP zostało utracone / zamknięte / nieprawidłowe lub cokolwiek innego. Może się tak zdarzyć, jeśli Twoja aplikacja ma działające połączenie TCP i aplikacja jest na jakiś czas w tle lub gdy wyłączyłeś ekran telefonu. System operacyjny decyduje się zatrzymać jak najwięcej zasobów, aby zmniejszyć zużycie baterii. Jeśli przeniesiesz aplikację na pierwszy plan, połączenia TCP, które miałeś wcześniej, nie będą już działać. Musisz ponownie utworzyć nowe połączenie TCP.

Jeśli ci to nie przeszkadza, po prostu to zignoruj.