Not
Åtkomst till denna sida kräver auktorisation. Du kan prova att logga in eller byta katalog.
Åtkomst till denna sida kräver auktorisation. Du kan prova att byta katalog.
Viktigt!
Visual Studio App Center drogs tillbaka den 31 mars 2025, förutom analys- och diagnostikfunktionerna, som fortsätter att stödjas fram till den 30 juni 2026. Läs mer.
App Center-krascher genererar automatiskt en kraschlogg varje gång appen kraschar, med en logg till enhetens lagring. När en användare startar appen igen skickar SDK:et kraschrapporten till App Center. Insamling av krascher fungerar för både beta- och liveappar, dvs. krascher som skickas till Google Play. Kraschloggar innehåller värdefull information som hjälper dig att åtgärda kraschen.
Följ anvisningarna i avsnittet Komma igång med Unity om du inte har konfigurerat SDK:t i ditt program ännu.
Kraschloggar på iOS kräver symbolisering. Om du vill aktivera symbolik läser du dokumentationen för App Center Diagnostics, som förklarar hur du tillhandahåller symboler för din app.
Viktigt!
Crashs SDK för Unity stöder inte UWP. Anvisningarna på den här sidan omfattar endast Android och iOS.
Anmärkning
SDK:t vidarebefordrar inga kraschloggar om du har kopplat felsökningsprogrammet. Kontrollera att felsökaren inte är ansluten när du kraschar appen.
Anmärkning
Om du har Enable CrashReport API aktiverat i PlayerSettings samlar SDK inte in kraschloggar.
Generera en testkrasch
Med App Center-krascher får du ett API för att generera en testkrasch för enkel testning av SDK:n. Det här API:et söker efter felsöknings- och versionskonfigurationer. Så du kan bara använda den när du felsöker eftersom den inte fungerar för versionsappar.
Crashes.GenerateTestCrash();
Anmärkning
Den här metoden fungerar bara med inställningen Development Build aktiverad.
Få mer information om en tidigare krasch
App Center-krascher har två API:er som ger dig mer information om din app har kraschat.
Fick appen en varning om lite minne i föregående session?
När som helst efter att du har startat SDK:n kan du kontrollera om appen fick en minnesvarning i föregående session:
bool hadLowMemoryWarning = Crashes.HasReceivedMemoryWarningInLastSessionAsync().Result;
Anmärkning
Den här metoden fungerar inte i Awake().
Anmärkning
I vissa fall kan en enhet med lite minne inte skicka händelser.
Kraschade appen i föregående session?
När som helst efter att du har startat SDK kan du kontrollera om appen kraschade i föregående start:
bool didAppCrash = await Crashes.HasCrashedInLastSessionAsync();
Anrop HasCrashedInLastSessionAsync är användbart om du vill justera appens beteende eller användargränssnitt efter att en krasch har inträffat. Vissa utvecklare visar ytterligare användargränssnitt för att be om ursäkt till sina användare eller vill kontakta dem när en krasch har inträffat.
Information om den senaste kraschen
Om appen kraschade tidigare kan du få information om den senaste kraschen.
ErrorReport crashReport = await Crashes.GetLastSessionCrashReportAsync();
Det vanligaste användningsfallet för det här API:et är när en användare implementerar sin anpassade Crashes-delegering eller händelselyssnare.
Anpassa din användning av App Center Crashes
App Center-krascher ger återanrop för utvecklare att vidta ytterligare åtgärder före och när de skickar kraschloggar till App Center.
Anmärkning
Ställ in återanropet innan App Center startar, till exempel i Awake metoden eftersom App Center börjar bearbeta krascher direkt efter starten.
Ska kraschen bearbetas?
Ange följande återanrop om du vill avgöra om en viss krasch behöver hanteras eller inte. Det kan till exempel finnas en krasch på systemnivå som du vill ignorera och inte skicka till App Center.
Crashes.ShouldProcessErrorReport = (ErrorReport report) =>
{
// Check the report in here and return true or false depending on the ErrorReport.
return true;
};
Be om användarens medgivande att skicka en kraschlogg
Om användarsekretess är viktigt för dig kanske du vill få användarbekräftelse innan du skickar en kraschrapport till App Center. SDK exponerar ett återanrop som instruerar App Center Crashes att invänta bekräftelse från användaren innan kraschrapporter skickas.
Om koden använder det här återanropet ansvarar du för att få användarens bekräftelse. Ett alternativ är via en dialogruta med något av följande alternativ: Skicka alltid, Skicka och Skicka inte. Baserat på indata meddelar du App Center Crashes vad det ska göra och därefter hanteras kraschen enligt inställningarna.
Anmärkning
SDK:t visar ingen dialogruta för detta. Appen måste ange ett eget användargränssnitt för att be om användarmedgivande.
Följande återanrop visar hur du instruerar SDK:t att vänta på att användaren bekräftas innan krascher skickas:
Crashes.ShouldAwaitUserConfirmation = () =>
{
// Build your own UI to ask for user consent here. 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;
};
Om återanropet returnerar truemåste du hämta användarbehörighet och skicka ett meddelande till SDK:n med resultatet med hjälp av följande 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);
Som ett exempel kan du referera till vårt anpassade dialogexempel.
Hämta information om statusen för sändningen av en kraschlogg
Ibland vill du veta status för din appkrasch. Ett vanligt användningsfall är att visa ett användargränssnitt som informerar användaren om att appen skickar en kraschrapport. Ett annat scenario är när du vill justera appens beteende för att säkerställa att kraschloggarna kan skickas strax efter omstarten. App Center Crashes erbjuder tre olika återanrop som du kan använda för att bli informerad om vad som har hänt.
Följande callback-funktion anropas innan en kraschlogg skickas av SDK:et
Crashes.SendingErrorReport += (errorReport) =>
{
// Your code, e.g. to present a custom UI.
};
Om vi har nätverksproblem eller ett avbrott på slutpunkten och du startar om appen SendingErrorReport utlöses den igen efter att processen startats om.
Följande callback kommer att anropas efter att SDK:et har skickat en kraschlogg framgångsrikt
Crashes.SentErrorReport += (errorReport) =>
{
// Your code, e.g. to hide the custom UI.
};
Följande återanrop kommer att ske om SDK:et misslyckats med att skicka en kraschlogg
Crashes.FailedToSendErrorReport += (errorReport, exception) =>
{
// Your code goes here.
};
Att ta emot FailedToSendErrorReport innebär att ett fel som inte kan återställas, till exempel en 4xx-kod , inträffade. Till exempel betyder 401 att det är appSecret fel.
Återanropet utlöses inte om det är ett nätverksproblem. I det här fallet fortsätter SDK:n att försöka igen (och pausar även återförsök medan nätverksanslutningen är nere).
Lägg till bilagor till ett kraschanmälan eller en rapport om ohanterat undantag
Du kan också valfritt lägga till binära filer och textbilagor i en kraschrapport eller en rapport för ohanterade undantag. SDK skickar dem tillsammans med rapporten så att du kan se dem i App Center-portalen. Följande återanrop anropas direkt innan den lagrade rapporten skickas. För krascher sker det vid nästa programstart. För ohanterade undantag måste du anmäla dig för att skicka bifogade filer. Kontrollera att den bifogade filen inte är namngiven minidump.dmp eftersom namnet är reserverat för minidump-filer. Här är ett exempel på hur du bifogar text och en bild till en rapport:
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")
};
};
Krascher skiljs från ohanterade undantag i rapporter med egenskapen IsCrash. Egenskapen kommer att vara sann för krascher och falsk i andra fall.
Anmärkning
Storleksgränsen gäller för bifogade filer som för närvarande är 7 MB. Om du försöker skicka en större bifogad fil utlöses ett fel.
Anmärkning
GetErrorAttachments anropas i huvudtråden och delar inte upp arbete över bildrutor. Undvik att blockera spelloopen genom att inte utföra några tidskrävande uppgifter i det här återanropet.
Aktivera eller inaktivera App Center-krascher vid körning
Du kan aktivera och inaktivera App Center-krascher under körning. Om du inaktiverar det utför SDK:t ingen kraschrapportering för appen.
Crashes.SetEnabledAsync(false);
Om du vill aktivera App Center-krascher igen använder du samma API men skickar true som en parameter.
Crashes.SetEnabledAsync(true);
Du behöver inte invänta det här anropet för att göra andra API-anrop (till exempel IsEnabledAsync) konsekventa.
Tillståndet sparas i enhetens lagring mellan programstarter.
Kontrollera om App Center Crashes är aktiverat
Du kan också kontrollera om App Center Crashes är aktiverat:
bool isEnabled = await Crashes.IsEnabledAsync();
Hanterade undantag i Unity
Med App Center kan du också spåra fel med hanterade undantag i Unity. Om du vill göra det använder du TrackError metoden:
try {
// your code goes here.
} catch (Exception exception) {
Crashes.TrackError(exception);
}
Om du vill ha ytterligare kontext om felet kan du även koppla egenskaper till det. Skicka egenskaperna som en ordlista med strängar. Det här steget är valfritt.
try {
// your code goes here.
} catch (Exception exception) {
var properties = new Dictionary<string, string>
{
{ "Category", "Music" },
{ "Wifi", "On" }
};
Crashes.TrackError(exception, properties);
}
Du kan också lägga till binära filer och textbilagor i en hanterad felrapport. Skicka de bifogade filerna som en matris med ErrorAttachmentLog objekt som visas i exemplet nedan.
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);
}
Ohanterade undantag i Unity
Rapportera ohanterade undantag
Som standardläge rapporterar App Center SDK inte ohanterade undantag som genereras i din app och inte orsakar en krasch. Om du vill aktivera den här funktionen anropar du följande metod:
Crashes.ReportUnhandledExceptions(true);
När du har anropat det här API:et loggar App Center alla ohanterade undantag som problem i App Center-portalen, liknande hanterade undantag som nämnts tidigare. Om du vill inaktivera den här funktionen anropar du samma API som skickar false som parametern.
Crashes.ReportUnhandledExceptions(false);
Anmärkning
Vissa ohanterade undantag som identifieras av App Center SDK visas som fel i App Center-användargränssnittet. Det beror på att Unity fångar upp ohanterade undantag som standard, vilket innebär att appen inte avslutas och inte betraktas som en krasch.
Lägga till bifogade filer i en ohanterad undantagsrapport
Som standard aktiverar Inte App Center SDK bifogade filer vid ohanterade undantag. Om du vill aktivera den här funktionen anger du den enableAttachmentsCallback booleska parametern för ReportUnhandledExceptions metoden till true:
Crashes.ReportUnhandledExceptions(true, true);
Sedan kan du lägga till bifogade filer i en ohanterad undantagsrapport genom att implementera återanropet GetErrorAttachments .
Rapportera NDK-krascher
Rapportera krascher
Om du vill ta emot rätt kraschrapporter i App Center kontrollerar du först att du har konfigurerat App Center Crashs SDK genom att följa anvisningarna ovan.
Skapa breakpad-biblioteket
Därefter måste du inkludera och kompilera Google Breakpad genom att följa anvisningarna i den officiella Google Breakpad för Android README. Om du vill använda den i Unity inkluderar du binärfilen med din app.
Anmärkning
App Center SDK paketar inte Google Breakpad som standard.
Ansluta undantagshanteraren
När du har inkluderat Google Breakpad bifogar du NDK-kraschhanteraren:
/* Attach NDK Crash Handler. */
var minidumpDir = Crashes.GetMinidumpDirectoryAsync();
setupNativeCrashesListener(minidumpDir.Result);
...
[DllImport("YourLib")]
private static extern void setupNativeCrashesListener(string path);
Metoden setupNativeCrashesListener är en intern metod som du måste implementera i C/C++:
#include <android/log.h>
#include "google-breakpad/src/client/linux/handler/exception_handler.h"
#include "google-breakpad/src/client/linux/handler/minidump_descriptor.h"
static google_breakpad::ExceptionHandler exception_handler(google_breakpad::MinidumpDescriptor(), NULL, dumpCallback, NULL, true, -1);
/**
* Registers breakpad as the exception handler for NDK code.
* @param path minidump directory path returned from Crashes.GetMinidumpDirectoryAsync()
*/
extern "C" void setupNativeCrashesListener(const char *path) {
google_breakpad::MinidumpDescriptor descriptor(path);
exception_handler.set_minidump_descriptor(descriptor);
}
Var dumpCallback används för felsökning:
/*
* Triggered automatically after an attempt to write a minidump file to the breakpad folder.
*/
static bool dumpCallback(const google_breakpad::MinidumpDescriptor &descriptor,
void *context,
bool succeeded) {
/* Allow system to log the native stack trace. */
__android_log_print(ANDROID_LOG_INFO, "YourLogTag",
"Wrote breakpad minidump at %s succeeded=%d\n", descriptor.path(),
succeeded);
return false;
}
När dessa metoder har konfigurerats korrekt skickar appen minidumpen till App Center automatiskt vid omstart. Om du vill felsöka kan du använda utförliga loggar för att kontrollera om minidumps skickas när appen har startats om.
Anmärkning
App Center använder det reserverade namnet minidump.dmp för minidumpbilagor. Se till att ge den bifogade filen ett annat namn om det inte är en minidumpfil så att vi kan hantera den korrekt.
Varning
Det finns en känd bugg i breakpad som gör det omöjligt att fånga krascher på x86-emulatorer.
Symboliskt
Mer information om bearbetning av krascher finns i dokumentationen för diagnostik .