Console i Xcode: nyckelbegrepp, datautmatning och felsökning

Vad är Console i Xcode

Console — en del av Debug Area i Xcode, placerad i redigerarens nedre panel (View → Debug Area → Activate Console, kortkommando Cmd + Shift + Y). Console visar all textutdata från den aktiva appen: meddelanden från NSLog, os_log, print, körningsvarningar (runtime warnings) och automatiska undantagsdumpar vid appkrasch.

Console fungerar både på simulatorn och på en fysisk enhet. På simulatorn kommer meddelanden omedelbart via en lokal pipe, på enheten — via USB-anslutning med en fördröjning på 1–3 bildrutor. För produktionsappar är Console inte tillgänglig på enheten — utvecklaren förlitar sig på Crashlytics eller Unified Logging med fjärrinsamling via log collect.

Till skillnad från systemappen Console.app på Mac visar Console-fönstret i Xcode endast loggar för den aktuella aktiva appen (med filtreringsmöjligheter). Console.app samlar in loggar från alla processer på Mac, inklusive iOS-simulatorer. För felsökning av iOS-appar använder utvecklare dock den inbyggda Console Xcode på grund av integrationen med LLDB-felsökaren.

Loggnings-API:er: NSLog, os_log och print

Tre huvudsakliga API:er finns tillgängliga för iOS-utvecklaren för utmatning i Console: NSLog (föråldrat), os_log (rekommenderat) och print (endast Swift). Var och en har sina egna egenskaper när det gäller prestanda, formatering och kompatibilitet med Unified Logging System.

NSLog — klassisk loggning

NSLog — funktion från Foundation, tillgänglig i Objective-C och Swift. NSLog skriver ut ett meddelande med tidsstämpel, processnamn och PID. Nackdelar: NSLog skriver till systembufferten synkront och blockerar den aktuella tråden under skrivningen. Vid frekventa anrop (t.ex. i en loop) skapar NSLog en märkbar fördröjning. Apple rekommenderar inte NSLog för nya projekt, men det förblir kompatibelt med gammal kod och tredjepartsbibliotek.

os_log — modern standard

os_log — API från os.framework, introducerat i iOS 10. os_log är asynkront: meddelandet placeras i en kö och skrivs till bufferten utan att blockera den anropande tråden. Enligt WWDC 2016 är os_log 50 gånger snabbare än NSLog i högbelastningsscenarier. os_log stöder också dynamisk hantering: DEBUG-nivåmeddelanden samlas endast in i Debug-bygget, i Release ignoreras de utan prestandakostnad.

print() — endast Swift-utmatning

print() — den enklaste utmatningsmetoden i Swift. print skriver till stdout (standardutmatning), som Xcode vidarebefordrar till Console. print lägger inte till metadata (tid, nivå), men stöder stdout-buffring. För snabb felsökning är print ett bekvämt verktyg, men för permanent loggning är det sämre än os_log när det gäller funktionalitet och kontroll.

import os.log

// NSLog — föråldrat, blockerande
NSLog("Application started")

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

// print — snabb Swift-utmatning
print("Application started")

Unified Logging: kategorier, nivåer och delsystem

Unified Logging System (ULS) — Apples omfattande loggningsinfrastruktur, introducerad i iOS 10 och macOS Sierra. ULS samlar in meddelanden från alla systemprocesser i en enda lagringsplats med fjärråtkomst via log-kommandoradsverktyget på Mac. Utvecklaren använder os_log för att skriva till ULS och Console för att läsa.

Delsystem och kategorier

Varje OSLog identifieras av ett par subsystem (t.ex. com.myapp.network) och category (t.ex. http, websocket). Delsystemet är appens domän (en app kan ha flera delsystem för olika moduler). Kategorin är en komponent inom delsystemet. Kombinationen subsystem + category möjliggör flexibel filtrering av loggar i Console och log collect.

OSLog-lognivåer

log collect — fjärrinsamling av loggar

Kommandot log collect på Mac samlar in arkiverade loggar från en ansluten iOS-enhet till en .logarchive-fil. Denna fil kan öppnas i Console.app på Mac för detaljerad analys, inklusive os_log-meddelanden, krashloggar och systemdiagnostik. För att aktivera insamling på enheten måste du aktivera Developer Mode och ansluta enheten via USB.

Arbeta med Console: steg-för-steg felsökning och analys av krashloggar

Praktiskt arbete med Console omfattar tre huvudscenarier: aktiv loggning under utveckling, analys av krashloggar efter krasch och fjärrdiagnostik via .logarchive. För varje scenario finns en optimal uppsättning verktyg och inställningar.

Konfigurera Console för utveckling

Det rekommenderas att skapa en separat OSLog för varje modul i appen med nivåer: debug (detaljerad felsökning), info (viktiga tillståndsövergångar), error (undantag och fel). I Xcode Console aktiverar du filter efter din apps delsystem för att utesluta systemmeddelanden som skapar brus och distraherar från applogiken.

Analys av krashlogg

Vid appkrasch stoppar Xcode automatiskt exekveringen och visar tråden där kraschen inträffade, med full stack trace i Console. Den första raden i krashloggen innehåller undantagstypen (NSException, EXC_BAD_ACCESS) och orsaken (reason). Studera stack trace från botten till toppen: den senast anropade metoden är kraschplatsen. För krypterade adresser (i Release) krävs symbolication via dSYM.

// Exempel på modulär OSLog-konfiguration
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"
    )
}

// Användning med nivåer
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)

Avancerade funktioner: brytpunktsloggar och anpassade format

Xcode Console stöder flera avancerade funktioner som går utöver enkel loggning. Brytpunktsloggar gör det möjligt att mata ut meddelanden i Console utan att stoppa exekveringen, och LLDB-kommandon i Debugger Command ger full kontroll över formateringen av utdata.

Brytpunktsloggar utan stopp

Du kan konfigurera en brytpunkt så att den matar ut ett meddelande i Console och automatiskt fortsätter exekveringen. Placera en brytpunkt på önskad rad, högerklicka → Edit Breakpoint → lägg till Debugger Command: “po self” eller “expr @import UIKit” + Debugger Command: “po self.view”. Markera Automatically continue after evaluating. Efter start kommer brytpunkten att visa kommandots resultat i Console varje gång raden nås, utan att avbryta tråden.

LLDB-kommandon i Console

Xcode Console stöder exekvering av godtyckliga LLDB-kommandon under stopp vid en brytpunkt. po (print object) visar objektbeskrivningen, p (print) — primitiva värden, och expr — utför Swift/ObjC-uttryck. För formaterad utdata använder du p/CGRectGetWidth. LLDB-utdata visas i Console omedelbart efter att brytpunkten nåtts.

func processUserData(user: User) {
    // Brytpunkt här med Debugger Command:
    // po "User name: \(user.name)"
    // expr user.age = 30
    print("Processing user: \(user.name)")
}

// Exempel på anpassad loggning med sekvens
func trackMethodCall(
    file: String = #file,
    function: String = #function
) {
    os_log("[\(function)] called",
        log: .uiLifecycle, type: .debug)
}

Integration med Instruments

Xcode Console är nära integrerad med Instruments — Xcode-profileringsverktyget. När appen startas via Product → Profile med Logging-mallen, registreras alla os_log-meddelanden i Instruments-spår med tidsstämplar. Detta gör det möjligt att samtidigt se loggar, prestanda och systemhändelser på samma tidsskala, vilket är avgörande för att diagnostisera race condition och prestandaregression.