The iPhone shields log output based on changes in the debug and release statuses.

Reference: http://www.cnblogs.com/springfield/archive/2011/05/04/2037089.html

Here is a very practical tips. When developing applications, we often use nslog to debug ourProgramAs 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.

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 judgeWhether or not the debug macro is defined. If there is a definition, we will replace the clog macro with the nslog call. If the debug flag is not defined, we will 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, write it on our own. Take xcode 4 as an example, 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 theseCodeFiles are hardly modified, so xcode only compiles these files once in the early stage, so that we can use these files repeatedly in the subsequent build process. 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.