Regelmäßige Verfolgungsmethoden von iOS Crash und detaillierte Anwendung von Bugly

Gewöhnliche Verfolgungsmethoden für iOS-Crashes und die Integration von Bugly

Wenn das App abstürzt, kann man im Entwicklungsstadium in der Regel auf die folgenden Weise die Crash-Informationen verfolgen

#1.Simulator ausführen, Fehlerprotokoll von Xcode anzeigen

#2。真机调试，查看Xcode错误日志

#3.Echtgerät ausführen, Protokoll der Gerätezeit anzeigen

　Hier wird ein Beispiel gegeben, schreiben Sie ein Stück Code, das zusammenbricht: crashdemo:

- (void)viewDidLoad {
  [super viewDidLoad];
  // Erstellen Sie zusätzliche Einstellungen nach dem Laden der Ansicht, typischerweise aus einem nib
  [self performSelector:@selector(print) withObject:nil afterDelay:5];
}
- (void)print {
  NSArray *array = @[];
  NSLog(@"%@", array[1]);
}

Demo#1.Simulator ausführen, Fehlerprotokoll von Xcode anzeigen

Das Programm kracht sofort zusammen, öffnen Sie die Protokollierung der Systemzeit von Xcode, um die folgenden Fehlerinformationen anzuzeigen

2016-10-29 12:13:29.015 CrashDemo[37842:7436441] *** 终止应用程序，由于未捕获的异常'NSRangeException'，原因：'*** -[__NSArray0 objectAtIndex:]: 索引 1 超出空NSArray的界限
*** 第一次抛出调用堆栈：
(
  0  CoreFoundation           0x00b7ba84 __exceptionPreprocess + 180
  1  libobjc.A.dylib           0x00642e02 objc_exception_throw + 50
  2  CoreFoundation           0x00b22390 __CFArrayGetTypeID_block_invoke + 0
  3  CoreFoundation           0x00ac07f8 -[NSArray objectAtIndexedSubscript:] + 40
  4  CrashDemo              0x000877b7 -[ViewController print] + 87
  5  Foundation             0x00250d71 __NSFireDelayedPerform + 442
  6  CoreFoundation           0x00acd576 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 22
  7  CoreFoundation           0x00accf72 __CFRunLoopDoTimer + 1250
  8  CoreFoundation           0x00a8b25a __CFRunLoopRun + 2202
  9  CoreFoundation           0x00a8a706 CFRunLoopRunSpecific + 470
  10 CoreFoundation           0x00a8a51b CFRunLoopRunInMode + 123
  11 GraphicsServices          0x041e4664 GSEventRunModal + 192
  12 GraphicsServices          0x041e44a1 GSEventRun + 104
  13 UIKit                0x00f0c1eb UIApplicationMain + 160
  14 CrashDemo              0x00087bba main + 138
  15 libdyld.dylib            0x03189a21 start + 1
)
libc++abi.dylib: 终止时未捕获异常类型为NSException
(lldb)

通过Xcode日志可以看到是数组访问越界，发生越界的方式名为print

针对这个demo我们当然很清楚是刚才列的array[1]发生越界，但对于一个完整的程序如何查看是在哪个地方发生越界的呢？63;

这个时候我们可以利用Xcode的显示断点导航器功能，点击加号选择添加异常断点

这个时候我们在执行程序，Xcode执行会自动停在要发生崩溃的代码段

Demo#2。真机调试，查看Xcode错误日志
如果有添加异常点，程序会自动停在打印array[1]那一行。如果没有添加，则程序会崩溃，Xcode会出现以下错误日志

2016-10-29 12:15:53.561 CrashDemo[1062:316582] *** 终止应用程序，由于未捕获的异常'NSRangeException'，原因：'*** -[__NSArray0 objectAtIndex:]: 索引 1 超出空NSArray的界限
*** 第一次抛出调用堆栈：
(0x211b398b 0x2094ee17 0x211433e7 0xc5a3b 0x219d1ad5 0x211765ff 0x21176231 0x2117407d 0x210c32e9 0x210c30d5 0x226b3ac9 0x257880b9 0xc5c99 0x20d6b873)
libc++abi.dylib: 终止时未捕获异常类型为NSException
(lldb)

通过错误信息我们只能看到发生了数组访问越界，如果有添加异常断点则会自动停在发生错误的代码行。

　Demo#3。在真机上运行，查看设备系统日志

Xcode停止运行此crashdemo，选择Xcode窗口 - Geräte, wählen Sie das Telefon aus - Betrachten Sie die device logs

Dann führen Sie crashdemo auf dem Telefon aus, sortieren Sie die neuesten Protokolle im device logs nach Zeit, um das crashdemo crash log zu sehen

Incident Identifier: 9A4C52F0-B0D7-42C9-A7CB-D4D3321D00D5
CrashReporter Key:  90f4d3621773443794fa73f506fd6bdef49fc269
Hardware Model:   iPhone4,1
Process:       CrashDemo [1074]
Path:        /private/var/containers/Bundle/Application/1307034E-9C2B-451F-ACD9-04C97DEC047B/CrashDemo.app/CrashDemo
Identifier:     PEGA.CrashDemo
Version:       1 (1.0)
Code Type:      ARM (Native)
Parent Process:   launchd [1]
Date/Time:      2016-10-29 12:21:49.49 +0800
Launch Time:     2016-10-29 12:21:43.43 +0800
OS Version:     iOS 9.3.1 (13E238)
Report Version:   104
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Triggered by Thread: 0
Filtered syslog:
None found
Last Exception Backtrace:
0  CoreFoundation          0x211b3986 __exceptionPreprocess + 122
1  libobjc.A.dylib          0x2094ee12 objc_exception_throw + 34
2  CoreFoundation          0x211433e2 -[__NSArray0 objectAtIndex:] + 110
3  CrashDemo             0x000e6a36 0xe0000 + 27190
4  Foundation            0x219d1ad0 __NSFireDelayedPerform + 464
5  CoreFoundation          0x211765fa

这些在开发阶段都能很简便的实现，但是当app发布出去后用户发生crash呢? 一般用户只能反馈在做什么的时候发生crash

然后我们在去做尝试是否能遇到，不过这样效率不高而且一般很难复现到用户的crash

Bugly的出现解决的这个问题

Bugly SDK在当程序崩溃时，会自动将错误信息发送到服务器方便开发人员查看分析

那么如何使用Bugly?

首先先到https://bugly.qq.com/v2/注册账号，并注册app下载SDK包

将Bugly.framework拖拽到工程中，记得勾选copy if needed.

然后添加libz.tbd / libstdc++.tbd / Security.framework / SystemConfiguration.framework到工程中

delegate.m中注册

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { 
    [Bugly startWithAppId:@"此处替换为你的AppId"]; 
    return YES; 
 }

这样当程序发生崩溃时，崩溃信息会自动发送到服务器登录你的bugly账号就能查看到了

　感谢阅读，希望能帮助到大家，谢谢大家对本站的支持！

Grund教程