-
导致Crash的原因
- 这个一般在开发阶段就可以检测出来, 所以导致crash几率较低
- 应用违反了操作系统原则, 如当App在切换AppDelegate的各种状态时响应超时, 有可能被系统终止应用(唤醒超时)
- 应用中一些bug: 如空数组, 调用未识别的方法, 阻塞主线程时间过长等等
-
获取Crash日志
- 当iOS应用程序崩溃的时候, 系统会自动创建一份crash日志保存在设备上, crash日志记录了App崩溃时的信息
- 在调试的时候, 可以通过
Xcode -> Window -> Device
来导出你的崩溃日志 - 对于已经发布的App, 一般都是通过一些第三方推送来获取Crash日志, 如友盟
- 需要在后台监控上面查看, 然后使用错误分析工具来查看错误
- 也可以在iTunes Connect上面, 找到你已经发布的程序, 获取崩溃日志
-
Crash日志的简单介绍
Incident Identifier: 7B5C3D72-9A8B-4D57-BF03-3A518FF215DF CrashReporter Key: 84b7b4f09b56ab3172449e05efa31985611bbd73 Hardware Model: iPhone7,1 Process: QQ [29482] Path: /private/var/mobile/Containers/Bundle/Application/2E7374FD-B9A6-4915-B149-2707F3439152/QQ.app/QQ Identifier: com.tencent.mqq Version: 6.2.3.409 (6.2.3) Code Type: ARM-64 (Native) Parent Process: launchd [1] Date/Time: 2016-06-15 17:27:43.830 +0800 Launch Time: 2016-06-15 17:27:30.873 +0800 OS Version: iOS 8.3 (12F70) Report Version: 105 Exception Type: EXC_RESOURCE Exception Subtype: WAKEUPS Exception Message: (Limit 150/sec) Observed 3531/sec over 300 secs Triggered by Thread: 6 Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0: 0 libsystem_kernel.dylib 0x0000000196318e0c mach_msg_trap + 8 1 libsystem_kernel.dylib 0x0000000196318c84 mach_msg + 68 2 CoreFoundation 0x0000000184327720 __CFRunLoopServiceMachPort + 196 3 CoreFoundation 0x0000000184325674 __CFRunLoopRun + 936 4 CoreFoundation 0x00000001842512d0 CFRunLoopRunSpecific + 392 5 GraphicsServices 0x000000018da676f8 GSEventRunModal + 164 6 UIKit 0x0000000188e16fa8 UIApplicationMain + 1484 7 QQ 0x000000010090f600 0x1000dc000 + 8599040 8 libdyld.dylib 0x000000019621aa04 start + 0
- 这是刚刚找到的QQ的crash日志, 从上面看来基本上可以分成四部分
- 崩溃的程序, 以及一些主机信息
- 崩溃的事件, 当前系统的版本
- 崩溃的异常类型, 信息以及出问题的线程
- 崩溃前, 各个线程的详细信息
- 首先来解释一下上述崩溃的问题
- 我们可以看到在第三部分, 有各种
Exception
异常信息以及出情况的线程, 通常这就是导致崩溃的问题所在 - 但是只有异常类型, 以及一些模糊的信息, 我们并不能准确的断定到底异常发生在哪, 所以一般就需要你去
StackOverFlow
中查看 - 关于这个问题: 你可以看到
Exception Message: (Limit 150/sec) Observed 3531/sec over 300 secs
是由于这个错误引起的, 由于这个是由QQ引起的崩溃, 我只能在StackOverFlow
上面查看, 得到的结果是: 这个问题是由于在唤醒App线程中调用的方法次数过多导致的崩溃, 在iOS唤醒App的时候, 会有严格的控制方法调用的次数, 如果超过这个次数, 就会引发crash
- 我们可以看到在第三部分, 有各种
- 一般解决crash的方法
- 在线程中, 你可以看到线程正在调用的方法, 但是他们都统一被转化为十六进制和地址, 这被称为符号化, 这样我们就无法获知到底出现了什么错误
- Xcode符号化崩溃日志时,需要访问与App Store上对应的应用二进制文件以及生成二进制文件时产生的 .dSYM 文件
- 所以,保留每个分发给用户的编译版本非常重要。提交应用前进行归档时,Xcode将保存应用的二进制文件。可以在Xcode Organizer的Archives标签栏下找到所有已归档的应用文件。
- 这是刚刚找到的QQ的crash日志, 从上面看来基本上可以分成四部分
网友评论