IOS上objective-c开发调试方法

常用总结，陆续补充，免得忘记。

1.如果问题是可以复现的，用Breakpoint可以跟踪出错位置在进行分析

2.如果使用Breakpoint无法查出crash问题，问题无法复现，可以用profile记录运行过程中的内存，cpu使用，看是否在某一功能突然升高，不稳定。

3.可以通过将所有的NSLOG控制台输出截获到文件输出，在真机上运行来排查在模拟器上无法复现的问题。

在AppDelegate.m下增加方法

- (void) redirectConsoleLogToDocumentFolder {

    NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);

    NSString *documentsDirectory = [paths objectAtIndex:0];

    NSString *logPath = [documentsDirectory stringByAppendingPathComponent:@"NSLog2file.txt"];

    freopen([logPath cStringUsingEncoding:NSASCIIStringEncoding],"a+",stderr);

}

在程序applicationDidFinishLaunching下增加[selfredirectConsoleLogToDocumentFolder];调用。

查看log方法是将手机插入MAC,在xcode的Organize的devices下选择手机的application，可以在目录下找到文件。

4.在手机连入MAC后还可以在devices下看到 Device Logs，里面有所有的crash log，是系统记录的用于排查问题。

5.如果在模拟器遇到crash，实在无法解决，可以使用NSZombie来排查，看堆栈信息。 设置方法是在Xcode的product下的edit scheme中环境变量增加NSZombieEnabled YES, MallocStackLogging YES, MallocStackLoggingNoCompact YES

这样出问题时，可以在gdb下对crash的程序输入 info malloc-history 错误地址(比如:0x836fff0)或者shell pid序号 malloc_history

第一项可监控deallocated的内存，给更多的错误讯息

第二项可开启MallocStack，就知道内存在程式运行中被配置的历史

第三项可以更清楚显示指定的MallocStack状况