Planera och mäta appprestanda

Användarna förväntar sig att deras appar ska förbli dynamiska, kännas naturliga och inte tömma batteriet. Tekniskt sett är prestanda ett icke-funktionellt krav, men att behandla prestanda som en funktion hjälper dig att uppfylla användarnas förväntningar. Ange mål och mäta resultat – det här är viktiga faktorer. Fastställ dina prestandakritiska scenarier, definiera vad bra prestanda innebär och mät sedan tidigt och ofta under projektets livscykel för att vara säker på att du når dina mål.

Ange mål

Användarupplevelsen är ett grundläggande sätt att definiera bra prestanda. En apps starttid kan påverka en användares uppfattning om dess prestanda. En användare kan anse att en appstarttid på mindre än en sekund är utmärkt, mindre än fem sekunder för att vara bra och större än fem sekunder för att vara dålig.

Andra mått har mindre uppenbar inverkan på användarupplevelsen, till exempel minne. Sannolikheten för att en app avslutas när den är pausad eller inaktiv ökar med mängden minne som den aktiva appen använder. Hög minnesanvändning försämrar upplevelsen för alla appar i systemet, så det är rimligt att ha ett mål för minnesförbrukning.

Ange initiala mål som är specifika och mätbara. De bör delas in i tre kategorier:

  • Tid – hur lång tid det tar för användare eller appen att slutföra uppgifter
  • Fluidity – den hastighet och kontinuitet som appen ritar om sig själv som svar på användarinteraktion
  • Effektivitet – hur väl appen sparar systemresurser, inklusive batteridrift

Time

Tänk på godkända intervall av förfluten tid (interaktionsklasser) för användare att slutföra sina uppgifter.

Interaktionsklass Användarens uppfattning Ideal Högsta Examples
Snabbt Minimalt märkbar fördröjning 100 ms 200 ms Visa appfältet; tryck på en knapp (första steget)
Typiska Snabb, men inte snabb 300 ms 500 ms Ändra storlek; semantisk zoom
Responsiv Inte snabbt, men känns responsivt 500 ms 1 sekund Gå till en annan sida. återuppta appen
Launch Konkurrenserfarenhet 1 sekund 3 sekunder Starta appen för första gången
Kontinuerlig Känns inte längre responsivt 500 ms 5 sekunder Ladda ned en fil från Internet
Fångenskap Lång; användaren kan navigera bort 500 ms 10 sekund Installera flera appar från Store

Tilldela interaktionsklasser till appens prestandascenarier. För varje scenario tilldelar du appens punkt-i-tid-referens, en del av användarupplevelsen och en interaktionsklass.

Smidighet

Specifika mätbara fluiditetsmål för din app kan vara:

  • Inga avbrott i skärmuppdateringen (störningar)
  • Animeringar återges med 60 bildrutor per sekund (FPS)
  • När en användare panorerar eller rullar visar appen 3–6 sidor innehåll per sekund

Effektivitet

Specifika mätbara effektivitetsmål för din app kan vara:

  • Appens CPU-procentandel ligger på eller under ett målvärde och minnesanvändningen i MB ligger vid eller under ett mål hela tiden
  • När appen är inaktiv är processor- och minnesanvändningen minimal
  • Din app kan användas aktivt under ett målantal timmar på batteridrift

Utforma din app för prestanda

Använd dina prestandamål för att påverka appens design. Tänk på följande:

Användargränssnitt

  • Maximera parsning och inläsningstid och minneseffektivitet för varje sida genom att optimera XAML-markering. Skjut upp inläsning av användargränssnitt och kod tills det behövs.
  • För ListView och GridViewgör du alla objekt till samma storlek och använder så många optimeringstekniker som möjligt.
  • Deklarera användargränssnittet i markering i stället för att konstruera det imperativt i kod.
  • Fördröj skapandet av användargränssnittselement tills användaren behöver dem med hjälp av attributet x:Load .
  • Föredrar temaövergångar och animeringar till storyboardade animeringar. Bildrutebaserade animeringar kräver att skärmen uppdateras kontinuerligt och håller processorn och grafikpipelinen aktiva.
  • Läs in bilder med en storlek som är lämplig för den vy som du presenterar dem i.

CPU, minne och ström

  • Schemalägg arbete med lägre prioritet på trådar med lägre prioritet. Se Asynkron programmering och klassen DispatcherQueue .
  • Minimera appens minnesfotavtryck genom att frigöra dyra resurser (till exempel media) när de inte behövs.
  • Undvik minnesläckor genom att avregistrera händelsehanterare och avreferera gränssnittselement när det är möjligt.
  • För batterieffektivitet bör du vara försiktig med hur ofta du söker efter data, frågar en sensor eller schemalägger arbete på processorn när den är inaktiv.

Dataåtkomst

  • Om möjligt, förhandshämta innehåll.
  • Lagra i cacheminnet innehåll som är kostsamt att komma åt.
  • För cachemissar visar du ett platshållargränssnitt så snabbt som möjligt som anger att appen fortfarande läser in innehåll.

Instrument för prestanda

När du kodar lägger du till kod som loggar meddelanden och händelser vid vissa tidpunkter medan appen körs. Senare kan du använda profileringsverktyg som Windows Performance Recorder och Windows Analyzátor výkonu (båda ingår i Windows Performance Toolkit) för att skapa och visa en rapport om appens prestanda.

Windows tillhandahåller loggnings-API:er som backas upp av händelsespårning för Windows (ETW) som erbjuder en omfattande lösning för händelseloggning och spårning. API:erna i namnområdet Windows.Foundation.Diagnostics omfattar klasserna FileLoggingSession, LoggingActivity, LoggingChannel och LoggingSession.

// using Windows.Foundation.Diagnostics;

LoggingChannel myLoggingChannel = new LoggingChannel("MyLoggingChannel");
myLoggingChannel.LogMessage("Here's my logged message.", LoggingLevel.Information);

Så här loggar du start- och stopphändelser under en viss tidsperiod:

LoggingChannel myLoggingChannel = new LoggingChannel("MyLoggingChannel");
LoggingActivity myLoggingActivity;

using (myLoggingActivity = new LoggingActivity("MyLoggingActivity", myLoggingChannel))
{
    // A start event is logged when the activity begins.
    // Add code here to do something of interest.
}
// An end event is logged when the activity ends.

Testa och mäta mot prestandamål

Använd dessa tekniker och verktyg för att testa hur din app står sig mot dina prestandamål:

  • Testa mot en mängd olika maskinvarukonfigurationer, inklusive stationära datorer, bärbara datorer, ultrabooks och surfplattor.
  • Testa mot en mängd olika skärmstorlekar. Bredare skärmar visar mer innehåll, vilket kan påverka prestanda negativt.
  • Eliminera så många testvariabler som möjligt:
    • Inaktivera bakgrundsappar på testenheten.
    • Bygg din app i Release-konfigurationen innan du distribuerar den till testenheten.
    • Kör appen flera gånger för att eliminera slumpmässiga testvariabler och säkerställa konsekventa mätningar.
  • Testa för minskad strömtillgänglighet. Användarnas enheter kan ha betydligt mindre ström än utvecklingsdatorn.
  • Använd en kombination av verktyg som Visual Studio diagnostikverktyg och Windows Analyzátor výkonu för att mäta appprestanda.

Svara på prestandatestresultat

När du har analyserat prestandatestresultatet kontrollerar du om det behövs några ändringar:

  • Ska du ändra dina beslut om appdesign eller optimera koden?
  • Ska du lägga till, ta bort eller ändra instrumentation i koden?
  • Bör du ändra dina prestandamål?

Om det behövs ändringar gör du dem och återgår till instrumentering eller testning.

Optimize

Optimera endast de prestandakritiska kodsökvägarna i din app – de där mest tid spenderas. Profilering anger vilka områden dessa är. Ofta finns det en kompromiss mellan bra designmetoder och kod som presterar med högsta optimering. Prioritera utvecklarproduktivitet och bra programvarudesign inom områden där prestanda inte är ett problem.

Relaterat innehåll

  • Last updated on