Qu'est-ce que le statut de lecture TIC 1:57 dans iOS11 / Xcode 9?

Après la mise à jour vers Xcode 9, en utilisant Swift 3 et le simulateur iPhone X, ma console est pleine de:

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

Qu'est-ce que c'est et comment y remédier? L'aide est très appréciée.

PS: Je préfère ne pas simplement le "faire taire" avec un Environment Variabledans le schéma de construction.

Le personnel d'Apple a donné la réponse suivante:

TIC se développe en «connexion TCP I / O», qui est un sous-système de CFNetwork qui exécute une connexion TCP

1et 57sont le domaine et le code CFStreamError, respectivement; un domaine de 1 est kCFStreamErrorDomainPOSIX et, dans ce domaine, 57est ENOTCONN

En bref, une lecture TCP a échoué avec ENOTCONN.

Comme le sous-système de connexion d'E / S TCP n'a pas d'API publique, vous devez nécessairement l'utiliser via un wrapper de haut niveau (comme NSURLSession).

source: https://forums.developer.apple.com/thread/66058

MODIFIER / METTRE À JOUR:

Comme nous avons tous encore ces journaux ennuyeux, j'ai demandé au même spécialiste Apple à partir du lien ci-dessus à propos de notre situation , qui est maintenant spécifique pour Xcode 9 et Swift 4. La voici:

Beaucoup de gens se plaignent de ces journaux, que j'ai également dans toutes mes applications depuis la mise à niveau vers 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

Sa réponse:

Il est important de réaliser que cet ENOTCONN ne signifie pas nécessairement que quelque chose a mal tourné. Des connexions TCP fermées sont attendues dans toutes les versions de HTTP. Donc, à moins qu'il y ait un autre symptôme associé à cette erreur, ma recommandation est que vous l'ignoriez.

source: https://forums.developer.apple.com/message/272678#272678

SOLUTION: attendez simplement les nouvelles versions / mises à jour de Xcode 9.

Voici comment TIC Read Status [11:0x0]: 1:57se décompose:

TIC se développe en «connexion TCP I / O», qui est un sous-système de CFNetwork qui exécute une connexion TCP

11 est un numéro d'identification de connexion dans TIC

0x0 est un pointeur vers l'objet TIC lui-même

1et 57sont le domaine et le code CFStreamError, respectivement; un domaine de 1 est kCFStreamErrorDomainPOSIX et, dans ce domaine, 57 est ENOTCONN

Source: https://forums.developer.apple.com/thread/66058

Remarque: comme ce que @David a mentionné dans le commentaire, c'est un moyen de masquer les avertissements, utilisez donc cet argument de lancement pour éviter de recevoir de nombreux messages répétitifs et avoir une console propre. Une fois le débogage terminé, gardez-le désactivé car la console ne fournit pas d'informations utiles lorsqu'elle est activée. Par exemple libc++abi.dylib: terminating with uncaught exception of type NSException.

Pour les personnes qui se demandent comment faire taire l'avertissement et jusqu'à ce qu'un meilleur correctif soit disponible, vous pouvez continuer à suivre la variable à portée de main et basculer si nécessaire.

Utilisez OS_ACTIVITY_MODE = disablela variable d'environnement sous Arguments dans les schémas de produit pour éviter que la console ne soit inondée de tels avertissements.

Remarque B: activez-le pour voir l'effet.

Source: https://medium.com/@adinugroho/disable-os-logging-in-xcode-8-ec6d38502532

Le meilleur moyen que j'ai trouvé, concernant ce message de journal et quelques autres (comme les erreurs NSURLSession qui ne sont pas nécessairement des erreurs) est d'avoir mes propres fonctions de journal.

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

Ensuite, je tape simplement [MyProject] dans le filtre en bas à droite du panneau de la console, et c'est tout.

Notez qu'en appelant print sur la file d'attente principale, cela permet à votre enregistreur d'être utilisé à partir de threads sans mélanger votre console.

Prêt à être amélioré et peaufiné pour vos besoins :)

J'avais ce même problème où j'obtenais «}» en réponse à un service REST (GET).

En utilisant:

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

après avoir fait ma demande d'URL, et réinitialisé mon objet URLSession après avoir obtenu la réponse comme:

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

J'ai résolu mon problème.

Nous parvenons à résoudre ce problème de journalisation en désactivant HTTP / 2 sur le serveur Web, dans notre cas, nous avons migré de l'ELB classique vers l'application ELB qui a ajouté la prise en charge de HTTP / 2 sur AWS et nous avons commencé à obtenir "TIC Read Status [11: 0x0 ]: 1:57 "sur la console XCode 10.1 / iOS 12. Cela ressemble à une solution temporaire jusqu'à ce qu'Apple corrige le problème avec HTTP / 2, le cas échéant. Cette solution peut ne pas fonctionner pour tout le monde, en particulier si vous utilisez des API tierces, mais elle vous donne des informations sur le problème.

C'est une journalisation indiquant qu'une connexion TCP est perdue / fermée / non valide ou autre. Cela peut se produire si votre application a une connexion TCP en cours d'exécution et que l'application est mise en arrière-plan pendant un certain temps, ou si vous avez éteint l'écran de votre téléphone. Le système d'exploitation décide d'arrêter autant de ressources que possible pour réduire l'épuisement de la batterie. Si vous mettez l'application au premier plan, les connexions TCP que vous aviez auparavant ne fonctionneront plus. Vous devez recréer une nouvelle connexion TCP.

Si cela ne vous dérange pas, ignorez-le.