capture de journal de crash iOS, informations de débogage .. Récupérer et envoyer par courrier électronique à l'équipe de développement
Nous sommes récemment tombés sur une situation dans laquelle nous voulions voir les informations de débogage de l'application qu'un utilisateur a sur son appareil. Donc, ce que je recherche, c'est un moyen de trouver le journal sur le périphérique, de le coller sous forme de texte en ligne sur un courrier et de permettre à l'utilisateur de l'envoyer.
Des idées? Voici à nouveau les questions ... 1) Recherchez un journal de débogage sur le périphérique. 2) ouvrez le fichier et joignez le contenu du fichier sous forme de texte en ligne au courrier .. 3 pour l'envoyer par courriel la prochaine fois que l'application sera lancée ..
Merci,
Merci pour toutes les contributions les gars .. Je clubte vos solutions dans une solution qui résoudrait mon problème .. Voici ce que je l'ai fait pour être .. Sûrement je n'ai pas compilé le code, c'est un code à moitié cuit .. repasser rapidement une fois que je l'implémente dans mon code ..
NSLog dans le fichier Comment NSLog dans un fichier LOG2FILE
#if TARGET_IPHONE_SIMULATOR == 0
NSArray *paths =
NSSearchPathForDirectoriesInDomains(NSDocumentDirectory,NSUserDomainMask, YES);
NSString *documentsDirectory = [paths objectAtIndex:0];
NSString *logPath = [documentsDirectory stringByAppendingPathComponent:@"console.log"];
freopen([logPath cStringUsingEncoding:NSASCIIStringEncoding],"a+",stderr);
#endif
Catch the Crash et les connecter aussi dans un fichier
Tout d’abord, créez une fonction qui gérera l’erreur et la transmettra à la console (ainsi que tout ce que vous voulez faire avec):
void uncaughtExceptionHandler(NSException *exception) {
NSLog(@"CRASH: %@", exception);
NSLog(@"Stack Trace: %@", [exception callStackSymbols]);
// Internal error reporting
}
Ensuite, ajoutez le gestionnaire d'exceptions à votre délégué d'application:
-(BOOL)application:(UIApplication*)application didFinishLaunchingWithOptions:
(NSDictionary*)launchOptions
{
NSSetUncaughtExceptionHandler(&uncaughtExceptionHandler); // Normal launch stuff
}
Définit une variable dans le fichier info.plist appelée Crashed, puis la lit/écrit de cette façon
- (void)readPlist
{
NSString *localizedPath = [[NSBundle mainBundle] pathForResource:fileName ofType:@"plist"];
NSMutableDictionary* plistDict = [[NSMutableDictionary alloc] initWithContentsOfFile:localizedPath];
NSString *crashed;
crashed = [plistDict objectForKey:@"Crashed"];
}
- (void)writeToPlist
{
NSMutableDictionary* plistDict = [[NSMutableDictionary alloc] initWithContentsOfFile:filePath];
[plistDict setValue:@"YES" forKey:@"Crashed"];
[plistDict writeToFile:filePath atomically: YES];
}
Une fois l'application lancée, lisez le fichier info.plist et demandez à l'utilisateur de soumettre les journaux d'incidents.
{
MFMailComposeViewController *mailComposer = [[MFMailComposeViewController alloc] init];
mailComposer.mailComposeDelegate = self;[mailComposer setSubject:@"Crash Log"];
// Set up recipients
NSArray *toRecipients = [NSArray arrayWithObject:@"[email protected]"];
[mailComposer setToRecipients:toRecipients];
// Attach the Crash Log..
NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
NSString *documentsDirectory = [paths objectAtIndex:0];
NSString *logPath = [documentsDirectory stringByAppendingPathComponent:@"console.log"];
NSData *myData = [NSData dataWithContentsOfFile:logPath];
[mailComposer addAttachmentData:myData mimeType:@"Text/XML" fileName:@"Console.log"];
// Fill out the email body text
NSString *emailBody = @"Crash Log";
[mailComposer setMessageBody:emailBody isHTML:NO];
[self presentModalViewController:mailComposer animated:YES];
}
Pour consigner vos propres données, utilisez Cocoalumberjack . Il est beaucoup plus rapide que NSLog et peut être activé/désactivé dynamiquement. Il fournit également des options pour enregistrer les données dans un fichier. NSLog ralentira votre application et remplira le journal de la console. Aussi, vous ne voulez pas vous connecter trop en général. Vous ne pouvez pas vous connecter en toute sécurité lorsque le crash se produit. Donc, une fois que vous avez déterminé où se situe le problème, ajoutez-y un peu plus de journalisation et essayez de le reproduire, par exemple. en utilisant des frameworks de tests automatisés comme KIF .
Pour attraper un rapport d'incident, vous ne devriez rien d'autre qu'une solution basée sur le framework open source PLCrashReporter , qui peut safe intercepter des plantages, même lorsque votre application est déjà dans le magasin d'applications! Il n’est pas recommandé de capturer des exceptions comme suggéré par d’autres. Vérifiez cet article pour savoir pourquoi!
iTunes Connect vous offre également la possibilité d'afficher certains rapports d'erreur, mais cela peut prendre jusqu'à deux semaines, mais de loin pas tous comme par exemple. signalé par les développeurs Camera + . Donc, vous feriez mieux d'utiliser votre propre solution.
PLCrashReporter vous enverra des rapports d’incidents standard au format Apple, prêts à être symbolisés, afin que vous sachiez où l’incident se produit dans votre code, y compris les numéros de ligne.
Certaines solutions basées sur PLCrashReporter sont:
- QuincyKit : Client Open Source + serveur php, groupage de base des accidents, la symbolisation peut être automatisée à partir de votre mac (je suis le développeur de cela)
- HockeyApp : Service payant, utilise le client QuincyKit, groupage avancé d'accidents, symbolication entièrement effectuée sur le serveur (je suis l'un des développeurs de ce logiciel)
- Bugsense : Service gratuit, pas de symbolique
- AppBlade : service GRATUIT si utilisé avec 25 appareils ou moins, aucune symbolisation
- Crashlytics : Bêta privée, fonctionnalités inconnues, leur solution semble être basée sur PLCrashReporter
Les solutions proposées permettent soit d’envoyer automatiquement les données au prochain démarrage, soit en demandant à l’utilisateur s’il accepte de l’envoyer.
Pour la journalisation et l'analyse sous Swift, vous pouvez utiliser SwiftyBeaver. Il s'agit d'une plate-forme de journalisation complète comprenant un framework open source Swift 2 & Objective-C Framework, un stockage cloud chiffré et une application Mac.
Site Web: https://swiftybeaver.com
Cadre (supportant): https://github.com/SwiftyBeaver/SwiftyBeaver
Disclaimer: Je suis un fondateur.
C'est une solution qui intercepte les plantages au fur et à mesure, elle donnera plus d'informations de code lisibles par l'homme qu'un journal des crashs. Il manquera une partie du journal des accidents, mais comme le dit Till, vous devriez pouvoir y accéder de toute façon.
Une autre SO question sur le Xcode 4.2 revenant toujours à main après un crash. La réponse ici utilise cette méthode et vous pouvez l’étendre pour garder une trace des accidents.
implémenter votre propre gestionnaire d'exceptions dans AppDelegate
// on load
NSSetUncaughtExceptionHandler(&uncaughtExceptionHandler);
void uncaughtExceptionHandler(NSException *exception) {
NSLog(@"CRASH: %@", exception);
NSLog(@"Stack Trace: %@", [exception callStackSymbols]);
// Internal error reporting
}
UPDATE J’ai fait quelques retours en arrière et cette solution a été proposée par Zane Claes à la question Le débogage Xcode 4.2 ne symbolise pas l’appel de pile
Il propose une solution générale dans son deuxième commentaire. "Je trouve qu'il est utile d'écrire le journal des incidents dans un fichier et de demander à l'utilisateur de le soumettre lors du prochain lancement (en mode édition uniquement, pour ne pas entraver le débogage). Cela me permet d'obtenir d'excellents rapports de bogues. .. et les utilisateurs savent que leur problème est en cours de résolution "Je comprends que tout le monde ne voudrait pas poser cette question à l'utilisateur, mais il existe des super-utilisateurs qui seraient ravis de pouvoir vous aider.
Vous pouvez bien sûr inclure un bouton Ne plus afficher ce bouton Inviter à nouveau pour que les personnes ne soient pas frustrées par le mécanisme de rapport.
Alternativement, Vous pouvez contacter un serveur avec les informations (vous ne savez pas si cela fonctionnera comme il se bloque, mais enregistrez-le et essayez occasionnellement de POST sur un serveur avec les détails)
J'ai utilisé Crittercism pour automatiser cela pour moi. Fonctionne pour les tests et la production aussi.
BugSense fournit des services de signalement des incidents pour iOS. En plus de fournir une trace de pile entièrement symbolique, BugSense fournit des analyses pour vos accidents, dans toutes vos applications.
Je pense que c'est mieux que l'e-mail, car lorsque votre application deviendra populaire, vous devrez gérer tous ces e-mails manuellement, alors que BugSense le fait automatiquement. Toutefois, BugSense étant également à code source ouvert, vous pouvez modifier ses composants internes comme vous le souhaitez et ajouter des fonctionnalités supplémentaires.
En plus de cela, vous nous faites travailler gratuitement pour vous: si vous avez une idée d'une nouvelle fonctionnalité intéressante que vous souhaitez, nous le ferons - à condition que nous pensions que c'est aussi cool.
Avertissement: J'écris le code pour BugSense-iOS.framework.
J'ai utilisé le code ci-dessous pour attraper les journaux de débogage - Swift 4.1
var paths = NSSearchPathForDirectoriesInDomains(.documentDirectory, .userDomainMask, true)
let documentsDirectory = paths[0]
let fileName = "Logfile.txt"
let logFilePath = (documentsDirectory as NSString).appendingPathComponent(fileName)
freopen(logFilePath.cString(using: String.Encoding.ascii)!, "a+", stderr)
Si vous utilisez TestFlight avec leur SDK, cela est automatisé. C'est un très bon système. Pour les versions de test uniquement, cependant.
Voir la réponse de Ryan dans Comment afficher l'instruction NSLog à partir du fichier iphone .app pour un utilitaire gratuit fourni par Apple.
Mais ce n’est toujours pas une solution commode. Si vous pouvez vous permettre une nouvelle construction, vous devriez modifier votre journalisation dans l'application. Jano a de très bonnes idées à ce sujet dans Comment NSLog dans un fichier . Surtout l'option 2 devrait faire sans trop d'effort.
En général, je vous conseillerais de masquer les fonctions de journalisation natives derrière une façade ou une conception similaire au tout début du projet, quel que soit le langage de programmation utilisé.