English | 简体中文 | 繁體中文 | Русский язык | Français | Español | Português | Deutsch | 日本語 | 한국어 | Italiano | بالعربية
Méthodes de suivi habituelles des crashes iOS et intégration de Bugly
Lorsqu'une application plante, pendant la phase de développement, il est généralement possible de suivre les informations de plantage de la manière suivante
#1.Lancez le simulateur et regardez le journal d'erreur de Xcode
#2. Débogage sur appareil réel, consultez les journaux d'erreur xcode
#3.Lancez le appareil et regardez le journal système de l'appareil
Voici un exemple pour illustrer, écrivons d'abord un code qui va planter crashdemo:
- (void)viewDidLoad {
[super viewDidLoad];
// Faites toute autre configuration après le chargement de la vue, généralement à partir d'un nib.
5]
}
- (void)print {
NSArray *array = @[];
1]
}
Demo#1.Lancez le simulateur et regardez le journal d'erreur de Xcode
Le programme s'effondrera immédiatement après l'exécution, vous pouvez voir les informations d'erreur suivantes en ouvrant le journal système de Xcode
2016-10-29 12:13:29.015 CrashDemo[37842:7436441] *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[__NSArray0 objectAtIndex:]: index 1 beyond bounds for empty NSArray' *** First throw call stack: ( 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: arrêt avec une exception non capturée de type NSException (lldb)
En regardant les journaux xcode, nous pouvons voir que l'accès aux éléments du tableau dépasse ses limites, le mode de dépassement des limites s'appelle print
Pour ce demo, nous sommes bien sûr conscients que c'est juste array[1]Dépassement des limites, mais pour un programme complet, comment voir où le dépassement des limites se produit ?63;
Lors de cette étape, nous pouvons utiliser la fonction Show the breakpoint navigator de xcode, cliquer sur le signe + pour ajouter un point d'arrêt d'exception
Lorsque nous exécutons le programme à ce moment-là, xcode s'arrêtera automatiquement à la section de code où le crash se produira
Demo#2. Débogage sur appareil réel, consultez les journaux d'erreur xcode
Si un point d'exception a été ajouté, le programme s'arrêtera automatiquement à l'endroit où array[1]Cette ligne. Si elle n'a pas été ajoutée, le programme se brisera, xcode affichera les journaux d'erreur suivants
2016-10-29 12:15:53.561 CrashDemo[1062:316582] *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[__NSArray0 objectAtIndex:]: index 1 beyond bounds for empty NSArray' *** First throw call stack: (0x211b398b 0x2094ee17 0x211433e7 0xc5a3b 0x219d1ad5 0x211765ff 0x21176231 0x2117407d 0x210c32e9 0x210c30d5 0x226b3ac9 0x257880b9 0xc5c99 0x20d6b873) libc++abi.dylib: arrêt avec une exception non capturée de type NSException (lldb)
À partir des informations d'erreur, nous ne pouvons voir que l'accès aux éléments d'un tableau dépasse ses limites, si un point d'arrêt d'exception a été ajouté, le programme s'arrêtera automatiquement à la ligne de code où l'erreur se produit.
Demo#3. Exécution sur appareil réel, consultez les journaux système de l'appareil
xcode arrête d'exécuter ce crashdemo, sélectionnez la fenêtre xcode - devices, sélectionnez le téléphone - visualiser les logs device
Ensuite, exécutez crashdemo sur le téléphone, puis regardez les logs device les plus récents en les triant par date pour voir les logs de crash de crashdemo
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
Ces éléments peuvent être réalisés de manière simple pendant la phase de développement, mais que faire lorsque l'application est publiée et que les utilisateurs rencontrent des crashes ?63; Les utilisateurs ne peuvent généralement que signaler un crash lorsqu'ils font quelque chose
Ensuite, nous essayons de voir si nous pouvons le rencontrer, mais cela est inefficace et généralement difficile à reproduire un crash utilisateur
Bugly résout ce problème
Le SDK Bugly enverra automatiquement les informations d'erreur au serveur lorsque le programme plante, ce qui facilite la visualisation et l'analyse des développeurs.
Alors, comment utiliser Bugly?
Allez d'abord à https://bugly.qq.com/v2/Enregistrez un compte, puis enregistrez l'application et téléchargez le SDK
Déplacez Bugly.framework dans le projet, n'oubliez pas de cocher copy if needed.
ensuite, ajoutez libz.tbd / libstdc++.tbd / Security.framework / ajout de SystemConfiguration.framework au projet
enregistrement dans delegate.m
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
[Bugly startWithAppId:@"remplacez par votre AppId ici"];
return YES;
}
De cette manière, lorsque le programme plante, les informations de plantage sont automatiquement envoyées au serveur, vous pouvez les consulter en vous connectant à votre compte bugly.
Merci de votre lecture, j'espère que cela peut vous aider, merci de votre soutien à notre site !