IOS shields log output based on changes in debug and release statuses

Here is a very practical tips. When developing applications, we often use nslog to debug our programs. As the project grows, the log output for debugging becomes difficult to manage. When releasing the official version, we must block all background outputs because these outputs consume system resources. At this point, we have to find the nslog call in one row and comment out it. This is more effective when the project is small, but as the project grows, it will become increasingly difficult to control. Next we will introduce a simple method for you to block all log output without any changes when generating the release version. (That is, the trace function in C ++ is provided, which is not provided by IOS currently. It is very disappointing. It should be added later)

1. First, we need to define such a pre-processing command. The file name can be started as needed, such as clog. h.

#ifdef DEBUG#define CLog(format, ...)  NSLog(format, ## __VA_ARGS__)#else#define CLog(format, ...)#endif

Here, we determine whether the macro debug is defined (it is best to use the _ debug macro, which is consistent with that in C ++). If there is a definition, we will replace the clog macro with the nslog call,

If the debug flag has not been defined, we can skip it directly. This is not hard to understand.

2.
Check whether the debug flag is correctly defined. xcode usually defines the debug flag in the debug running configuration item,

If it is not defined, we can write it on our own, using my xcode4
For example:

 

Find the Preprocessor macros attribute and write debug for the debug configuration, while leave it blank in the release configuration. In this way, the pre-processing command just now can be used to determine whether the debug version or the release version is compiled to control the nslog output. (Because xcode 4 compares the two configuration items debug/release at the same time, and 3. versions X can only be set separately. If xcode 3.x is used, check both Debug and release ).

3. At this point, we have finished our judgment, but it is a little more troublesome. If we want to use clog macros, We must import the clog. h header file. However, xcode provides us with a very clever solution. Let's take a look at the project file, is there a file called xxx-prefix.pch, as long as you notice the PCH extension. What is the purpose of this file? The following is a sample of a PCH file:

//// Prefix header for all source files //#import <Availability.h>#ifndef __IPHONE_3_0#warning "This project uses features only available in iPhone SDK 3.0 and later."#endif#ifdef __OBJC__    #import <UIKit/UIKit.h>    #import <Foundation/Foundation.h>#endif

Some header files are introduced here, which is actually a pre-compilation mechanism of xcode. When we compile a project, there will be many common source files, and these code files will be hardly modified, therefore, xcode only compiles these files once in the early stage, so that we can build these files multiple times in the future. For example, in uikit and foundation, this mechanism can speed up every time we build a project. Of course, we don't have to go into it too deeply here. After knowing its role, we can use it to facilitate our development. We just need to introduce the just-created clog. h here, so that all the files in our project can access the clog macro we just defined.
The following is the PCH file after completion:

#import <Availability.h>#ifndef __IPHONE_3_0#warning "This project uses features only available in iPhone SDK 3.0 and later."#endif#ifdef __OBJC__    #import <UIKit/UIKit.h>    #import <Foundation/Foundation.h>    #import "CLog.h"#endif

In this way, our clog is complete. Now we can use the clog macro to output logs in any source file. The pre-processing command will automatically judge the current compilation configuration. If it is debug, logs are output, but nothing is output.