App Center-Abstürze (iOS)
Wichtig
Visual Studio App Center wird am 31. März 2025 eingestellt. Sie können Visual Studio App Center zwar weiterhin verwenden, bis es vollständig eingestellt ist, es gibt jedoch mehrere empfohlene Alternativen, zu denen Sie möglicherweise eine Migration in Erwägung ziehen.
App Center-Abstürze generiert automatisch ein Absturzprotokoll, wenn Ihre App abstürzt. Das Protokoll wird zuerst in den Speicher des Geräts geschrieben, und wenn der Benutzer die App erneut startet, wird der Absturzbericht an App Center gesendet. Das Sammeln von Abstürze funktioniert sowohl für Beta- als auch für Live-Apps, d. h. für solche, die an die App Store übermittelt werden. Absturzprotokolle enthalten wertvolle Informationen, die Sie bei der Behebung des Absturzes unterstützen.
Folgen Sie dem Abschnitt Erste Schritte, wenn Sie das SDK noch nicht in Ihrer Anwendung eingerichtet haben.
Außerdem erfordern Absturzprotokolle unter iOS Symbolik. Lesen Sie die App Center-Diagnosedokumentation , in der erläutert wird, wie Symbole für Ihre App bereitgestellt werden.
Hinweis
Das SDK leitet kein Absturzprotokoll weiter, wenn Sie an den Debugger angefügt sind. Stellen Sie sicher, dass der Debugger nicht angefügt ist, wenn Sie die App abstürzen.
Hinweis
Stellen Sie sicher, dass Bitcode deaktiviert ist, um ordnungsgemäß symbolische Stapelablaufverfolgungen zu erhalten. Weitere Informationen zu Bitcode finden Sie in der Dokumentation zur iOS-Symbolik von App Center.
Hinweis
In der 4.0.0
Version von App Center wurden breaking changes eingeführt. Folgen Sie dem Abschnitt Migrieren zu App Center SDK 4.0.0 und höher , um App Center von früheren Versionen zu migrieren.
App Center unterstützt Absturzberichte in iOS-Erweiterungen. Die Verwendung ist identisch mit der in der Containeranwendung.
App Center Crashes bietet Ihnen eine API zum Generieren eines Testabsturzes zum einfachen Testen des SDK. Diese API kann nur in Test-/Beta-Apps verwendet werden und wird in Produktions-Apps nicht ausgeführt.
[MSACCrashes generateTestCrash];
Crashes.generateTestCrash()
App Center Crashes verfügt über zwei APIs, die Ihnen weitere Informationen liefern, falls Ihre App abgestürzt ist.
Nach dem Starten des SDK können Sie jederzeit überprüfen, ob die App in der vorherigen Sitzung eine Speicherwarnung erhalten hat:
[MSACCrashes hasReceivedMemoryWarningInLastSession];
Crashes.hasReceivedMemoryWarningInLastSession
Hinweis
Diese Methode darf nur verwendet werden, nachdem Crashes
sie gestartet wurde, sie wird immer zurückgegeben NO
oder false
vor dem Start.
Hinweis
In einigen Fällen kann ein Gerät mit wenig Arbeitsspeicher keine Ereignisse senden.
Nach dem Starten des SDK können Sie jederzeit überprüfen, ob die App beim vorherigen Start abgestürzt ist:
[MSACCrashes hasCrashedInLastSession];
Crashes.hasCrashedInLastSession
Dies ist nützlich, wenn Sie das Verhalten oder die Benutzeroberfläche Ihrer App nach einem Absturz anpassen möchten.
Hinweis
Diese Methode darf nur verwendet werden, nachdem MSACCrashes
sie gestartet wurde, sie wird immer zurückgegeben NO
oder false
vor dem Start.
Wenn Ihre App zuvor abgestürzt ist, können Sie Details zum letzten Absturz abrufen.
MSACErrorReport *crashReport = [MSACCrashes lastSessionCrashReport];
var crashReport = Crashes.lastSessionCrashReport
Hinweis
Diese Methode darf erst nach dem Crashes
Start verwendet werden. Sie wird immer vor dem Start zurückgegeben nil
.
Es gibt zahlreiche Anwendungsfälle für diese API. Am häufigsten sind Benutzer, die diese API aufrufen und ihre benutzerdefinierten CrashesDelegate implementieren.
App Center Crashes bietet Rückrufe für Entwickler, um zusätzliche Aktionen vor und beim Senden von Absturzprotokollen an App Center auszuführen.
Um Ihr benutzerdefiniertes Verhalten hinzuzufügen, müssen Sie das CrashesDelegate
-Protokoll übernehmen. Alle zugehörigen Methoden sind optional.
[MSACCrashes setDelegate:self];
Crashes.delegate = self
Hinweis
Sie müssen den Delegat vor dem Aufrufen AppCenter.start
festlegen, da App Center die Verarbeitung sofort nach dem Start abstürzt.
Implementieren Sie die crashes:shouldProcessErrorReport:
-Methode in der Klasse, die das CrashesDelegate
-protokoll übernimmt, wenn Sie entscheiden möchten, ob ein bestimmter Absturz verarbeitet werden muss oder nicht. Beispielsweise kann es zu einem Absturz auf Systemebene kommen, den Sie ignorieren möchten und den Sie nicht an App Center senden möchten.
- (BOOL)crashes:(MSACCrashes *)crashes shouldProcessErrorReport:(MSACErrorReport *)errorReport {
return YES; // return YES if the crash report should be processed, otherwise NO.
}
func crashes(_ crashes: Crashes, shouldProcess errorReport: ErrorReport) -> Bool {
return true; // return true if the crash report should be processed, otherwise false.
}
App Center ermöglicht ihnen auch das Nachverfolgen von Fehlern mithilfe von verarbeiteten Ausnahmen über die trackError
-Methode. Eine App kann optional Eigenschaften oder/und Anlagen an einen behandelten Fehlerbericht anfügen, um weiteren Kontext bereitzustellen.
@try {
// Throw error.
} @catch (NSError *error) {
// Init attachments.
NSArray<MSACErrorAttachmentLog *> attachments = @[ MSACErrorAttachmentLog attachmentWithText:@"Hello world!" filename:@"hello.txt"] ]
// Init properties.
NSDictionary *properties = @{ "Category" : "Music", "Wifi" : "On" };
// Track errors.
[MSACCrashes trackError:error withProperties:properties attachments:attachments];
[MSACCrashes trackError:error withProperties:properties attachments:nil];
[MSACCrashes trackError:error withProperties:nil attachments:attachments];
[MSACCrashes trackError:error withProperties:nil attachments:nil];
}
do {
// Throw error.
} catch {
// Init attachments.
let attachments = [ErrorAttachmentLog.attachment(withText: "Hello world!", filename: "hello.txt")]
// Init properties.
let properties:Dictionary<String, String> = ["Category" : "Music", "Wifi" : "On"]
// Track errors.
Crashes.trackError(error, properties: properties, attachments: attachments)
Crashes.trackError(error, properties: properties, attachments: nil)
Crashes.trackError(error, properties: nil, attachments: attachments)
Crashes.trackError(error, properties: nil, attachments: nil)
}
Für Nachverfolgungsausnahmen können Sie die Methode verwenden trackException
:
@try {
// Throw exceptions.
} @catch (NSException *exception) {
// Init exceptions.
MSACExceptionModel *customException1 = [MSACExceptionModel initWithType:@"Custom exception" exceptionMessage:"Track custom exception.", stackTrace:exception.callStackSymbols];
MSACExceptionModel *customException2 = [MSACExceptionModel initWithException:exception];
// Track exceptions.
[MSACCrashes trackException:customException1 withProperties:properties attachments:nil];
[MSACCrashes trackException:customException2 withProperties:properties attachments:nil];
}
do {
// Throw exception.
} catch {
// Init exception.
let exception = ExceptionModel(withType: "Custom exception", exceptionMessage: "Track custom exception.", stackTrace: Thread.callStackSymbols)
// Track exception.
Crashes.trackException(exception, properties: properties, attachments: nil)
}
Wenn Ihnen der Datenschutz der Benutzer wichtig ist, sollten Sie eine Benutzerbestätigung erhalten, bevor Sie einen Absturzbericht an App Center senden. Das SDK macht einen Rückruf verfügbar, der App Center-Abstürze angibt, die Bestätigung des Benutzers abzuwarten, bevor Absturzberichte gesendet werden.
Wenn Sie sich dafür entschieden haben, sind Sie dafür verantwortlich, die Bestätigung des Benutzers abzurufen, z. B. über eine Dialogaufforderung mit einer der folgenden Optionen: Immer senden, senden und Nicht senden. Basierend auf der Eingabe teilen Sie App Center Abstürze mit, was zu tun ist, und der Absturz wird dann entsprechend behandelt.
Hinweis
Das SDK zeigt dafür kein Dialogfeld an. Die App muss eine eigene Benutzeroberfläche bereitstellen, um die Zustimmung des Benutzers einzuholen.
Hinweis
Die App sollte nicht explizit aufrufen notifyWithUserConfirmation
, wenn sie kein Benutzerbestätigungsdialogfeld implementiert. Das Modul Crashes verarbeitet implizit das Senden von Protokollen für Sie.
Die folgende Methode zeigt, wie Sie einen Benutzerbestätigungshandler einrichten:
[MSACCrashes setUserConfirmationHandler:(^(NSArray<MSACErrorReport *> *errorReports) {
// Your code to present your UI to the user, e.g. an UIAlertController.
UIAlertController *alertController = [UIAlertController
alertControllerWithTitle:@"Sorry about that!"
message:@"Do you want to send an anonymous crash report so we can fix the issue?"
preferredStyle:UIAlertControllerStyleAlert];
[alertController
addAction:[UIAlertAction actionWithTitle:@"Don't send"
style:UIAlertActionStyleCancel
handler:^(UIAlertAction *action) {
[MSACCrashes notifyWithUserConfirmation:MSACUserConfirmationDontSend];
}]];
[alertController
addAction:[UIAlertAction actionWithTitle:@"Send"
style:UIAlertActionStyleDefault
handler:^(UIAlertAction *action) {
[MSACCrashes notifyWithUserConfirmation:MSACUserConfirmationSend];
}]];
[alertController
addAction:[UIAlertAction actionWithTitle:@"Always send"
style:UIAlertActionStyleDefault
handler:^(UIAlertAction *action) {
[MSACCrashes notifyWithUserConfirmation:MSACUserConfirmationAlways];
}]];
// Show the alert controller.
[self.window.rootViewController presentViewController:alertController animated:YES completion:nil];
return YES; // Return YES if the SDK should await user confirmation, otherwise NO.
})];
Crashes.setUserConfirmationHandler({ (errorReports: [ErrorReport]) in
// Your code to present your UI to the user, e.g. an UIAlertController.
let alertController = UIAlertController(title: "Sorry about that!",
message: "Do you want to send an anonymous crash report so we can fix the issue?",
preferredStyle:.alert)
alertController.addAction(UIAlertAction(title: "Don't send", style: .cancel) {_ in
Crashes.notify(with: .dontSend)
})
alertController.addAction(UIAlertAction(title: "Send", style: .default) {_ in
Crashes.notify(with: .send)
})
alertController.addAction(UIAlertAction(title: "Always send", style: .default) {_ in
Crashes.notify(with: .always)
})
// Show the alert controller.
self.window?.rootViewController?.present(alertController, animated: true)
return true // Return true if the SDK should await user confirmation, otherwise return false.
})
Falls Sie im obigen Handlerblock zurückkehren YES
/true
, sollte Ihre App die Benutzerberechtigung erhalten und dem SDK eine Nachricht mit dem Ergebnis mithilfe der folgenden API senden. Wenn Sie hierfür eine Warnung verwenden, wie im obigen Beispiel, rufen Sie sie in Ihrer Implementierung des alertView:clickedButtonAtIndex:
Rückrufs auf.
// Depending on the users's choice, call notifyWithUserConfirmation: with the right value.
[MSACCrashes notifyWithUserConfirmation:MSACUserConfirmationDontSend];
[MSACCrashes notifyWithUserConfirmation:MSACUserConfirmationSend];
[MSACCrashes notifyWithUserConfirmation:MSACUserConfirmationAlways];
// Depending on the user's choice, call notify(with:) with the right value.
Crashes.notify(with: .dontSend)
Crashes.notify(with: .send)
Crashes.notify(with: .always)
Manchmal möchten Sie die status Ihres App-Absturzes kennen. Ein häufiger Anwendungsfall ist, dass Sie möglicherweise eine Benutzeroberfläche anzeigen möchten, die den Benutzern mitteilt, dass Ihre App einen Absturzbericht übermittelt, oder, falls Ihre App nach dem Start schnell abstürzt, möchten Sie das Verhalten der App anpassen, um sicherzustellen, dass die Absturzprotokolle übermittelt werden können. Das CrashesDelegate
-Protokoll definiert drei verschiedene Rückrufe, die Sie in Ihrer App verwenden können, um über die Vorgänge informiert zu werden:
- (void)crashes:(MSACCrashes *)crashes willSendErrorReport:(MSACErrorReport *)errorReport {
// Your code, e.g. to present a custom UI.
}
func crashes(_ crashes: Crashes, willSend errorReport: ErrorReport) {
// Your code, e.g. to present a custom UI.
}
Falls Netzwerkprobleme oder ein Ausfall auf dem Endpunkt auftreten und Sie die App neu starten, willSendErrorReport
wird nach dem Neustart des Prozesses erneut ausgelöst.
- (void)crashes:(MSACCrashes *)crashes didSucceedSendingErrorReport:(MSACErrorReport *)errorReport {
// Your code, e.g. to hide the custom UI.
}
func crashes(_ crashes: Crashes, didSucceedSending errorReport: ErrorReport) {
// Your code goes here.
}
- (void)crashes:(MSACCrashes *)crashes didFailSendingErrorReport:(MSACErrorReport *)errorReport withError:(NSError *)error {
// Your code goes here.
}
func crashes(_ crashes: Crashes, didFailSending errorReport: ErrorReport, withError error: Error) {
// Your code goes here.
}
Der didFailSendingErrorReport
Empfang bedeutet einen nicht wiederherstellbaren Fehler, z. B. ein 4xx-Code . Beispielsweise bedeutet 401, dass falsch appSecret
ist.
Dieser Rückruf wird nicht ausgelöst, wenn es sich um ein Netzwerkproblem handelt. In diesem Fall versucht das SDK immer wieder (und hält auch Wiederholungen an, während die Netzwerkverbindung unterbrochen ist).
Sie können Binär- und Textanlagen zu einem Absturzbericht hinzufügen. Das SDK sendet sie zusammen mit dem Absturz, sodass Sie sie im App Center-Portal sehen können. Der folgende Rückruf wird direkt vor dem Senden des gespeicherten Absturzes von früheren Anwendungsstarts aufgerufen. Es wird nicht aufgerufen, wenn der Absturz auftritt. Hier sehen Sie ein Beispiel für das Anfügen von Text und einem Bild an einen Absturz:
- (NSArray<MSACErrorAttachmentLog *> *)attachmentsWithCrashes:(MSACCrashes *)crashes
forErrorReport:(MSACErrorReport *)errorReport {
MSACErrorAttachmentLog *attachment1 = [MSACErrorAttachmentLog attachmentWithText:@"Hello world!" filename:@"hello.txt"];
MSACErrorAttachmentLog *attachment2 = [MSACErrorAttachmentLog attachmentWithBinary:[@"Fake image" dataUsingEncoding:NSUTF8StringEncoding] filename:@"fake_image.jpeg" contentType:@"image/jpeg"];
return @[ attachment1, attachment2 ];
}
func attachments(with crashes: Crashes, for errorReport: ErrorReport) -> [ErrorAttachmentLog]? {
let attachment1 = ErrorAttachmentLog.attachment(withText: "Hello world!", filename: "hello.txt")
let attachment2 = ErrorAttachmentLog.attachment(withBinary: "Fake image".data(using: String.Encoding.utf8), filename: nil, contentType: "image/jpeg")
return [attachment1!, attachment2!]
}
Hinweis
Die Größenbeschränkung beträgt derzeit 7 MB. Beim Versuch, eine größere Anlage zu senden, wird ein Fehler ausgelöst.
Sie können App Center-Abstürze zur Laufzeit aktivieren und deaktivieren. Wenn Sie sie deaktivieren, erstellt das SDK keine Absturzberichte für die App.
[MSACCrashes setEnabled:NO];
Crashes.enabled = false
Um App Center-Abstürze erneut zu aktivieren, verwenden Sie dieselbe API, übergeben YES
/true
Sie jedoch als Parameter.
[MSACCrashes setEnabled:YES];
Crashes.enabled = true
Der Zustand wird über Anwendungsstarts hinweg im Speicher des Geräts beibehalten.
Hinweis
Diese Methode darf erst nach dem Crashes
Start verwendet werden.
Sie können auch überprüfen, ob App Center-Abstürze aktiviert ist oder nicht:
BOOL enabled = [MSACCrashes isEnabled];
var enabled = Crashes.enabled
Hinweis
Diese Methode darf nur verwendet werden, nachdem Crashes
gestartet wurde. Sie wird immer vor dem Start zurückgegeben false
.
Standardmäßig verwendet App Center Crashes den Mach-Ausnahmehandler, um schwerwiegende Signale, z. B. Stapelüberläufe, über einen Mach-Ausnahmeserver abzufangen.
Die disableMachExceptionHandler
-Methode bietet eine Option zum Deaktivieren des Abfangens schwerwiegender Signale über einen Mach-Ausnahmeserver. Wenn Sie den Mach-Ausnahmehandler deaktivieren möchten, sollten Sie diese Methode aufrufen, BEVOR Sie das SDK starten. Ihr typischer Setupcode sieht wie folgt aus:
[MSACCrashes disableMachExceptionHandler];
[MSACAppCenter start:@"{Your App Secret}" withServices:@[[MSACAnalytics class], [MSACCrashes class]]];
Crashes.disableMachExceptionHandler()
AppCenter.start(withAppSecret: "{Your App Secret}", services: [Analytics.self, Crashes.self])