iOS_异常堆栈报告分析

在使用 Xcode 工具的开发过程中, 面对运行异常, 很多初学者往往毫无头绪, 不知道如何跟踪异常堆栈, 如何分析异常堆栈报告. 这里就给大家介绍如何<b>跟踪异常堆栈</b>和<b>分析堆栈报告</b>.
<h4>1>跟踪异常堆栈</h4>
默认情况下, 使用 Xcode 工具进行开发时, 产生异常时会有信息输出, 也会有异常堆栈输出, 不过它们都是晦涩难懂的内存地址, 我们需要单独添加程序代码来处理这些程序.

<b>这里自己写了一个运行期异常:</b>

这是点击某个按钮要执行的操作.

 [self performSelector:@selector(testAction) withObject:nil afterDelay:0];

这里这个 testAction 方法是不存在的.当这个按钮监听到用户的点击事件以后, 程序运行到这里就会抛出异常.
默认情况下,运行产生异常时,输出到输出窗口的内容如下:

    @try{
        @autoreleasepool {
            return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
        }
    }@catch (NSException *exception){
        
        YYLLog(@"Stack Trace :  %@", [exception callStackSymbols]);
    }

我们知道, main.m 是程序的逻辑入口点.事实上, 所有的异常最后都要抛到这里,如果这里不处理,就会由系统采用默认的处理方式.
我们在进行异常捕获,然后处理输出异常堆栈信息, 其中的exception是异常对象,callStackSymbols方法可以处理异常堆栈.再次运行程序,输出窗口的代码如下:

**2016-08-22 11:52:45.720 htIphone[2386:1947628] -[HTNewOverseasPurchaseViewController testAction]: unrecognized selector sent to instance 0x7fed9bf24de0**
**2016-08-22 11:52:45.728 htIphone[2386:1947628] Stack Trace :  (**
** 0   CoreFoundation                      0x000000010ac9ad85 __exceptionPreprocess + 165,**
** 1   libobjc.A.dylib                     0x0000000109ecbdeb objc_exception_throw + 48,**
** 2   CoreFoundation                      0x000000010aca3d3d -[NSObject(NSObject) doesNotRecognizeSelector:] + 205,**
** 3   CoreFoundation                      0x000000010abe9cfa ___forwarding___ + 970,**
** 4   CoreFoundation                      0x000000010abe98a8 _CF_forwarding_prep_0 + 120,**
** 5   Foundation                          0x00000001076bf2c9 __NSFireDelayedPerform + 402,**
** 6   CoreFoundation                      0x000000010abf4074 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20,**
** 7   CoreFoundation                      0x000000010abf3c21 __CFRunLoopDoTimer + 1089,**
** 8   CoreFoundation                      0x000000010abb5b11 __CFRunLoopRun + 1937,**
** 9   CoreFoundation                      0x000000010abb50f8 CFRunLoopRunSpecific + 488,**
** 10  GraphicsServices                    0x000000010d510ad2 GSEventRunModal + 161,**
** 11  UIKit                               0x000000010894ff09 UIApplicationMain + 171,**
** 12  htIphone                            0x00000001065a71ce main + 142,**
** 13  libdyld.dylib                       0x000000010c12992d start + 1,**
**)**

这就是异常堆栈的信息了,这个内容比系统默认的信息要容易理解得多.

<h4>2>分析堆栈报告</h4>
这里来介绍一下如何分析堆栈报告, 它里面的内容是什么含义.
一条堆栈信息由5部分构成.见下图

Paste_Image.png

<b>第1部分</b>堆栈输出序号,序号越大表示越早被调用.
<b>第2部分</b>调用方法(或函数)所属的框架(或库),图中所示的 PresentationLayer 是我自己编写的表示层工程.
<b>第3部分</b>调用方法(或函数)的内存地址,这个信息对我们的帮助不是很大.
<b>第4部分</b>调用方法(或函数)名,这个信息对我们很重要.
<b>第5部分</b>调用方法(或函数)编译之后的代码偏移量,这个信息很多人误以为是行号,对我们基本没有什么帮助.

此外,堆栈信息是要从下往上看的, 程序运行的过程是从下面的方法(或函数)调用项目的方法(或函数).例如:下面的语句是htIphone中的 main 函数调用 UIKit 中的 UIApplicationMain方法:

** 11  UIKit                               0x000000010894ff09 UIApplicationMain + 171,**
** 12  htIphone                            0x00000001065a71ce main + 142,**

在程序运行过程中, 堆栈信息可能很长, 我们不需要每一行都去看, 只需关注我们自己的工程(或库)就可以了, 这是因为首先我们要假定别人提供给我们的框架(或库)是正确的, 先看自己的工程(或库)中的方法(或函数),找到那条调用语句看看是不是有问题.

这就是堆栈信息报告分析过程了, 当然是否能够找到问题, 还会因人而异, 有调试经验的人可能很快就能找出问题.