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.
- 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
Przed użyciem naszych interfejsów API dodaj odpowiednie przestrzenie nazw.
using Microsoft.AppCenter.Crashes;
Dodaj lub zmodyfikuj następujące wywołanie konstruktora aplikacji, aby uwzględnić moduł awarii:
AppCenter.Start("{Your App Secret}", typeof(Crashes));
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();
Usługa App Center Crash ma dwa interfejsy API, które zapewniają więcej informacji na wypadek awarii aplikacji.
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.
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.
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.
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;
};
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);
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:
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.
Crashes.SentErrorReport += (sender, e) =>
{
// Your code, e.g. to hide the custom UI.
};
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).
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.
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.
Możesz również sprawdzić, czy usługa App Center Ulega awarii jest włączona, czy nie:
bool isEnabled = await Crashes.IsEnabledAsync();
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);
}