Awarie centrum aplikacji (UWP/WinUI)
Ważne
Program Visual Studio App Center ma zostać wycofany 31 marca 2025 r. Mimo że możesz nadal używać programu Visual Studio App Center do momentu jej 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 centrum aplikacji automatycznie wygenerują dziennik awarii za każdym razem, gdy aplikacja ulegnie awarii. Dziennik jest najpierw zapisywany w magazynie urządzenia, a gdy użytkownik ponownie uruchomi aplikację, raport o awarii zostanie wysłany do Centrum aplikacji. Zbieranie awarii działa zarówno dla aplikacji beta, jak i przesłanych do Sklepu Windows. Dzienniki awarii zawierają cenne informacje ułatwiające naprawienie awarii.
Zestaw SDK centrum aplikacji zbiera tylko awarie spowodowane przez nieobsługiwane wyjątki platformy .NET. Nie zbiera ona natywnych awarii, np. w przypadku korzystania z języka C lub C++. Jeśli jednak masz aplikację z awariami języka C++, możesz przekazać je do Centrum aplikacji za pośrednictwem interfejsu API awarii przekazywania.
Jeśli zestaw SDK nie został jeszcze skonfigurowany w aplikacji, postępuj zgodnie z sekcją Wprowadzenie.
Uwaga
Obecnie nie obsługujemy wykrywania ostrzeżeń o niskiej ilości pamięci na platformie UWP/WinUI.
Dodawanie modułu awarii
Konsola menedżera pakietów
- Otwórz konsolę w programie Visual Studio. W tym celu wybierz pozycję Narzędzia Konsola>Menedżera>pakietów NuGet Menedżera pakietów.
- Wpisz następujące polecenia:
Install-Package Microsoft.AppCenter.Crashes
Dodawanie instrukcji using
Przed użyciem naszych interfejsów API dodaj odpowiednie przestrzenie nazw.
using Microsoft.AppCenter.Crashes;
Modyfikowanie Start() metody
Dodaj lub zmodyfikuj następujące wywołanie konstruktora aplikacji, aby uwzględnić moduł awarii:
AppCenter.Start("{Your App Secret}", typeof(Crashes));
Generowanie awarii testowej
Usługa App Center Crash udostępnia interfejs API umożliwiający wygenerowanie awarii testowej w celu łatwego testowania zestawu SDK. Ten interfejs API sprawdza konfiguracje debugowania i wydania. Dlatego można go używać tylko podczas debugowania, ponieważ nie będzie działać w przypadku aplikacji wydania.
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 uległa awarii w poprzedniej sesji?
W dowolnym momencie po uruchomieniu zestawu SDK możesz sprawdzić, czy aplikacja uległa awarii w poprzednim uruchomieniu:
bool didAppCrash = await Crashes.HasCrashedInLastSessionAsync();
Jest to przydatne w przypadku, gdy chcesz dostosować zachowanie lub interfejs użytkownika aplikacji po wystąpieniu awarii. Niektórzy deweloperzy zdecydują się pokazać dodatkowy interfejs użytkownika, aby przeprosić swoich użytkowników lub chcieć skontaktować się po wystąpieniu awarii.
Uwaga
Ta metoda musi być używana tylko po Crashes rozpoczęciu; zawsze będzie zwracana false przed rozpoczęciem.
Szczegóły dotyczące ostatniej awarii
Jeśli aplikacja uległa awarii wcześniej, możesz uzyskać szczegółowe informacje o ostatniej awarii.
ErrorReport crashReport = await Crashes.GetLastSessionCrashReportAsync();
Uwaga
Ta metoda musi być używana tylko po Crashes rozpoczęciu; zawsze będzie zwracana null 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ą niestandardowy delegat lub odbiornik awarii.
Dostosowywanie użycia awarii centrum aplikacji
Usługa App Center Crash udostępnia wywołania zwrotne dla deweloperów w celu wykonywania dodatkowych akcji przed i podczas wysyłania dzienników awarii do centrum aplikacji.
Uwaga
Ustaw wywołanie zwrotne przed wywołaniem AppCenter.Start()metody , ponieważ usługa App Center rozpoczyna przetwarzanie awarii natychmiast po uruchomieniu.
Czy awaria powinna zostać przetworzona?
Ustaw to wywołanie zwrotne, 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 centrum aplikacji.
Crashes.ShouldProcessErrorReport = (ErrorReport report) =>
{
// Check the report in here and return true or false depending on the ErrorReport.
return true;
};
Poproś użytkownika o zgodę na wysłanie dziennika awarii
Jeśli prywatność użytkownika jest dla Ciebie ważna, możesz uzyskać potwierdzenie użytkownika przed wysłaniem raportu o awarii do Centrum aplikacji. Zestaw SDK uwidacznia wywołanie zwrotne, które informuje usługę App Center Crash o oczekiwaniu na potwierdzenie użytkownika przed wysłaniem raportów o awarii.
Jeśli zdecydujesz się to zrobić, odpowiadasz za uzyskanie potwierdzenia użytkownika, np. za pośrednictwem monitu 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 okna dialogowego. Aplikacja musi podać własny interfejs użytkownika, aby poprosić o zgodę użytkownika.
Uwaga
Aplikacja nie powinna wywoływać NotifyUserConfirmation jawnie, jeśli nie implementuje okna dialogowego potwierdzenia użytkownika. Moduł Crash obsłuży wysyłanie dzienników niejawnie.
Poniższe wywołanie zwrotne pokazuje, jak poinformować zestaw SDK o oczekiwaniu na potwierdzenie użytkownika przed wysłaniem awarii:
Crashes.ShouldAwaitUserConfirmation = () =>
{
// Build your own UI to ask for user consent here. The SDK doesn't provide one by default.
// Return true if you built a UI for user consent and are waiting for user input on that custom UI, otherwise false.
return true;
};
Jeśli wrócisz true w powyższym wywołaniu zwrotnym, aplikacja musi uzyskać (przy użyciu własnego kodu) uprawnienie użytkownika i wysłać wiadomość do zestawu SDK z wynikiem przy użyciu następującego interfejsu API.
// Depending on the user's choice, call Crashes.NotifyUserConfirmation() with the right value.
Crashes.NotifyUserConfirmation(UserConfirmation.DontSend);
Crashes.NotifyUserConfirmation(UserConfirmation.Send);
Crashes.NotifyUserConfirmation(UserConfirmation.AlwaysSend);
Uzyskiwanie informacji o stanie wysyłania dziennika awarii
Czasami chcesz znać stan awarii aplikacji. Typowy przypadek użycia polega na tym, że możesz pokazać 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 dzienniki awarii można przesłać. Awarie usługi App Center udostępnia trzy różne wywołania zwrotne, których można użyć w aplikacji, aby otrzymywać powiadomienia o tym, co się dzieje:
Następujące wywołanie zwrotne zostanie wywołane przed wysłaniem dziennika awarii przez zestaw SDK
Crashes.SendingErrorReport += (sender, e) =>
{
// Your code, e.g. to present a custom UI.
};
W przypadku wystąpienia problemów z siecią lub awarii punktu końcowego i ponowne uruchomienie aplikacji SendingErrorReport zostanie ponownie wyzwolone po ponownym uruchomieniu procesu.
Następujące wywołanie zwrotne zostanie wywołane po pomyślnym wysłaniu dziennika awarii zestawu SDK
Crashes.SentErrorReport += (sender, e) =>
{
// Your code, e.g. to hide the custom UI.
};
Następujące wywołanie zwrotne zostanie wywołane, jeśli zestaw SDK nie może wysłać dziennika awarii
Crashes.FailedToSendErrorReport += (sender, e) =>
{
// Your code goes here.
};
Odbieranie FailedToSendErrorReport oznacza, że wystąpił błąd niemożliwy do odzyskania, taki jak kod 4xx . Na przykład 401 oznacza, że wartość jest nieprawidłowa appSecret .
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 będzie wywoływana, gdy wystąpi awaria. Upewnij się, że plik załącznika nie ma nazwy, minidump.dmp ponieważ nazwa jest zarezerwowana dla plików minidump. Oto przykład dołączania tekstu i obrazu do awarii:
Crashes.GetErrorAttachments = (ErrorReport report) =>
{
// Your code goes here.
return new ErrorAttachmentLog[]
{
ErrorAttachmentLog.AttachmentWithText("Hello world!", "hello.txt"),
ErrorAttachmentLog.AttachmentWithBinary(Encoding.UTF8.GetBytes("Fake image"), "fake_image.jpeg", "image/jpeg")
};
};
Uwaga
Limit rozmiaru wynosi obecnie 7 MB. Próba wysłania większego załącznika spowoduje wyzwolenie 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 o awarii dla aplikacji.
Crashes.SetEnabledAsync(false);
Aby ponownie włączyć awarie usługi App Center, użyj tego samego interfejsu API, ale przekaż true go jako parametr.
Crashes.SetEnabledAsync(true);
Nie musisz czekać na to wywołanie, aby inne wywołania interfejsu API (takie jak IsEnabledAsync) były spójne.
Stan jest utrwalany w magazynie urządzenia w ramach uruchamiania aplikacji.
Sprawdzanie, czy usługa App Center ulega awarii jest włączona
Możesz również sprawdzić, czy usługa App Center Ulega awarii jest włączona, czy nie:
bool isEnabled = await Crashes.IsEnabledAsync();
Obsługiwane błędy
Usługa App Center umożliwia również śledzenie błędów przy użyciu obsługiwanych wyjątków. W tym celu użyj TrackError metody :
try {
// your code goes here.
} catch (Exception exception) {
Crashes.TrackError(exception);
}
Aplikacja może opcjonalnie dołączać właściwości do obsłużonego raportu o błędach w celu zapewnienia dalszego kontekstu. Przekaż właściwości jako słownik par klucz/wartość (tylko ciągi), jak pokazano w poniższym przykładzie.
try {
// your code goes here.
} catch (Exception exception) {
var properties = new Dictionary<string, string>
{
{ "Category", "Music" },
{ "Wifi", "On"}
};
Crashes.TrackError(exception, properties);
}
Opcjonalnie możesz również dodać załączniki binarne i tekstowe do obsłużonego raportu o błędach. Przekaż załączniki jako tablicę ErrorAttachmentLog obiektów, jak pokazano w poniższym przykładzie.
try {
// your code goes here.
} catch (Exception exception) {
var attachments = new ErrorAttachmentLog[]
{
ErrorAttachmentLog.AttachmentWithText("Hello world!", "hello.txt"),
ErrorAttachmentLog.AttachmentWithBinary(Encoding.UTF8.GetBytes("Fake image"), "fake_image.jpeg", "image/jpeg")
};
Crashes.TrackError(exception, attachments: attachments);
}