Awarie usługi App Center (tvOS)
Ważne
Program Visual Studio App Center ma zostać wycofany 31 marca 2025 r. Chociaż możesz nadal używać programu Visual Studio App Center do momentu jego pełnego wycofania, istnieje kilka zalecanych alternatyw, do których można rozważyć migrację.
Dowiedz się więcej o osiach czasu pomocy technicznej i alternatywach.
Awarie usługi App Center automatycznie generują dziennik awarii za każdym razem, gdy aplikacja ulegnie awarii. Dziennik jest najpierw zapisywany w magazynie urządzenia, a gdy użytkownik uruchomi aplikację ponownie, raport o awarii zostanie wysłany do Centrum aplikacji. Zbieranie awarii działa zarówno w przypadku aplikacji w wersji beta, jak i na żywo, tj. przesyłanych do App Store. Dzienniki awarii zawierają cenne informacje ułatwiające naprawienie awarii.
Postępuj zgodnie z sekcją Wprowadzenie, jeśli zestaw SDK nie został jeszcze skonfigurowany w aplikacji.
Ponadto dzienniki awarii w systemie tvOS wymagają symboliczności, zapoznaj się z dokumentacją diagnostyki Centrum aplikacji , która wyjaśnia, jak zapewnić symbole dla aplikacji.
Uwaga
Aby odbierać prawidłowo symboliczne ślady stosu, upewnij się, że kod bitowy jest wyłączony. Więcej informacji na temat kodu bitowego można dowiedzieć się w dokumentacji symbolicznej systemu iOS w usłudze App Center.
Uwaga
4.0.0
Wprowadzono zmiany powodujące niezgodność w usłudze App Center. Postępuj zgodnie z sekcją Migrate to App Center SDK 4.0.0 and higher (Migrowanie do zestawu APP Center SDK 4.0.0 i nowszych), aby przeprowadzić migrację centrum aplikacji z poprzednich wersji.
Generowanie awarii testowej
Awarie usługi App Center udostępnia interfejs API do generowania awarii testowej w celu łatwego testowania zestawu SDK. Ten interfejs API może być używany tylko w aplikacjach testowych/beta i nie będzie wykonywać żadnych czynności w aplikacjach produkcyjnych.
[MSACCrashes generateTestCrash];
Crashes.generateTestCrash()
Uzyskaj więcej informacji o poprzedniej awarii
Usługa App Center Crash ma dwa interfejsy API, które zapewniają więcej informacji na wypadek awarii aplikacji.
Czy aplikacja otrzymała ostrzeżenie o niskiej ilości pamięci w poprzedniej sesji?
W dowolnym momencie po uruchomieniu zestawu SDK możesz sprawdzić, czy aplikacja otrzymała ostrzeżenie o pamięci w poprzedniej sesji:
[MSACCrashes hasReceivedMemoryWarningInLastSession];
Crashes.hasReceivedMemoryWarningInLastSession
Uwaga
Ta metoda musi być używana tylko po Crashes
uruchomieniu, zawsze będzie zwracać NO
lub false
przed rozpoczęciem.
Uwaga
W niektórych przypadkach urządzenie z małą ilością pamięci nie może wysyłać zdarzeń.
Czy aplikacja uległa awarii w poprzedniej sesji?
W dowolnym momencie po uruchomieniu zestawu SDK możesz sprawdzić, czy aplikacja uległa awarii w poprzednim uruchomieniu:
[MSACCrashes hasCrashedInLastSession];
Crashes.hasCrashedInLastSession
Jest to przydatne w przypadku, gdy chcesz dostosować zachowanie lub interfejs użytkownika aplikacji po wystąpieniu awarii.
Uwaga
Ta metoda musi być używana tylko po MSACCrashes
uruchomieniu, zawsze będzie zwracać NO
lub false
przed rozpoczęciem.
Szczegółowe informacje o ostatniej awarii
Jeśli aplikacja uległa awarii wcześniej, możesz uzyskać szczegółowe informacje o ostatniej awarii.
MSACErrorReport *crashReport = [MSACCrashes lastSessionCrashReport];
var crashReport = Crashes.lastSessionCrashReport
Uwaga
Ta metoda musi być używana tylko po Crashes
uruchomieniu. Zawsze będzie ona zwracana nil
przed rozpoczęciem.
Istnieje wiele przypadków użycia dla tego interfejsu API, najczęściej są to osoby, które nazywają ten interfejs API i implementują niestandardowe awarieDelegate.
Dostosowywanie użycia awarii usługi App Center
Awarie usługi App Center udostępniają deweloperom wywołania zwrotne umożliwiające wykonywanie dodatkowych akcji przed i podczas wysyłania dzienników awarii do Centrum aplikacji.
Aby dodać zachowanie niestandardowe, należy zastosować CrashesDelegate
protokół -, wszystkie jego metody są opcjonalne.
Zarejestruj się jako pełnomocnik
[MSACCrashes setDelegate:self];
Crashes.delegate = self
Uwaga
Należy ustawić delegata przed wywołaniem metody AppCenter.start
, ponieważ usługa App Center rozpoczyna przetwarzanie awarii natychmiast po uruchomieniu.
Czy awaria powinna zostać przetworzona?
Zaimplementuj metodę crashes:shouldProcessErrorReport:
-w klasie, która przyjmuje CrashesDelegate
protokół -, jeśli chcesz zdecydować, czy należy przetworzyć konkretną awarię, czy nie. Na przykład może wystąpić awaria na poziomie systemu, którą chcesz zignorować, i że nie chcesz wysyłać do usługi App Center.
- (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.
}
Obsługiwane błędy
Usługa App Center umożliwia również śledzenie błędów przy użyciu obsługiwanych wyjątków za pośrednictwem trackError
metody. Aplikacja może opcjonalnie dołączać właściwości lub/i załączniki do obsłużonego raportu o błędach w celu zapewnienia dalszego kontekstu.
@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)
}
W przypadku śledzenia wyjątków można użyć trackException
metody :
@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)
}
Poproś użytkownika o zgodę na wysłanie dziennika awarii
Jeśli prywatność użytkowników jest dla Ciebie ważna, przed wysłaniem raportu o awarii do Centrum aplikacji warto uzyskać potwierdzenie użytkowników. Zestaw SDK uwidacznia wywołanie zwrotne, które informuje usługę App Center o awarii w celu oczekiwania na potwierdzenie użytkowników przed wysłaniem raportów o awarii.
Jeśli zdecydujesz się to zrobić, odpowiadasz za uzyskanie potwierdzenia użytkownika, na przykład za pośrednictwem okna dialogowego z jedną z następujących opcji: Zawsze wysyłaj, Wysyłaj i Nie wysyłaj. Na podstawie danych wejściowych poinformujesz centrum aplikacji o awarii, co należy zrobić, a awaria zostanie odpowiednio obsłużona.
Uwaga
Zestaw SDK nie wyświetla w tym celu okna dialogowego. Aplikacja musi podać własny interfejs użytkownika, aby poprosić o zgodę użytkownika.
Uwaga
Aplikacja nie powinna wywoływać notifyWithUserConfirmation
jawnie, jeśli nie implementuje okna dialogowego potwierdzenia użytkownika. Moduł Awarie będzie obsługiwać wysyłanie dzienników niejawnie.
Poniższa metoda pokazuje, jak skonfigurować procedurę obsługi potwierdzenia użytkownika:
[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.
})];
MSACCrashes.setUserConfirmationHandler({ (errorReports: [MSACErrorReport]) 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
MSACCrashes.notify(with: .dontSend)
})
alertController.addAction(UIAlertAction(title: "Send", style: .default) {_ in
MSACCrashes.notify(with: .send)
})
alertController.addAction(UIAlertAction(title: "Always send", style: .default) {_ in
MSACCrashes.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.
})
Jeśli wrócisz YES
/true
do powyższego bloku obsługi, aplikacja powinna uzyskać uprawnienia użytkownika i wyświetlić komunikat zestawu SDK z wynikiem przy użyciu następującego interfejsu API. Jeśli używasz dla tego alertu, tak jak w powyższym przykładzie, wywołasz go z poziomu implementacji wywołania zwrotnego alertView:clickedButtonAtIndex:
- callback.
// 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.
MSACCrashes.notify(with: .dontSend)
MSACCrashes.notify(with: .send)
MSACCrashes.notify(with: .always)
Uzyskiwanie informacji o stanie wysyłania dziennika awarii
Czasami chcesz znać stan awarii aplikacji. Typowy przypadek użycia polega na tym, że można wyświetlić interfejs użytkownika, który informuje użytkowników, że aplikacja przesyła raport o awarii lub w przypadku, gdy aplikacja ulega awarii szybko po uruchomieniu, chcesz dostosować zachowanie aplikacji, aby upewnić się, że można przesłać dzienniki awarii. Protokół CrashesDelegate
-protocol definiuje trzy różne wywołania zwrotne, których można używać w aplikacji do powiadamiania o tym, co się dzieje:
Następujące wywołanie zwrotne zostanie wywołane przed wysłaniem dziennika awarii przez zestaw SDK
- (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.
}
W przypadku problemów z siecią lub awarii w punkcie końcowym i ponownego uruchomienia aplikacji willSendErrorReport
zostanie ponownie wyzwolona po ponownym uruchomieniu procesu.
Następujące wywołanie zwrotne zostanie wywołane po pomyślnym wysłaniu dziennika awarii przez zestaw SDK
- (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.
}
Następujące wywołanie zwrotne zostanie wywołane, jeśli zestaw SDK nie może wysłać dziennika awarii
- (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.
}
Odbieranie didFailSendingErrorReport
oznacza, że wystąpił błąd niemożliwy do odzyskania, taki jak kod 4xx . Na przykład 401 oznacza, że błąd appSecret
jest nieprawidłowy.
To wywołanie zwrotne nie jest wyzwalane, jeśli jest to problem z siecią. W takim przypadku zestaw SDK ponawia próbę (a także wstrzymuje ponawianie próby, gdy połączenie sieciowe nie działa).
Dodawanie załączników do raportu o awarii
Możesz dodać załączniki binarne i tekstowe do raportu o awarii. Zestaw SDK wyśle je wraz z awarią, aby można było je zobaczyć w portalu Centrum aplikacji. Następujące wywołanie zwrotne zostanie wywołane bezpośrednio przed wysłaniem przechowywanej awarii z poprzednich uruchomień aplikacji. Nie zostanie ona wywołana, gdy wystąpi awaria. Oto przykład dołączania tekstu i obrazu do awarii:
- (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!]
}
Uwaga
Limit rozmiaru wynosi obecnie 7 MB. Próba wysłania większego załącznika spowoduje wystąpienie błędu.
Włączanie lub wyłączanie awarii usługi App Center w czasie wykonywania
Możesz włączyć i wyłączyć awarie usługi App Center w czasie wykonywania. Jeśli ją wyłączysz, zestaw SDK nie będzie wykonywać żadnych raportów dotyczących awarii dla aplikacji.
[MSACCrashes setEnabled:NO];
Crashes.enabled = false
Aby ponownie włączyć awarie usługi App Center, użyj tego samego interfejsu API, ale przekaż YES
/true
go jako parametr.
[MSACCrashes setEnabled:YES];
Crashes.enabled = true
Stan jest utrwalany w magazynie urządzenia w ramach uruchamiania aplikacji.
Uwaga
Ta metoda musi być używana tylko po Crashes
rozpoczęciu.
Sprawdzanie, czy w centrum aplikacji jest włączona awaria
Możesz również sprawdzić, czy usługa App Center Ulega awarii jest włączona, czy nie:
BOOL enabled = [MSACCrashes isEnabled];
var enabled = Crashes.enabled
Uwaga
Ta metoda musi być używana tylko po Crashes
rozpoczęciu. Będzie ona zawsze zwracana false
przed rozpoczęciem.