1.自定义宏实现log,附加输出当前的函数和行数。
- #define NSLog(format, ...) do { \
- fprintf(stderr, "<%s : %d> %s\n", \
- [[[NSString stringWithUTF8String:__FILE__] lastPathComponent] UTF8String], \
- __LINE__, __func__); \
- (NSLog)((format), ##__VA_ARGS__); \
- fprintf(stderr, "-------\n"); \
- } while (0)
输出:
- <AppDelegate.m : 46> -[AppDelegate application:didFinishLaunchingWithOptions:]
- 2014-01-20 16:44:25.480 TestProject[30466:70b] The array is (
- Hello,
- My,
- Macro
- )
2.聪明地使用NSLog
在release版本禁止输出NSLog内容
任何由NSLog输出的内容都会成为成品代码的一部分,也就是说会被任何接触到应用的人看到。只要把设备接入信息管理工具,每个人都能查看控制台信息并查询每一条日志记录。没错,这必然会引发一系列严重后果。试想一下,如果我们曾经向控制台输出过机密逻辑算法或者者用户密码,这些信息一旦被他人获得将带来恶劣影响。有鉴于此,苹果公司会在App Store的审核流程中检测控制台信息。一旦发现其中包含太多输出结果,应用程序将被直接打回开发者处进行调整。
在-Prefix.pch(pch全称是“precompiled header”,也就是预编译头文件,该文件里存放的工程中一些不常被修改的代码,比如常用的框架头文件,这样做的目的提高编译器编译速度。我们知道当我们修改一个工程中某个文件代码时候,编译器并不是重新编译所有所有文件,而是编译改动过文件的,假如pch中某个文件修改了,那么pch整个文件里包含的的其他文件也会重新编译一次,这样就会消耗大量时间,所以它里面添加的文件最好是是很少变动或不变动的头文件或者是预编译的代码片段;)文件中添加
#ifdef DEBUG
# define DebugLog(fmt, ...) NSLog((@"[DEBUG]%s " fmt), __PRETTY_FUNCTION__, ##__VA_ARGS__);
#else
# define DebugLog(...)
#endif
或者:
- #ifdef DEBUG
- #define DMLog(...) NSLog(@"%s %@", __PRETTY_FUNCTION__, [NSString stringWithFormat:__VA_ARGS__])
- #else
- #define DMLog(...) do { } while (0)
上段代码的意思就是 用宏指令做一个判断,如果DEBUG为真,则编译#ifdef到#endif宏定义,否则编译器就不编译;
这个DEBUG在哪设置呢,
在 "Target > Build Settings > Preprocessor Macros > Debug" 里有一个"DEBUG=1"。
设置为Debug模式下,Product-->Scheme-->SchemeEdit Scheme现在如果我们使用DMLog(这个名称可以随便起),它将只向调试版本输出结果,任何成品代码都不会受到影响。_PRETTY_FUNCTION_也帮上了大忙,它会根据日志信息来源为函数命名。
采取下一个步骤
虽然NSLog表现卓越,但其局限性也不可忽视:
- 它只能向本地输出结果;
- 我们无法为其添加日志“等级”(例如严重、警告等等);
- NSLog速度很慢。在进行大量处理时它会严重拖慢应用程序的运行效果。
对于想给自己来点挑战的开发者来说,还有两款框架能够回避NSLog的短板——但前辈是大家得有足够的时间和精力投入其中。下面来看这两款个人推荐:
- Cocoa LumberJack –一款专为Cocoa打造的知名通用型日志框架,学习起来略困难但功能非常强大。
- SNLog –NSLog的替换方案之一。
本文介绍了如何在iOS开发中自定义log宏,并在release版本禁止NSLog输出,以保护敏感信息。通过在-Prefix.pch文件中设置DEBUG宏,实现了在Debug模式下使用自定义的DMLog,而在Release模式下不输出日志。同时,讨论了NSLog的局限性,如不能本地输出、无法添加日志等级以及影响性能,推荐了两个替代框架Cocoa LumberJack和SNLog。

2714

被折叠的 条评论
为什么被折叠?



