XCGLogger
1.0.0
XCGLOGGER ist das ursprüngliche Debug -Protokollmodul für die Verwendung in Swift -Projekten.
Swift enthält keinen C-Präprozessor #define sodass Entwickler das Debug-Protokoll nicht verwenden können. Dies bedeutet, dass unsere traditionelle Art, schöne Debug -Protokolle zu generieren, nicht mehr funktioniert. Wenn Sie auf nur alte print zurückgreifen, verlieren Sie viele hilfreiche Informationen oder müssen viel mehr Code eingeben.
Mit XCGLogger können Sie Details an der Konsole (und optional eine Datei oder andere benutzerdefinierte Ziele) protokollieren, genau wie Sie es mit NSLog() oder print() hätten, jedoch mit zusätzlichen Informationen wie Datum, Funktionsname, Dateiname und Zeilennummer.
Gehen Sie davon:
Simple message
dazu:
2014-06-09 06:44:43.600 [Debug] [AppDelegate.swift:40] application(_:didFinishLaunchingWithOptions:): Simple message
Ausführen:
git submodule add https://github.com/DaveWoodCom/XCGLogger.git
in Ihrem Repository -Ordner.
Fügen Sie Ihrem Cartfile die folgende Zeile hinzu.
github "DaveWoodCom/XCGLogger" ~> 7.1.5
Führen Sie dann carthage update --no-use-binaries oder nur carthage update . Einzelheiten zur Installation und Verwendung von Karthago finden Sie auf der Projektseite.
Entwickler, die in Swift 5.0 und höher laufen, müssen $(SRCROOT)/Carthage/Build/iOS/ObjcExceptionBridging.framework zu ihren Eingabedateien in der Build -Phase der Kopie -Karthage -Frameworks hinzufügen.
Fügen Sie Ihrer Podfile etwas Ähnliches wie die folgenden Zeilen hinzu. Möglicherweise müssen Sie sich anhand Ihrer Plattform, Version/Filiale usw. anpassen.
source 'https://github.com/CocoaPods/Specs.git'
platform :ios, '12.0'
use_frameworks!
pod 'XCGLogger', '~> 7.1.5'
Die Angabe des POD XCGLogger selbst wird das Kerngerüst enthalten. Wir fangen an, Subspecs hinzuzufügen, mit denen Sie auch optionale Komponenten einfügen können:
pod 'XCGLogger/UserInfoHelpers', '~> 7.1.5' : Fügen Sie einen experimentellen Code hinzu, mit dem Sie die Verwendung von Benutzerinfo -Wörterbüchern zum Tag -Protokollnachrichten verarbeiten können.
Führen Sie dann pod install aus. Einzelheiten zur Installation und Verwendung von Cocoapods finden Sie auf der offiziellen Website.
Hinweis: Vor Cocoapods 1.4.0 war es nicht möglich, mehrere Pods mit einer Mischung von schnellen Versionen zu verwenden. Möglicherweise müssen Sie sicherstellen, dass jeder Pod für die richtige Swift -Version konfiguriert ist (überprüfen Sie die Ziele im POD -Projekt Ihres Arbeitsbereichs). Wenn Sie die Swift -Version für ein Projekt manuell einstellen, wird sie beim nächsten Ausführen pod install zurückgesetzt. Sie können Ihren Podfile einen post_install -Haken hinzufügen, um die richtigen Swift -Versionen zu automatisieren. Dies ist weitgehend ungetestet und ich bin mir nicht sicher, ob es eine gute Lösung ist, aber es scheint zu funktionieren:
post_install do |installer|
installer.pods_project.targets.each do |target|
if ['SomeTarget-iOS', 'SomeTarget-watchOS'].include? "#{target}"
print "Setting #{target}'s SWIFT_VERSION to 4.2n"
target.build_configurations.each do |config|
config.build_settings['SWIFT_VERSION'] = '4.2'
end
else
print "Setting #{target}'s SWIFT_VERSION to Undefined (Xcode will automatically resolve)n"
target.build_configurations.each do |config|
config.build_settings.delete('SWIFT_VERSION')
end
end
end
print "Setting the default SWIFT_VERSION to 3.2n"
installer.pods_project.build_configurations.each do |config|
config.build_settings['SWIFT_VERSION'] = '3.2'
end
end
Sie können das natürlich an Ihre Bedürfnisse anpassen.
Fügen Sie den folgenden Eintrag in die Abhängigkeiten Ihres Pakets hinzu:
.Package(url: "https://github.com/DaveWoodCom/XCGLogger.git", majorVersion: 7)
Verwenden:
Diese schnelle Startmethode ist nur dazu gedacht, Sie mit dem Logger zum Laufen zu bringen. Sie sollten jedoch die erweiterte Verwendung unten verwenden, um das Beste aus dieser Bibliothek herauszuholen.
Fügen Sie das XCGloGger -Projekt als Unterprojekt in Ihr Projekt hinzu und fügen Sie die entsprechende Bibliothek als Abhängigkeit Ihres Ziels hinzu. Fügen Sie unter der General Registerkarte Ihres Ziels XCGLogger.framework und ObjcExceptionBridging.framework in den Abschnitt Embedded Binaries hinzu.
Dann in jeder Quelldatei:
import XCGLoggerDeklarieren Sie in Ihrem AppDelegate (oder einer anderen globalen Datei) eine globale Konstante für die Standard -XCGlogger -Instanz.
let log = XCGLogger . defaultIm
application ( _ application : UIApplication , didFinishLaunchingWithOptions launchOptions : [ UIApplicationLaunchOptionsKey : Any ] ? = nil ) // iOS, tvOSoder
applicationDidFinishLaunching ( _ notification : Notification ) // macOSFunktion, konfigurieren Sie die Optionen, die Sie benötigen:
log . setup ( level : . debug , showThreadName : true , showLevel : true , showFileNames : true , showLineNumbers : true , writeToFile : " path/to/file " , fileLevel : . debug ) Der Wert für writeToFile: Kann eine String oder URL sein. Wenn die Datei bereits vorhanden ist, wird sie gelöscht, bevor wir sie verwenden. Lassen Sie den Parameter weg oder setzen Sie ihn auf nil , um sich nur bei der Konsole zu melden. Sie können optional eine andere Protokollebene für die Dateiausgabe mithilfe des Parameters fileLevel: festlegen. Stellen Sie es auf nil ein oder lassen Sie es aus, um die gleiche Protokollebene wie die Konsole zu verwenden.
Wenn Sie dann etwas protokollieren möchten, verwenden Sie eine der Convenience -Methoden:
log . verbose ( " A verbose message, usually useful when working on a specific problem " )
log . debug ( " A debug message " )
log . info ( " An info message, probably useful to power users looking in console.app " )
log . notice ( " A notice message " )
log . warning ( " A warning message, may indicate a possible error " )
log . error ( " An error occurred, but it's recoverable, just info about what happened " )
log . severe ( " A severe error occurred, we are likely about to crash now " )
log . alert ( " An alert error occurred, a log destination could be made to email someone " )
log . emergency ( " An emergency error occurred, a log destination could be made to text someone " ) Die verschiedenen Methoden setzen die Protokollebene der Nachricht. XCGLOGGER druckt nur Nachrichten mit einer Protokollebene, die der aktuellen Protokollebene eingestellt oder gleich ist. Ein Logger mit .error gibt also nur Protokollnachrichten mit einer Ebene von .error , .severe , .alert oder .emergency
XCGLOGGER zielt darauf ab, einfach zu verwenden und Sie schnell mit nur 2 Codezeilen oben zu betreiben. Aber es ermöglicht viel größere Kontrolle und Flexibilität.
Ein Logger kann konfiguriert werden, um Protokollnachrichten an eine Vielzahl von Zielen zu übermitteln. Unter Verwendung des obigen Basis -Setups gibt der Protokollsprotokollnachrichten an die Standard -Xcode -Debug -Konsole aus und optional eine Datei, wenn ein Pfad bereitgestellt wird. Es ist sehr wahrscheinlich, dass Sie Protokolle an interessantere Orte wie die Apple System Console, eine Datenbank, einen Drittanbieter oder eine andere Anwendung wie NSLogger senden möchten. Dies wird erreicht, indem das Ziel dem Logger hinzugefügt wird.
Hier ist ein Beispiel für die Konfiguration des Protokolls für die Ausgabe für das Apple -Systemprotokoll sowie eine Datei.
// Create a logger object with no destinations
let log = XCGLogger ( identifier : " advancedLogger " , includeDefaultDestinations : false )
// Create a destination for the system console log (via NSLog)
let systemDestination = AppleSystemLogDestination ( identifier : " advancedLogger.systemDestination " )
// Optionally set some configuration options
systemDestination . outputLevel = . debug
systemDestination . showLogIdentifier = false
systemDestination . showFunctionName = true
systemDestination . showThreadName = true
systemDestination . showLevel = true
systemDestination . showFileName = true
systemDestination . showLineNumber = true
systemDestination . showDate = true
// Add the destination to the logger
log . add ( destination : systemDestination )
// Create a file log destination
let fileDestination = FileDestination ( writeToFile : " /path/to/file " , identifier : " advancedLogger.fileDestination " )
// Optionally set some configuration options
fileDestination . outputLevel = . debug
fileDestination . showLogIdentifier = false
fileDestination . showFunctionName = true
fileDestination . showThreadName = true
fileDestination . showLevel = true
fileDestination . showFileName = true
fileDestination . showLineNumber = true
fileDestination . showDate = true
// Process this destination in the background
fileDestination . logQueue = XCGLogger . logQueue
// Add the destination to the logger
log . add ( destination : fileDestination )
// Add basic app info, version info etc, to the start of the logs
log . logAppDetails ( )Sie können jedes Protokollziel je nach Ihren Anforderungen mit unterschiedlichen Optionen konfigurieren.
Ein weiteres häufiges Verwendungsmuster ist, mehrere Holzfäller zu haben, möglicherweise eines für UI -Probleme, eines für die Vernetzung und eine andere für Datenprobleme.
Jedes Protokollziel kann eine eigene Protokollebene haben. Als Komfort können Sie die Protokollebene auf dem Protokollobjekt selbst festlegen und diese Ebene an jedes Ziel übergeben. Stellen Sie dann die Ziele ein, die anders sein müssen.
Hinweis : Ein Zielobjekt kann nur zu einem Logger -Objekt hinzugefügt werden. Wenn Sie es zu einer Sekunde hinzufügen, wird es von der ersten entfernt.
Alternativ können Sie einen Verschluss verwenden, um Ihre globale Variable zu initialisieren, damit die gesamte Initialisierung an einem Ort durchgeführt wird
let log : XCGLogger = {
let log = XCGLogger ( identifier : " advancedLogger " , includeDefaultDestinations : false )
// Customize as needed
return log
} ( ) HINWEIS : Dies erstellt das Protokollobjekt träge, was bedeutet, dass es erst dann erstellt wird, wenn es tatsächlich benötigt wird. Dadurch verzögert sich die anfängliche Ausgabe der App -Informationsdetails. Aus diesem Grund empfehle ich, das Protokollobjekt beim Start von App zu erstellen, indem Sie die Zeile hinzufügen let _ = log oben in Ihrer didFinishLaunching -Methode, wenn Sie noch nicht etwas beim App -Start protokollieren.
Sie können Zeichenfolgen protokollieren:
log . debug ( " Hi there! " )oder so ziemlich alles, was Sie wollen:
log . debug ( true )
log . debug ( CGPoint ( x : 1.1 , y : 2.2 ) )
log . debug ( MyEnum . Option )
log . debug ( ( 4 , 2 ) )
log . debug ( [ " Device " : " iPhone " , " Version " : 7 ] ) Neu bei XCGLogger 4 können Sie jetzt Filter erstellen, die für Ihren Protokoll (oder auf bestimmte Ziele) angewendet werden können. Erstellen und konfigurieren Sie Ihre Filter (Beispiele unten) und fügen Sie sie dann dem Protokoll- oder Zielobjekte hinzu, indem Sie die Eigenschaft der optionalen filters in ein Array mit den Filtern einstellen. Filter werden in der Reihenfolge angewendet, die sie im Array existieren. Während der Verarbeitung wird jeder Filter gefragt, ob die Protokollnachricht aus dem Protokoll ausgeschlossen werden sollte. Wenn ein Filter die Protokollnachricht ausschließt, ist sie ausgeschlossen. Filter haben keine Möglichkeit, den Ausschluss eines anderen Filters umzukehren.
Wenn filters eines Ziels nil ist, wird stattdessen die filters des Protokolls verwendet. Um ein Ziel zu haben, protokolliert alles, während alle anderen Ziele etwas filtern, fügen Sie die Filter zum Protokollobjekt hinzu und setzen Sie die filters eines Ziels in ein leeres Array [] .
HINWEIS : Im Gegensatz zu Zielen können Sie mehreren Loggers und/oder mehreren Zielen dasselbe Filterobjekt hinzufügen.
Um alle Protokollnachrichten aus einer bestimmten Datei auszuschließen, erstellen Sie einen Ausschlussfilter wie SO:
log . filters = [ FileNameFilter ( excludeFrom : [ " AppDelegate.swift " ] , excludePathWhenMatching : true ) ] excludeFrom: Nimmt ein Array<String> oder Set<String> ein, damit Sie mehrere Dateien gleichzeitig angeben können.
excludePathWhenMatching: Standards an true , damit Sie es weglassen können, es sei denn, Sie möchten auch Pfade entsprechen.
Um Protokollnachrichten nur für einen bestimmten Satz für Dateien einzubeziehen, erstellen Sie den Filter mit dem includeFrom: Initializer. Es ist auch möglich, die inverse Eigenschaft nur umzuschalten, um den Ausschlussfilter in einen Einschlussfilter umzudrehen.
Um Protokollnachrichten per Tag zu filtern, müssen Sie natürlich in der Lage sein, ein Tag in den Protokollnachrichten festzulegen. Jede Protokollnachricht kann nun zusätzliche, benutzerdefinierte Daten an sie angehängt haben, die von Filtern (und/oder Formatierungen usw.) verwendet werden können. Dies wird mit einem userInfo: Dictionary<String, Any> Objekt behandelt. Der Wörterbuchschlüssel sollte eine Namenszeichenfolge sein, um Kollisionen mit zukünftigen Ergänzungen zu vermeiden. Offizielle Schlüssel beginnen mit com.cerebralgardens.xcglogger . Der Tag -Taste kann von XCGLogger.Constants.userInfoKeyTags zugegriffen werden. Sie möchten das definitiv nicht tippen. Erstellen Sie also eine globale Verknüpfung: let tags = XCGLogger.Constants.userInfoKeyTags . Jetzt können Sie Ihre Protokolle problemlos markieren:
let sensitiveTag = " Sensitive "
log . debug ( " A tagged log message " , userInfo : [ tags : sensitiveTag ] ) Der Wert für Tags kann je nach Ihren Anforderungen ein Array<String> , Set<String> oder nur eine String sein. Sie werden alle genauso arbeiten, wenn sie gefiltert werden.
Abhängig von Ihrem Workflow und Ihrer Nutzung erstellen Sie wahrscheinlich schnellere Methoden, um das userInfo -Wörterbuch einzurichten. Weitere mögliche Verknüpfungen finden Sie unten.
Nachdem Sie Ihre Protokolle markiert haben, können Sie leicht filtern:
log . filters = [ TagFilter ( excludeFrom : [ sensitiveTag ] ) ] Genau wie der FileNameFilter können Sie includeFrom: oder inverse um nur Protokollnachrichten mit den angegebenen Tags einzuschließen.
Die Filterung durch den Entwickler ist genau wie Filterung nach Tag, nur mit dem userInfo -Schlüssel von XCGLogger.Constants.userInfoKeyDevs . Tatsächlich sind beide Filter Unterklassen der UserInfoFilter -Klasse, mit der Sie zusätzliche Filter erstellen können. Siehe Erweiterung XCGLOGGER unten.
In großen Projekten mit mehreren Entwicklern möchten Sie wahrscheinlich mit dem Tagging -Protokollmeldungen beginnen und dem Entwickler angeben, der die Nachricht hinzugefügt hat.
Das userInfo -Wörterbuch kann zwar extrem flexibel sind, kann ein wenig umständlich sein. Es gibt einige mögliche Methoden, mit denen Sie einfach Dinge verwenden können. Ich teste diese immer noch selbst aus, damit sie noch nicht offiziell Teil der Bibliothek sind (ich würde Feedback oder andere Vorschläge lieben).
Ich habe einen experimentellen Code erstellt, um die Benutzerinfo -Wörterbücher zu erstellen. (Fügen Sie den optionalen UserInfoHelpers subspec bei Verwendung von Cocoapods hinzu). Überprüfen Sie die iOS -Demo -App, um sie zu verwenden.
Es gibt zwei Strukturen, die dem UserInfoTaggingProtocol -Protokoll entsprechen. Tag und Dev .
Sie können jeweils eine Erweiterung erstellen, die zu Ihrem Projekt passt. Zum Beispiel:
extension Tag {
static let sensitive = Tag ( " sensitive " )
static let ui = Tag ( " ui " )
static let data = Tag ( " data " )
}
extension Dev {
static let dave = Dev ( " dave " )
static let sabby = Dev ( " sabby " )
} Zusammen mit diesen Typen gibt es einen überlasteten Operator | Dies kann verwendet werden, um sie zu einem Wörterbuch zusammenzuführen, das mit dem Parameter UserInfo: Parameter der Protokollierungsaufrufe kompatibel ist.
Dann können Sie solche Nachrichten protokollieren:
log . debug ( " A tagged log message " , userInfo : Dev . dave | Tag . sensitive ) Es gibt einige aktuelle Probleme, die ich bei diesen UserInfoHelpers sehe, weshalb ich es vorerst optional/experimentell gemacht habe. Ich würde gerne Kommentare/Vorschläge für Verbesserungen hören.
| verschmelzen Wörterbücher, solange es keine Set gibt. Wenn eines der Wörterbücher einen Set enthält, wird es einen von ihnen verwenden, ohne sie zu verschmelzen. Bevorzugen Sie die linke Seite, wenn beide Seiten einen Satz für denselben Schlüssel haben.userInfo: Parameter ein Wörterbuch benötigt, können Sie kein einzelnes Entwickler- oder Tag -Objekt übergeben. Sie müssen mindestens zwei mit dem | verwenden Bediener, damit es automatisch in ein kompatibles Wörterbuch konvertiert wird. Wenn Sie beispielsweise nur ein Tag wünschen, müssen Sie manuell auf den .dictionary userInfo: Tag("Blah").dictionary Alle Protokollmethoden arbeiten bei Schließungen. Mit dem gleichen syntaktischen Zucker wie Swifts assert() -Funktion stellt dieser Ansatz sicher, dass wir keine Ressourcen für die Erstellung von Protokollnachrichten verschwenden, die ohnehin nicht ausgegeben werden, während gleichzeitig eine saubere Anrufe beibehalten wird.
Beispielsweise verschwendet die folgende Protokollanweisung keine Ressourcen, wenn die Debug -Protokollebene unterdrückt wird:
log . debug ( " The description of ( thisObject ) is really expensive to create " ) Angenommen, Sie müssen eine Schleife durchführen, um vor dem Protokollieren des Ergebniss eine Schleife durchzuführen. In Objective-C können Sie diesen Codeblock zwischen #if #endif einstellen und den Code verhindern. Aber in Swift müssten Sie zuvor diese Schleife noch verarbeiten und Ressourcen verschwenden. Mit XCGLogger ist es so einfach wie:
log . debug {
var total = 0.0
for receipt in receipts {
total += receipt . total
}
return " Total of all receipts: ( total ) "
} In Fällen, in denen Sie Code selektiv ausführen möchten, ohne eine Protokollzeile zu generieren, geben Sie nil zurück oder verwenden Sie eine der Methoden: verboseExec , debugExec , infoExec , warningExec , errorExec und severeExec .
Sie können Ihr eigenes DateFormatter -Objekt erstellen und es dem Protokoll zuweisen.
let dateFormatter = DateFormatter ( )
dateFormatter . dateFormat = " MM/dd/yyyy hh:mma "
dateFormatter . locale = Locale . current
log . dateFormatter = dateFormatterXCGLOGGER unterstützt das Hinzufügen von Formatierungscodes zu Ihren Protokollnachrichten, um die Farbe an verschiedenen Stellen zu aktivieren. Die ursprüngliche Option bestand darin, das XCodeColors-Plug-In zu verwenden. Xcode (ab Version 8) unterstützt jedoch keine Plug-Ins mehr. Sie können Ihre Protokolle immer noch in Farbe anzeigen, nur nicht in Xcode. Sie können die ANSI -Farbunterstützung verwenden, um Ihren Anmeldestinationsobjekten Farbe hinzuzufügen und Ihre Protokolle über ein Terminalfenster anzusehen. Dies gibt Ihnen einige zusätzliche Optionen wie das Hinzufügen mutiger, Kursivschrift oder (bitte nicht) blinzelt!
Sobald es aktiviert ist, kann jede Protokollebene eine eigene Farbe haben. Diese Farben können wie gewünscht angepasst werden. Wenn Sie mehrere Holzfäller verwenden, können Sie jeden Logger alternativ auf seine eigene Farbe einstellen.
Ein Beispiel für die Einrichtung des ANSI -Formaters:
if let fileDestination : FileDestination = log . destination ( withIdentifier : XCGLogger . Constants . fileDestinationIdentifier ) as? FileDestination {
let ansiColorLogFormatter : ANSIColorLogFormatter = ANSIColorLogFormatter ( )
ansiColorLogFormatter . colorize ( level : . verbose , with : . colorIndex ( number : 244 ) , options : [ . faint ] )
ansiColorLogFormatter . colorize ( level : . debug , with : . black )
ansiColorLogFormatter . colorize ( level : . info , with : . blue , options : [ . underline ] )
ansiColorLogFormatter . colorize ( level : . notice , with : . green , options : [ . italic ] )
ansiColorLogFormatter . colorize ( level : . warning , with : . red , options : [ . faint ] )
ansiColorLogFormatter . colorize ( level : . error , with : . red , options : [ . bold ] )
ansiColorLogFormatter . colorize ( level : . severe , with : . white , on : . red )
ansiColorLogFormatter . colorize ( level : . alert , with : . white , on : . red , options : [ . bold ] )
ansiColorLogFormatter . colorize ( level : . emergency , with : . white , on : . red , options : [ . bold , . blink ] )
fileDestination . formatters = [ ansiColorLogFormatter ]
} Wie bei Filtern können Sie dieselben Formatterobjekte für mehrere Holzfäller und/oder mehrere Ziele verwenden. Wenn die formatters eines Ziels nil ist, wird stattdessen die formatters des Loggers verwendet.
Weitere Informationen zum Erstellen Ihrer eigenen benutzerdefinierten Formatierungen finden Sie unter Erweiterung von XCGLOGGER.
Durch die Verwendung von Swift -Build -Flags können unterschiedliche Protokollpegel für das Debuggen im Vergleich zu Inszenierung/Produktion verwendet werden. Gehen Sie zu Build -Einstellungen -> Swift -Compiler -benutzerdefinierte Flaggen -> Andere Swift -Flags und fügen Sie den Debug -Eintrag -DDEBUG hinzu.
#if DEBUG
log . setup ( level : . debug , showThreadName : true , showLevel : true , showFileNames : true , showLineNumbers : true )
#else
log . setup ( level : . severe , showThreadName : true , showLevel : true , showFileNames : true , showLineNumbers : true )
#endif Sie können eine beliebige Anzahl von Optionen auf ähnliche Weise einstellen. In der aktualisierten iOSdemo -App suchen Sie ein Beispiel für die Verwendung verschiedener Protokolldestinationen basierend auf Optionen. Suchen Sie nach USE_NSLOG .
Standardmäßig verarbeiten die mitgelieferten Protokolldestinationen die Protokolle in dem von ihnen gerufenen Thread. Dies soll sicherstellen, dass die Protokollnachricht beim Debuggen einer Anwendung sofort angezeigt wird. Sie können sofort nach einem Protokollaufruf einen Haltepunkt hinzufügen und die Ergebnisse sehen, wenn der Haltepunkt trifft.
Wenn Sie jedoch nicht aktiv die Anwendung debuggen, kann die Verarbeitung der Protokolle im aktuellen Thread einen Performance -Hit einführen. Sie können jetzt einen Zielverfahren angeben. Seine Protokolle in einer Versand -Warteschlange Ihrer Wahl (oder sogar einen ausgelieferten Standard verwenden).
fileDestination . logQueue = XCGLogger . logQueueoder auch
fileDestination . logQueue = DispatchQueue . global ( qos : . background )Dies funktioniert extrem gut, wenn sie mit der oben genannten Konfigurationsmethode kombiniert werden.
#if DEBUG
log . setup ( level : . debug , showThreadName : true , showLevel : true , showFileNames : true , showLineNumbers : true )
#else
log . setup ( level : . severe , showThreadName : true , showLevel : true , showFileNames : true , showLineNumbers : true )
if let consoleLog = log . logDestination ( XCGLogger . Constants . baseConsoleDestinationIdentifier ) as? ConsoleDestination {
consoleLog . logQueue = XCGLogger . logQueue
}
#endifWenn Sie die erweiterte Konfiguration des Protokolls verwenden (siehe erweiterte Verwendung oben), können Sie nun angeben, dass der Protokoller an eine vorhandene Protokolldatei angehängt wird, anstatt sie automatisch zu überschreiben.
Fügen Sie das optionale shouldAppend: Parameter bei der Initialisierung des FileDestination hinzu. Sie können auch den Parameter appendMarker: Parameter hinzufügen, um der Protokolldatei einen Marker hinzuzufügen, in dem angegeben ist, wo eine neue Instanz Ihrer App angemeldet wurde. Standardmäßig fügen wir hinzu -- ** ** ** -- Wenn der Parameter weggelassen wird. Stellen Sie es auf nil ein, um das Anhängen des Markers zu überspringen.
let fileDestination = FileDestination(writeToFile: "/path/to/file", identifier: "advancedLogger.fileDestination", shouldAppend: true, appendMarker: "-- Relauched App --")
Wenn Sie sich bei einer Datei anmelden, haben Sie die Option, die Protokolldatei automatisch in ein archiviertes Ziel zu drehen und den Protokoller automatisch eine neue Protokolldatei anstelle des alten zu erstellen.
Erstellen Sie ein Ziel mit der AutoRotatingFileDestination -Klasse und setzen Sie die folgenden Eigenschaften fest:
targetMaxFileSize : automatisch drehen, sobald die Datei größer ist als diese
targetMaxTimeInterval : automatisch nach so vielen Sekunden drehen
targetMaxLogFiles : Anzahl der zu halten archivierten Protokolldateien, ältere werden automatisch gelöscht
Dies sind alles Richtlinien für den Logger, nicht für harte Grenzen.
Sie können alternative Protokolldestinationen erstellen (neben den integrierten). Ihr benutzerdefiniertes Protokollziel muss das DestinationProtocol -Protokoll implementieren. Instantieren Sie Ihr Objekt, konfigurieren Sie es und fügen Sie es dann mit add(destination:) zum XCGLogger -Objekt hinzu. Es gibt zwei Basiszielklassen ( BaseDestination und basiert und BaseQueuedDestination ), von denen Sie erben können, um den größten Teil des Prozesses für Sie zu verarbeiten, und Sie müssen nur eine zusätzliche Methode in Ihrer benutzerdefinierten Klasse implementieren. Schauen Sie sich ConsoleDestination und FileDestination für Beispiele an.
Sie können auch benutzerdefinierte Filter oder Formatierungen erstellen. Schauen Sie sich die bereitgestellten Versionen als Ausgangspunkt an. Beachten Sie, dass Filter und Formatter die Möglichkeit haben, die Protokollnachrichten zu ändern, sobald sie verarbeitet werden. Dies bedeutet, dass Sie einen Filter erstellen können, der Kennwörter streift, bestimmte Wörter hervorhebt, Nachrichten verschlüsselt usw.
XCGLOGGER ist aufgrund der Beiträge der Community wie Ihnen der beste Logger für Swift. Es gibt viele Möglichkeiten, wie Sie es weiterhin großartig machen können.
HINWEIS : Wenn Sie eine Pull -Anfrage einreichen, verwenden Sie bitte viele kleine Commits Verse, ein großes Commit. Es erleichtert es viel einfacher, sich zu verschmelzen, wenn mehrere Pull -Anfragen für eine neue Version kombiniert werden müssen.
Wenn Sie diese Bibliothek hilfreich finden, finden Sie dieses andere Tool auf jeden Fall hilfreich:
Watchdog: https://watchdogforxcode.com/
Bitte schauen Sie sich auch einige meiner anderen Projekte an:
Das Änderungsprotokoll befindet sich jetzt in einer eigenen Datei: Changelog.md
