Because of this, it is a common practice among developers to use the DEBUG preprocessor macro to conditionally compile your logging code so that it only appears in your debug builds (and does not ship to your final customers). But, for your final shipping product, it is better to remove all of the logging so your customers can enjoy faster performance without the logging going on. During testing, this normally isn't a problem. Note: NSLog can take time to execute and this will add additional overhead to the runtime of your application (especially if you add lots and lots of NSLog statements to your app). For more information about the substitution tokens that can be used with NSLog see the " String Format Specifiers" section of the " String Programming Guide".Ġ AVCustomEdit 0x0000efa6 - + 278ġ AVCustomEdit 0x0000686e - + 590Ģ UIKit 0x007a4099 - + 526ģ UIKit 0x007a4617 - + 146Ĥ UIKit 0x007a49aa - + 63ĥ UIKit 0x0069f0d0 _afterCACommitHandler_block_invoke_2 + 33Ħ UIKit 0x0069f055 _applyBlockToCFArra圜opiedToStack + 403ħ UIKit 0x0069ee9a _afterCACommitHandler + 568Ĩ CoreFoundation 0x029db2bf _CFRunLoopDoObservers + 399ĩ CoreFoundation 0x029b9254 _CFRunLoopRun + 1076ġ0 CoreFoundation 0x029b89d3 CFRunLoopRunSpecific + 467ġ1 CoreFoundation 0x029b87eb CFRunLoopRunInMode + 123ġ2 GraphicsServices 0x0318b5ee GSEventRunModal + 192ġ3 GraphicsServices 0x0318b42b GSEventRun + 104ġ4 UIKit 0x00681f9b UIApplicationMain + 1225 This will allow you to display many different kinds of values. In addition to the substitution token, all of the regular printf style substitution tokens can be used in the formatting string. Printing error messages in your logs that explicitly tell you when values are out of range will help you recognize these cases. Printing variable and property values at key places during the execution of your app will allow you to verify that those values are within acceptable bounds. In every log statement, it is useful to include some unique and easy to find text pattern so if you do identify a problem in that log statement you can easily search through your source files and find its location. It is often useful to add many NSLog statements to especially complex sequences of code so you can better understand the flow of execution at runtime. Here are some items that are commonly included in logs with some explanation: Logic and branchingĪdding logging statements inside of the logic of your code will help you understand which parts are being executed and which branches in your logic are being utilized. As such, you want to include as much useful information in your logs as possible so that it is easier for you to really see what is happening as your app runs.
Logging allows you to create a transcript describing the operation of your application that you can later analyze at your leisure. The remainder of this document discuses the NSLog function, however many of the same strategies discussed apply to apps written using the Swift language.īack to Top Good things to include in your logs For more information about the CustomDebugStringConvertible protocol, see Standard Swift Library API Reference: CustomDebugStringConvertible. To override the default representation used for logging your custom data types using the the debugPrint(_:) function, you can make your custom data types conform to the CustomDebugStringConvertible protocol. Figure 1 Example showing logging in Swift using the debugPrint(_:) and dump(_:) functions.įor more information about the debugPrint(_:) function, see Standard Swift Library API Reference: debugPrint(_:separator:terminator:to:). As shown in Figure 1, the debugPrint(_:) function will sometimes display additional information and the dump(_:) function will use the object's mirror to print information to standard output. The print(_:) or debugPrint(_:) functions can be used to log output from your app to the console for any data type. Swift provides a default debugging textual representation that you can use for printing any type. Document Revision History Logging in Swift
0 kommentar(er)
