iOS应用崩溃日志

最新推荐文章于 2025-05-19 13:53:30 发布

原创最新推荐文章于 2025-05-19 13:53:30 发布 · 5.9k 阅读

3 ·

本内容遵循CC 4.0 BY-SA版权协议

标签

#iOS #应用崩溃日志分析

iOS 专栏收录该内容

8 篇文章

订阅专栏

本文详细介绍iOS应用崩溃日志的结构与解析方法，包括进程信息、基础信息、异常类型及常见崩溃类型等内容，帮助开发者快速定位并解决应用崩溃问题。

iOS设备上的应用闪退时，操作系统会生成一个崩溃报告，也叫崩溃日志，保存在设备上。

崩溃日志上有很多有用的信息，包括应用是什么情况下闪退的。通常，上面有每个正在执行线程的完整堆栈跟踪信息，所以你能从中了解到闪退发生时各线程都在做什么，并分辨出闪退发生在哪个线程上。通过这些文件你可以很快定位到问题发生的地方，设备和电脑上的iTuns同步后，日志会保存在电脑上，路径是： :~/Library/Logs/CrashReporter/MobileDevice/

苹果有很详细的文档和视频解析相关的日志文件：https://developer.apple.com/library/ios/technotes/tn2151/_index.html#//apple_ref/doc/uid/DTS40008184-CH1-INTRODUCTION，没时间看的可以看看此文参考，

1、Process Information(进程信息)：
Incident Identifier: 68F2D36F-CE19-4EA3-BD3D-AE4E1C6BD0D9
CrashReporter Key: 2e7155ae1d2136fd11ed342862eccf0b3d732dc2
Hardware Model: iPhone8,1
Process: newbaichuanzhongyun [12631]
Path: /private/var/mobile/Containers/Bundle/Application/4D97BE8F-0A36-47C2-81E0-BB03F4AEC322/newbaichuanzhongyun.app/newbaichuanzhongyun
Identifier: com.baichuanzhongyun.newmeimeiyichu
Version: 1 (1.0)
Code Type: ARM-64 (Native)
Parent Process: launchd [1]

Incident Idnetifier	崩溃报告的唯一标识符，不同的Crash
CrashReporter Key	设备标识相对应的唯一键值(并非真正的设备的UDID，苹果为了保护用户隐私iOS6以后已经无法获取)。通常同一个设备上同一版本的App发生Crash时，该值都是一样的。
Hardware Model	代表发生Crash的设备类型，上图中的“iPad4,4”代表iPad Air
Process	代表Crash的进程名称，通常都是我们的App的名字, []里面是当时进程的ID
Path	可执行程序在手机上的存储位置，注意路径时到XXX.app/XXX，XXX.app其实是作为一个Bundle的，真正的可执行文件其实是Bundle里面的XXX，感兴趣的可以自己查一下相关资料，有机会我后面也会介绍到
Identifier	你的App的Indentifier，通常为“com.xxx.yyy”，xxx代表你们公司的域名，yyy代表某一个App
Version	当前App的版本号，由Info.plist中的两个字段组成，`CFBundleShortVersionString` and `CFBundleVersion`
Code Type	当前App的CPU架构
Parent Process	当前进程的父进程，由于iOS中App通常都是单进程的，一般父进程都是launchd

2、Basic Information

Date/Time: 2016-03-28 18:24:37.37 +0800
Launch Time: 2016-03-28 18:24:28.28 +0800
OS Version: iOS 9.2.1 (13D15)
Report Version: 105

Date/Time	Crash发生的时间，可读的字符串
OS Version	系统版本，（）内的数字代表的时Bulid号
Report Version	Crash日志的格式，目前基本上都是104，不同的version里面包含的字段可能有不同

3、Exception（非常重要）

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

Exception Type	异常类型
Exception Subtype:	异常子类型
Crashed Thread	发生异常的线程号

通过崩溃的类型，你可以分析你可以具体确认是什么样的问题，基本能定位到大致的问题发生的位置

4、Thread Backtrace

Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x0000000180c88140 0x180c6c000 + 115008
1 libsystem_pthread.dylib 0x0000000180d50ef8 0x180d4c000 + 20216
2 libsystem_c.dylib 0x0000000180bf9dac 0x180b98000 + 400812
3 libc++abi.dylib 0x000000018072d3f4 0x18072c000 + 5108
4 libc++abi.dylib 0x0000000180749e98 0x18072c000 + 122520
5 libobjc.A.dylib 0x0000000180754248 0x18074c000 + 33352
6 libc++abi.dylib 0x0000000180746f44 0x18072c000 + 110404
7 libc++abi.dylib 0x0000000180746b10 0x18072c000 + 109328
8 libobjc.A.dylib 0x0000000180754120 0x18074c000 + 33056
9 CoreFoundation 0x0000000180fc9728 0x180fc0000 + 38696
10 GraphicsServices 0x00000001824d8088 0x1824cc000 + 49288
11 UIKit 0x0000000185e40d90 0x185dc4000 + 511376
12 newbaichuanzhongyun 0x000000010012b100 0x100094000 + 618752
13 libdyld.dylib 0x0000000180b6a8b8 0x180b68000 + 10424

发生Crash的线程的Crash调用栈，从上到下分别代表调用顺序，最上面的一个表示抛出异常的位置，依次往下可以看到API的调用顺序。

二、常见的Crash类型

1、Watchdog timeout

Exception Code：0x8badf00d，不太直观，可以读成“eat bad food”，意思是don‘t block main thread

紧接着下面会有一段描述：

Application Specific Information：

com.xxx.yyy　　 failed to resume in time

对于此类Crash，我们应该去审视自己App初始化时做的事情是否正确，是否在主线程请求了网络，或者其他耗时的事情卡住了正常初始化流程。

通常系统允许一个App从启动到可以相应用户事件的时间最多为5S，如果超过了5S，App就会被系统终止掉。在Launch，resume，suspend，quit时都会有相应的时间要求。在Highlight Thread里面我们可以看到被终止时调用到的位置，xxxAppDelegate加上行号。

PS. 在连接Xcode调试时为了便于调试，系统会暂时禁用掉Watchdog，所以此类问题的发现需要使用正常的启动模式

2、User force-quit

Exception Codes: 0xdeadfa11, deadfall