Trạng thái TIC đã đọc 1:57 trong iOS11 / Xcode 9 là gì?

Sau khi cập nhật lên Xcode 9, sử dụng Swift 3 và trình giả lập iPhone X, bảng điều khiển của tôi có đầy đủ:

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

Đó là gì và làm thế nào để tôi sửa nó? Giúp đỡ là rất đánh giá cao.

PS: Tôi không chỉ muốn "im lặng" với một Environment Variablekế hoạch xây dựng.

Nhân viên Apple đã đưa ra câu trả lời sau:

TIC mở rộng lên kết nối I / O của TCP TCP, là một hệ thống con trong CFNetwork chạy kết nối TCP

1và 57là tên miền và mã CFStreamError, tương ứng; tên miền của 1 là kCFStreamErrorDomainPOSIX và, trong miền đó, 57là ENOTCONN

Nói tóm lại, một lần đọc TCP đã thất bại với ENOTCONN.

Vì hệ thống con kết nối TCP I / O không có API công khai, bạn nhất thiết phải sử dụng nó thông qua một số trình bao bọc cấp cao (như NSURLSession).

nguồn: https://forums.developer.apple.com/thread/66058

CHỈNH SỬA / CẬP NHẬT:

Vì tất cả chúng ta vẫn đang có những nhật ký gây phiền nhiễu này, tôi đã hỏi một chuyên gia của Apple từ liên kết trên về tình huống của chúng tôi , hiện cụ thể cho Xcode 9 và Swift 4. Đây là:

Rất nhiều người phàn nàn về các nhật ký này, điều mà tôi đang có trong tất cả các ứng dụng của mình kể từ khi tôi nâng cấp lên 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

Câu trả lời của anh ấy:

Điều quan trọng là phải nhận ra rằng ENOTCONN này không nhất thiết có nghĩa là bất cứ điều gì đã sai. Các kết nối TCP kín được mong đợi trong tất cả các phiên bản HTTP. Vì vậy, trừ khi có một số triệu chứng khác liên quan đến lỗi này, khuyến nghị của tôi là bạn bỏ qua nó.

nguồn: https://forums.developer.apple.com/message/272678#272678

GIẢI PHÁP: Chỉ cần chờ phiên bản / cập nhật mới hơn của Xcode 9.

Đây là cách TIC Read Status [11:0x0]: 1:57phá vỡ:

TIC mở rộng lên kết nối I / O của TCP TCP, là một hệ thống con trong CFNetwork chạy kết nối TCP

11 là số ID kết nối trong TIC

0x0 là một con trỏ tới chính đối tượng TIC

1và 57là tên miền và mã CFStreamError, tương ứng; tên miền của 1 là kCFStreamErrorDomainPOSIX và, trong miền đó, 57 là ENOTCONN

Nguồn: https://forums.developer.apple.com/thread/66058

Lưu ý: Giống như những gì @David đã đề cập trong bình luận, đó là một cách để ẩn các cảnh báo, vì vậy hãy sử dụng đối số khởi chạy này để tránh nhận được nhiều tin nhắn lặp đi lặp lại và có bảng điều khiển sạch. Sau khi gỡ lỗi xong, hãy tắt nó vì bảng điều khiển không cung cấp thông tin hữu ích khi được bật. Ví dụ libc++abi.dylib: terminating with uncaught exception of type NSException.

Đối với những người đang tự hỏi làm thế nào để tắt tiếng cảnh báo và cho đến khi có cách khắc phục tốt hơn, bạn có thể tiếp tục theo dõi biến và tiện dụng khi cần.

Sử dụng OS_ACTIVITY_MODE = disablebiến môi trường trong phần Đối số trong sơ đồ sản phẩm để tránh giao diện điều khiển bị ngập trong các cảnh báo như vậy.

Lưu ý B: Kích hoạt nó để xem hiệu ứng.

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

Cách tốt nhất tôi tìm thấy, liên quan đến thông điệp tường trình này và một số thông tin khác (như lỗi NSURLSession không nhất thiết là lỗi) là có các chức năng nhật ký của riêng tôi.

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

Sau đó, tôi chỉ cần gõ [MyProject] trong bộ lọc phía dưới bên phải của giao diện điều khiển và đó là nó.

Lưu ý rằng bằng cách gọi in trên hàng đợi chính, nó cho phép logger của bạn được sử dụng từ các luồng mà không trộn lẫn bàn điều khiển của bạn.

Sẵn sàng để được cải thiện và điều chỉnh cho nhu cầu của bạn :)

Tôi đã gặp vấn đề tương tự khi tôi nhận được '}' để đáp ứng với dịch vụ REST (GET).

Sử dụng:

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

sau khi thực hiện yêu cầu URL của tôi và đặt lại đối tượng URLSession của tôi sau khi nhận được phản hồi là:

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

Giải quyết vấn đề của tôi.

Chúng tôi quản lý để giải quyết vấn đề ghi nhật ký này bằng cách vô hiệu hóa HTTP / 2 trên máy chủ web, trong trường hợp của chúng tôi, chúng tôi đã chuyển từ ELB cổ điển sang ELB ứng dụng có thêm hỗ trợ cho HTTP / 2 trên AWS và chúng tôi bắt đầu nhận được "Trạng thái đọc TIC [11: 0x0 ]: 1:57 "trên bảng điều khiển XCode 10.1 / iOS 12. Đây có vẻ là một giải pháp tạm thời cho đến khi Apple khắc phục sự cố với HTTP / 2 nếu có. Giải pháp này có thể không hiệu quả với tất cả mọi người, đặc biệt nếu bạn đang sử dụng API của bên thứ ba, nhưng nó cung cấp cho bạn một số hiểu biết về vấn đề này.

Đó là ghi nhật ký cho biết kết nối TCP bị mất / đóng / not_valid hoặc bất cứ điều gì. Điều này có thể xảy ra nếu ứng dụng của bạn có kết nối tcp đang chạy và ứng dụng được đặt trong nền trong một thời gian hoặc bạn tắt màn hình điện thoại. HĐH quyết định dừng càng nhiều tài nguyên càng tốt để giảm tiêu hao pin. Nếu bạn đưa ứng dụng lên nền trước, các kết nối tcp bạn có trước đây, sẽ không hoạt động nữa. Bạn cần tạo lại một kết nối tcp mới.

Nếu nó không làm phiền bạn, hãy bỏ qua nó.