Console w Xcode: kluczowe pojęcia, wypisywanie danych i debugowanie

Czym jest Console w Xcode

Console — część Debug Area w Xcode, znajdująca się w dolnym panelu edytora (View → Debug Area → Activate Console, skrót Cmd + Shift + Y). Console pokazuje cały tekstowy output uruchomionej aplikacji: komunikaty z NSLog, os_log, print, błędy kompilacji na bieżąco (runtime warnings) oraz automatyczne zrzuty wyjątków przy awarii aplikacji.

Console działa zarówna na symulatorze, jak i na fizycznym urządzeniu. Na symulatorze komunikaty przychodzą natychmiast przez lokalny pipe, na urządzeniu — przez połączenie USB z opóźnieniem 1–3 klatek. Dla aplikacji produkcyjnych Console na urządzeniu jest niedostępna — programista polega na Crashlytics lub Unified Logging ze zdalnym zbieraniem przez log collect.

W przeciwieństwie do systemowej aplikacji Console.app na Mac, okno Console w Xcode pokazuje tylko logi aktualnie uruchomionej aplikacji (z możliwością filtrowania). Console.app zbiera logi wszystkich procesów na Mac, w tym symulatorów iOS. Jednak do debugowania aplikacji iOS programiści używają wbudowanej Console Xcode ze względu na integrację z debuggerem LLDB.

API logowania: NSLog, os_log i print

Trzy główne API są dostępne dla programisty iOS do wypisywania w Console: NSLog (przestarzałe), os_log (zalecane) i print (tylko Swift). Każde ma swoje właściwości dotyczące wydajności, formatowania i zgodności z Unified Logging System.

NSLog — klasyczne logowanie

NSLog — funkcja z Foundation, dostępna w Objective-C i Swift. NSLog wypisuje komunikat z znacznikiem czasu, nazwą procesu i PID. Wady: NSLog zapisuje do bufora systemowego synchronicznie, blokując bieżący wątek na czas zapisu. Przy częstych wywołaniach (np. w pętli) NSLog tworzy zauważalne opóźnienie. Apple nie zaleca NSLog dla nowych projektów, ale pozostaje on zgodny ze starym kodem i bibliotekami firm trzecich.

os_log — nowoczesny standard

os_log — API z os.framework, wprowadzone w iOS 10. os_log jest asynchroniczne: komunikat jest umieszczany w kolejce i zapisywany w buforze bez blokowania wywołującego wątku. Według WWDC 2016, os_log jest 50 razy szybsze niż NSLog w scenariuszach o wysokim obciążeniu. os_log obsługuje również dynamiczne zarządzanie: komunikaty poziomu DEBUG są zbierane tylko w kompilacji Debug, w Release są ignorowane bez narzutu wydajnościowego.

print() — wypisywanie tylko w Swift

print() — najprostszy sposób wypisywania w Swift. print zapisuje do stdout (standardowe wyjście), które Xcode przekierowuje do Console. print nie dodaje metadanych (czas, poziom), ale obsługuje buforowanie stdout. Do szybkiego debugowania print jest wygodnym narzędziem, ale do stałego logowania ustępuje os_log pod względem funkcjonalności i kontroli.

import os.log

// NSLog — przestarzałe, blokujące
NSLog("Application started")

// os_log — zalecane, asynchroniczne
let log = OSLog(
    subsystem: "com.myapp",
    category: "lifecycle"
)
os_log("Application started", log: log)

// print — szybkie wypisywanie w Swift
print("Application started")

Unified Logging: kategorie, poziomy i podsystemy

Unified Logging System (ULS) — kompleksowa infrastruktura logowania Apple, wprowadzona w iOS 10 i macOS Sierra. ULS zbiera komunikaty ze wszystkich procesów systemu w jednym magazynie z możliwością zdalnego dostępu przez narzędzie log wiersza poleceń na Mac. Programista używa os_log do zapisu w ULS, a Console do odczytu.

Podsystemy i kategorie

Każdy OSLog jest identyfikowany przez parę subsystem (np. com.myapp.network) i category (np. http, websocket). Podsystem to domena aplikacji (jedna aplikacja może mieć wiele podsystemów dla różnych modułów). Kategoria to komponent wewnątrz podsystemu. Kombinacja subsystem + category pozwala elastycznie filtrować logi w Console i log collect.

Poziomy logowania OSLog

log collect — zdalne zbieranie logów

Polecenie log collect na Mac zbiera zarchiwizowane logi z podłączonego urządzenia iOS do pliku .logarchive. Ten plik można otworzyć w Console.app na Mac do szczegółowej analizy, w tym komunikatów os_log, logów awarii i diagnostyk systemowych. Aby włączyć zbieranie na urządzeniu, należy włączyć tryb dewelopera i podłączyć urządzenie przez USB.

Praca z Console: debugowanie krok po kroku i analiza logów awarii

Praktyczna praca z Console obejmuje trzy główne scenariusze: aktywne logowanie podczas programowania, analiza logów awarii po awarii i zdalna diagnostyka przez .logarchive. Dla każdego scenariusza istnieje optymalny zestaw narzędzi i ustawień.

Konfiguracja Console do programowania

Zaleca się utworzenie osobnego OSLog dla każdego modułu aplikacji z poziomami: debug (szczegółowe debugowanie), info (kluczowe przejścia stanów), error (wyjątki i błędy). W Console Xcode włącz filtr według podsystemu swojej aplikacji, aby wykluczyć komunikaty systemowe, które powodują szum i odwracają uwagę od logiki aplikacji.

Analiza logu awarii

Przy awarii aplikacji Xcode automatycznie zatrzymuje wykonanie i pokazuje wątek, na którym nastąpiła awaria, z pełnym stack trace w Console. Pierwszy wiersz logu awarii zawiera typ wyjątku (NSException, EXC_BAD_ACCESS) i przyczynę (reason). Przeanalizuj stack trace od dołu do góry: ostatnia wywołana metoda to miejsce awarii. Dla zaszyfrowanych adresów (w Release) wymagana jest symbolikacja przez dSYM.

// Przykład modułowej konfiguracji OSLog
extension OSLog {
    static let uiLifecycle = OSLog(
        subsystem: "com.myapp.ui",
        category: "lifecycle"
    )
    static let network = OSLog(
        subsystem: "com.myapp.network",
        category: "http"
    )
    static let database = OSLog(
        subsystem: "com.myapp.data",
        category: "core-data"
    )
}

// Użycie z poziomami
os_log("View did load", log: .uiLifecycle, type: .debug)
os_log("HTTP 200 received", log: .network, type: .info)
os_log("Failed to save: \(error.localizedDescription)",
    log: .database, type: .error)

Zaawansowane możliwości: breakpoint-logs i niestandardowe formaty

Xcode Console obsługuje kilka zaawansowanych funkcji, które wykraczają poza zwykłe logowanie. Breakpoint-logs pozwalają wypisywać komunikaty w Console bez zatrzymywania wykonania, a polecenia LLDB w Debugger Command dają pełną kontrolę nad formatowaniem outputu.

Breakpoint-logs bez zatrzymywania

Możesz skonfigurować breakpoint tak, aby wypisywał komunikat w Console i automatycznie kontynuował wykonanie. Ustaw breakpoint na odpowiedniej linii, kliknij prawym przyciskiem → Edit Breakpoint → dodaj Debugger Command: «po self» lub «expr @import UIKit» + Debugger Command: «po self.view». Zaznacz Automatically continue after evaluating. Po uruchomieniu breakpoint będzie wypisywał wynik polecenia w Console przy każdym osiągnięciu linii, nie przerywając wątku.

Polecenia LLDB w Console

Console Xcode obsługuje wykonywanie dowolnych poleceń LLDB podczas zatrzymania na breakpoint. po (print object) wypisuje opis obiektu, p (print) — wartości prymitywne, a expr — wykonuje wyrażenia Swift/ObjC. Do sformatowanego outputu użyj p/CGRectGetWidth. Output LLDB jest wyświetlany w Console natychmiast po osiągnięciu breakpoint.

func processUserData(user: User) {
    // Breakpoint tutaj z Debugger Command:
    // po "User name: \(user.name)"
    // expr user.age = 30
    print("Processing user: \(user.name)")
}

// Przykład niestandardowego logowania z sekwencją
func trackMethodCall(
    file: String = #file,
    function: String = #function
) {
    os_log("[\(function)] called",
        log: .uiLifecycle, type: .debug)
}

Integracja z Instruments

Console Xcode jest ściśle zintegrowana z Instruments — narzędziem profilowania Xcode. Przy uruchomieniu aplikacji przez Product → Profile z szablonem Logging, wszystkie komunikaty os_log są zapisywane w śladzie Instruments z znacznikami czasu. Pozwala to jednocześnie widzieć logi, wydajność i zdarzenia systemowe na jednej osi czasu, co jest kluczowe do diagnozowania race condition i regresji wydajności.