Console in Xcode: kernbegrippen, gegevensuitvoer en debuggen

Wat is Console in Xcode

Console — onderdeel van Debug Area in Xcode, gelegen in het onderste paneel van de editor (View → Debug Area → Activate Console, toetscombinatie Cmd + Shift + Y). Console toont alle tekstuitvoer van de actieve app: berichten van NSLog, os_log, print, runtime-waarschuwingen (runtime warnings) en automatische uitzonderingsdumps bij een crash van de app.

Console werkt zowel op de simulator als op een fysiek apparaat. Op de simulator komen berichten onmiddellijk via een lokale pipe, op het apparaat — via USB-verbinding met een vertraging van 1–3 frames. Voor productie-apps is Console op het apparaat niet beschikbaar — de ontwikkelaar vertrouwt op Crashlytics of Unified Logging met externe verzameling via log collect.

In tegenstelling tot de systeemapp Console.app op Mac toont het Console-venster in Xcode alleen de logs van de huidige actieve app (met filtermogelijkheden). Console.app verzamelt logs van alle processen op Mac, inclusief iOS-simulatoren. Voor het debuggen van iOS-apps gebruiken ontwikkelaars echter de ingebouwde Console Xcode vanwege de integratie met de LLDB-debugger.

Log-API's: NSLog, os_log en print

Drie belangrijke API's zijn beschikbaar voor iOS-ontwikkelaars voor uitvoer in Console: NSLog (verouderd), os_log (aanbevolen) en print (alleen Swift). Elk heeft zijn eigen kenmerken op het gebied van prestaties, opmaak en compatibiliteit met Unified Logging System.

NSLog — klassiek loggen

NSLog — functie uit Foundation, beschikbaar in Objective-C en Swift. NSLog geeft een bericht weer met tijdstempel, procesnaam en PID. Nadelen: NSLog schrijft synchroon naar de systeembuffer, waardoor de huidige thread wordt geblokkeerd tijdens het schrijven. Bij frequente aanroepen (bijvoorbeeld in een lus) veroorzaakt NSLog merkbare vertraging. Apple raadt NSLog niet aan voor nieuwe projecten, maar het blijft compatibel met oude code en bibliotheken van derden.

os_log — moderne standaard

os_log — API uit os.framework, geïntroduceerd in iOS 10. os_log is asynchroon: het bericht wordt in een wachtrij geplaatst en in de buffer geschreven zonder de aanroepende thread te blokkeren. Volgens WWDC 2016 is os_log 50 keer sneller dan NSLog in scenario's met hoge belasting. os_log ondersteunt ook dynamisch beheer: DEBUG-niveauberichten worden alleen verzameld in Debug-builds, in Release worden ze genegeerd zonder prestatiekosten.

print() — alleen Swift-uitvoer

print() — de eenvoudigste uitvoermethode in Swift. print schrijft naar stdout (standaarduitvoer), die Xcode naar Console doorstuurt. print voegt geen metadata toe (tijd, niveau), maar ondersteunt stdout-buffering. Voor snel debuggen is print een handig hulpmiddel, maar voor permanent loggen doet het onder voor os_log wat betreft functionaliteit en controle.

import os.log

// NSLog — verouderd, blokkerend
NSLog("Application started")

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

// print — snelle Swift-uitvoer
print("Application started")

Unified Logging: categorieën, niveaus en subsystemen

Unified Logging System (ULS) — de uitgebreide Apple-loginfrastructuur, geïntroduceerd in iOS 10 en macOS Sierra. ULS verzamelt berichten van alle systeemprocessen in één opslagplaats met externe toegang via de log-opdrachtregeltool op Mac. De ontwikkelaar gebruikt os_log om naar ULS te schrijven en Console om te lezen.

Subsystemen en categorieën

Elke OSLog wordt geïdentificeerd door een paar subsystem (bijv. com.myapp.network) en category (bijv. http, websocket). Het subsysteem is het domein van de app (één app kan meerdere subsystemen hebben voor verschillende modules). De categorie is een component binnen het subsysteem. De combinatie subsystem + category zorgt voor flexibele filtering van logs in Console en log collect.

OSLog-logniveaus

log collect — extern log verzamelen

Het commando log collect op Mac verzamelt gearchiveerde logs van een aangesloten iOS-apparaat in een .logarchive-bestand. Dit bestand kan worden geopend in Console.app op Mac voor gedetailleerde analyse, inclusief os_log-berichten, crashlogs en systeemdiagnostiek. Om verzameling op het apparaat in te schakelen, moet u de Developer Mode inschakelen en het apparaat via USB aansluiten.

Werken met Console: stapsgewijs debuggen en analyseren van crashlogs

Praktisch werk met Console omvat drie hoofdscenario's: actief loggen tijdens ontwikkeling, analyse van crashlogs na een crash en externe diagnostiek via .logarchive. Voor elk scenario is er een optimale set tools en instellingen.

Console configureren voor ontwikkeling

Het wordt aanbevolen om een aparte OSLog te maken voor elke module van de app met niveaus: debug (gedetailleerd debuggen), info (belangrijke statusovergangen), error (uitzonderingen en fouten). Schakel in Console Xcode het filter in op het subsysteem van uw app om systeemberichten uit te sluiten die ruis creëren en afleiden van de app-logica.

Crashlog analyseren

Bij een crash van de app stopt Xcode automatisch de uitvoering en toont de thread waar de crash plaatsvond, met volledige stack trace in Console. De eerste regel van het crashlog bevat het uitzonderingstype (NSException, EXC_BAD_ACCESS) en de reden (reason). Bestudeer de stack trace van onder naar boven: de laatst aangeroepen methode is de crashlocatie. Voor versleutelde adressen (in Release) is symbolication via dSYM vereist.

// Voorbeeld van modulaire OSLog-configuratie
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"
    )
}

// Gebruik met niveaus
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)

Geavanceerde functies: breakpoint-logs en aangepaste formaten

Xcode Console ondersteunt verschillende geavanceerde functies die verder gaan dan eenvoudig loggen. Breakpoint-logs maken het mogelijk berichten in Console weer te geven zonder de uitvoering te stoppen, en LLDB-commando's in Debugger Command geven volledige controle over de opmaak van de uitvoer.

Breakpoint-logs zonder stoppen

U kunt een breakpoint zo instellen dat het een bericht in Console weergeeft en automatisch de uitvoering voortzet. Plaats een breakpoint op de gewenste regel, klik met de rechtermuisknop → Edit Breakpoint → voeg Debugger Command toe: “po self” of “expr @import UIKit” + Debugger Command: “po self.view”. Vink Automatically continue after evaluating aan. Na het starten geeft het breakpoint bij elke keer dat de regel wordt bereikt het resultaat van het commando weer in Console zonder de thread te onderbreken.

LLDB-commando's in Console

Console Xcode ondersteunt het uitvoeren van willekeurige LLDB-commando's tijdens het stoppen op een breakpoint. po (print object) geeft de beschrijving van een object, p (print) — primitieve waarden, en expr voert Swift/ObjC-expressies uit. Voor opgemaakte uitvoer gebruikt u p/CGRectGetWidth. LLDB-uitvoer wordt onmiddellijk in Console weergegeven nadat het breakpoint is bereikt.

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

// Voorbeeld van aangepast loggen met volgorde
func trackMethodCall(
    file: String = #file,
    function: String = #function
) {
    os_log("[\(function)] called",
        log: .uiLifecycle, type: .debug)
}

Integratie met Instruments

Console Xcode is nauw geïntegreerd met Instruments — de Xcode-profileringstool. Bij het starten van de app via Product → Profile met de Logging-sjabloon worden alle os_log-berichten met tijdstempels in Instruments-tracks vastgelegd. Hiermee kunt u logs, prestaties en systeemgebeurtenissen tegelijkertijd op één tijdschaal bekijken, wat cruciaal is voor het diagnosticeren van race conditions en prestatieregressie.