遇到iOS Crash,该如何分析?

一、背景说明

众所周知,Android App在机型兼容覆盖上面临非常大的挑战,一个根本原因就是由于Android生态的开放性,市场上充斥着数量巨大的各类Android设备,无法在浩如烟海的机型上做适配。

反观iOS生态,尽管整体上iOS App质量明显优于Android应用,但是从阿里云测移动质量中心的统计数据来看,依然有30%左右的iOS App存在崩溃、运行卡顿等严峻问题。iOS开发者依然需要花大力气通过各种测试手段发现这些隐藏问题,并逐一进行修复。

本文从解决iOS App崩溃的角度出发,分析了一份标准的iOS应用程序的Crash报告,iOS开发者可以通过这边文章掌握基本的崩溃分析方法。

二、如何分析iOS Crash

      一份标准的iOS应用程序的Crash报告,通常由以下6个部分组成:

      1. 报告头(Header)

报告头包含了应用程序以其运行环境的一些基本信息,下面是报告头的一个例子。

Incident Identifier: E6EBC860-0222-4B82-BF7A-2B1C26BE1E85
CrashReporter Key: 6196484647b3431a9bc2833c19422539549f3dbe
Hardware Model: iPhone6,1
Process: TheElements [4637]
Path: /private/var/mobile/Containers/Bundle/Application/5A9E4FC2-D03B-4E19-9A91-104A0D0C1D44/TheElements.app/TheElements
Identifier: com.example.apple-samplecode.TheElements
Version: 1.12
Code Type: ARM (Native)
Parent Process: launchd [1]
 
Date/Time: 2015-04-06 09:14:08.775 -0700
Launch Time: 2015-04-06 09:14:08.597 -0700
OS Version: iOS 8.1.3 (12B466)
Report Version: 105

 

       2. 异常代码(Exception Codes)

异常代码可能包含异常类型(Exception Type)、异常子类型(Exception Subtype)、处理器的详细异常代码(processor-specific Exception Codes)和其它能提供更多Crash信息的字段,最后一个字段列出了触发Crash的线程索引。下面是异常代码的示例。

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Triggered by Thread: 0

常见的异常类型有以下几种。

 

        a. Bad Memory Access [EXC_BAD_ACCESS // SIGSEGV // SIGBUS]

    此类型的Excpetion是最常见的Crash,通常由访问了无效的内存导致。

    SIGSEGV:访问了无效地址,没有物理内存对应该地址,通常由于重复释放对象导致。

    SIGBUS:总线错误,与 SIGSEGV 不同的是,SIGBUS 访问的是有效地址,但总线访问异常,通常是访问了未对齐的数据。

    SEGV:代表无效内存地址,比如空指针、未初始化指针、栈溢出等。

 

        b. Abnormal Exit [EXC_CRASH // SIGABRT]

     进程异常退出,造成Crash通常是因为未捕获到Objective-C/C++的异常。

     SIGABRT:收到Abort信号退出,通常Foundation库中的容器为了保护状态正常会做一些检测,例如插入nil到数组中等会遇到此类错误。

 

         c. 其它异常类型

     有些异常类型没有被命名,以16进制数字表示。

     0xbaaaaaad:意味着该Crash log并非一个真正的Crash,它仅仅只是包含了整个系统某一时刻的运行状态,由用户同时按Home键和音量键触发。

     0xbad22222:当VoIP程序在后台太过频繁的激活时,系统可能会终止此类程序。

     0x8badf00d:程序启动或者恢复时间过长被watch dog终止。

     0xc00010ff:程序执行大量耗费CPU和GPU的运算,导致设备过热,触发系统过热保护被系统终止。

     0xdead10cc:程序退到后台时还占用系统资源(如通讯录)被系统终止。

     0xdeadfa11:程序无响应用户强制退出。当用户长按电源键,直到屏幕出现关机确认画面后再长按Home键,将强制退出应用。我们可以合理认为用户这么做的原因是应用程序没有响应。

 

       3. 应用详情(Application Specific Information)

有些Crash出现时,会产生额外的信息,这些信息能帮助用户更好地了解应用程序终止时的运行环境。示例如下。

Application Specific Information:
MyApp[134] was suspended with locked system files:
/private/var/mobile/Library/AddressBook/AddressBook.sqlitedb

 

       4. 回溯(Backtrace)

这部分列出了发生Crash时线程的调用栈。示例如下。

Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   TheElements               0x0000000100063fdc -[AtomicElementViewController myTransitionDidStop:finished:context:] (AtomicElementViewController.m:201)
1   UIKit                     0x000000018ca5c2ec -[UIViewAnimationState sendDelegateAnimationDidStop:finished:] + 184
2   UIKit                     0x000000018ca5c1f4 -[UIViewAnimationState animationDidStop:finished:] + 100
3   QuartzCore                0x000000018c380f60 CA::Layer::run_animation_callbacks(void*) + 292
4   libdispatch.dylib         0x0000000198fb9368 _dispatch_client_callout + 12
5   libdispatch.dylib         0x0000000198fbd97c _dispatch_main_queue_callback_4CF + 928
6   CoreFoundation            0x000000018822dfa0 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 8
7   CoreFoundation            0x000000018822c048 __CFRunLoopRun + 1488
8   CoreFoundation            0x00000001881590a0 CFRunLoopRunSpecific + 392
9   GraphicsServices          0x00000001912fb5a0 GSEventRunModal + 164
10  UIKit                     0x000000018ca8aaa0 UIApplicationMain + 1484
11  TheElements               0x000000010005d800 main (main.m:55)
12  libdyld.dylib             0x0000000198fe2a04 start + 0
 
Thread 1 name: Dispatch queue: com.apple.libdispatch-manager
Thread 1:
0   libsystem_kernel.dylib    0x00000001990e0c94 kevent64 + 8
1   libdispatch.dylib         0x0000000198fc897c _dispatch_mgr_invoke + 272
2   libdispatch.dylib         0x0000000198fbb3b0 _dispatch_mgr_thread + 48
 
...

 

       5. 线程状态(Thread State)

这部分列出了发生Crash的线程的状态,即寄存器和寄存器的值。示例如下。

Thread 0 crashed with ARM Thread State (64-bit):
    x0: 0x0000000000000000   x1: 0x0000000000000000   x2: 0x0000000000000000   x3: 0x00000001995f8020
    x4: 0x0000000000000000   x5: 0x0000000000000001   x6: 0x0000000000000000   x7: 0x0000000000000000
    x8: 0x0000000000000000   x9: 0x0000000000000015  x10: 0x0000000199601df0  x11: 0x0000000b0000000f
   x12: 0x00000001741e8700  x13: 0x000001a5995f5779  x14: 0x0000000000000000  x15: 0x0000000044000000
   x16: 0x00000001989724d8  x17: 0x0000000188176370  x18: 0x0000000000000000  x19: 0x00000001701dda60
   x20: 0x0000000000000001  x21: 0x0000000136606e20  x22: 0x00000001000f6238  x23: 0x0000000000000000
   x24: 0x000000019cc640a8  x25: 0x0000000000000020  x26: 0x0000000000000000  x27: 0x0000000000000000
   x28: 0x000000019cc577c0  fp: 0x000000016fd1a8d0   lr: 0x00000001000effcc
    sp: 0x000000016fd1a860   pc: 0x00000001000effdc cpsr: 0x60000000

 

       6. 二进制映像(Binary Images)

这部分列出了当Crash发生时被装载进进程内存空间的依赖库或者模块。示例如下。

Binary Images:
0x100058000 - 0x10006bfff TheElements arm64 <77b672e2b9f53b0f95adbc4f68cb80d6> /var/mobile/Containers/Bundle/Application/CB86658C-

 

三、结合云上测试报告

       阿里云iOS自动化测试提供的检测报告里提供了详细的Crash日志,iOS开发者可以通过上面的Crash 分析方法快速定位到崩溃原因并加以解决。


       遇到iOS Crash,该如何分析?

 

       此外,检测报告里也包含了整个测试过程中的屏幕录像视频,对于崩溃发生的位置、时间都有记录。通过这个回溯视频,对于疑难bug的解决可以提供有效的定位依据,提高bug分析效率。


        遇到iOS Crash,该如何分析? 


       除iOS自动化测试外,阿里云移动服务还提供针对移动端的全面测试服务,包括Android 自动化测试、H5自动化测试。移动开发者可以点击前往体验试用。

上一篇:Project has no default.properties file! Edit the project properties to set one.错误解决方法


下一篇:Windows operation system 登录产生TEMP临时文件故障解决方法