Overvåk appens tekniske kvalitet med Android-nøkkelstatistikk

For å få mer informasjon om en verdi, velg Se detaljer () ved siden av den. På neste skjermbilde kan du se gjennom

• terskler for dårlig funksjonalitet
• kategorireferansemålinger
• detaljerte sammenligninger av referansemålinger
  • Velg Endre gruppen med lignende apper nær toppen av siden, på kortet for sammenligning med lignende apper, for å endre en tilpasset gruppe med lignende apper. Når du har opprettet en tilpasset gruppe, kan du se resultatene for appen din sammenlignet med andre apper på Google Play som du velger.
• Verditrender over tid

Med verdier for ANR-frekvens får du en oversikt over kvaliteten på appen din. Disse verdiene beregnes ved å ta antall brukere du har med ANR-feil, og normalisere dem basert på appbruken. De rapporteres som en prosentandel av daglige aktive brukere. En daglig aktiv bruker defineres som en bruker som bruker appen i løpet av én dag på én enkelt enhet. Hvis en bruker bruker appen din på mer enn én enhet i løpet av én dag, bidrar hver enhet til antallet aktive brukere for den aktuelle dagen. Hvis flere brukere bruker den samme enheten på samme dag, telles dette som én aktiv bruker.

Det finnes tre verdier for ANR-frekvens:

• Brukeroppfattet ANR-frekvens: Prosentandelen av de daglige aktive brukerne som opplevde minst én brukeroppfattet ANR. En brukeroppfattet ANR er en ANR-feil som brukeren mest sannsynlig har merket. For øyeblikket telles bare ANR-feil for «sending av inndata fikk tidsavbrudd». Denne verdien er alltid lavere enn den totale ANR-frekvensen fordi den normaliseres av daglig bruk, men den teller ikke alle ANR-feil.
  Brukeroppfattet ANR-frekvens er en kjernestatistikk. Det betyr at den påvirker hvor synlig appen din er på Google Play. Den er viktig fordi ANR-feilene den teller, alltid oppstår når brukeren bruker appen, noe som forårsaker mest forstyrrelse.
• ANR-frekvens: Prosentandelen av daglige brukere som har opplevd minst én ANR-feil. Denne verdien omfatter ANR-feil som ikke er klassifisert som brukeroppfattet, men vi kan ikke garantere at disse ANR-feilene ikke berører brukerne.
• Multi-ANR-frekvens: Prosentandelen av daglige brukere som opplevde minst to ANR-feil. Denne verdien fremhever gjentakende problemer.

Løs problemer

ANR-feilene som bidrar til verdiene for ANR-frekvens, rapporteres på Krasj og ANR-feil-siden. Du kan filtrere etter brukeroppfattede ANR-feil på denne siden.

På nettstedet for Android-utviklere finner du veiledning om hvordan du diagnostiserer og fikser ANR-feil.

Med beregningene av krasjfrekvens får du en oversikt over kvaliteten på appen din. Disse verdiene beregnes ved å ta antallet brukere du har med krasjfeil, og normalisere dem basert på appbruken. De rapporteres som en prosentandel av daglige brukere. En daglig bruker defineres som en bruker som bruker appen i løpet av én dag på én enkelt enhet. Hvis en bruker har mer enn én enhet, telles brukeren mer enn én gang. Hvis for eksempel to brukere bruker appen i to dager på én enhet hver, fører det til fire daglige økter.

Det finnes tre verdier for krasjfrekvens:

• Brukeroppfattet krasjfrekvens: Prosentandelen av daglige brukere som opplevde minst ett brukeroppfattet krasj. Et brukeroppfattet krasj er et krasj som brukeren mest sannsynlig har merket. Dette kan for eksempel være krasj som skjer når appen din viser en aktivitet eller kjører som en forgrunnstjeneste. Denne verdien er alltid lavere enn den totale krasjfrekvensen fordi den normaliseres av daglig bruk, men den teller ikke alle krasj.
  Brukeroppfattet krasjfrekvens er en kjernestatistikk. Det betyr at den påvirker hvor synlig appen din er på Google Play. Den er viktig fordi krasjene den teller, alltid oppstår når brukeren samhandler med appen, noe som forårsaker mest forstyrrelse. Derfor bør du sørge for at appen din ikke overskrider terskelen for dårlig funksjonalitet for denne verdien.

• Krasjfrekvens: Prosentandelen av daglige brukere som opplevde minst ett krasj. Denne verdien omfatter krasj som ikke er klassifisert som brukeroppfattet, men vi kan ikke garantere at disse krasjene ikke berører brukerne.

• Multikrasjfrekvens: Prosentandelen av daglige brukere som opplevde minst to krasj. Denne verdien fremhever gjentakende problemer.

Løs problemer

På nettstedet for Android-utviklere finner du veiledning om hvordan du diagnostiserer og fikser krasj.

På siden Oppstartstid kan du se detaljer om når appen din starter tregt fra kald, lunken og varm systemtilstand. Oppstartstiden måler tiden det tar fra en bruker åpner appen din til de første bildene dukker opp på skjermen. Dette kalles også «tid til første visning».

Det kan hende appen ikke er klar til bruk etter dette, for eksempel hvis appen har flere innlastingsskjermer.

Informasjon om datainnsamling

• Oppstartstider registreres bare når en bruker utløser en aktivitet.
  • Eksempel: For tastaturapper er oppstartstiden lik oppstartstiden for følgeappen.
• Hvis en app starter flere ganger på samme dag fra den samme systemtilstanden, registreres den høyeste oppstartstiden for den dagen.
• Oppstartstider registreres når det første skjermbildet i appen er lastet inn fullstendig, selv om det ikke er en skjerm der brukeren gjør noe aktivt.
  • Eksempel: Hvis en app starter med en splash-skjerm, er oppstartstiden lik tiden som kreves for å vise splash-skjermen.

Nøkkelstatistikk

• Berørte økter: prosentandelen av økter der brukerne har opplevd en treg oppstart for hver systemtilstand:
  • Treg kald oppstart: fem sekunder eller mer
  • Treg lunken oppstart: to sekunder eller mer
  • Treg varm oppstart: ett sekund eller mer
• Antall økter: omtrentlig antall registrerte økter.
• 90./99. persentil: 10 % / 1 % av daglige økter der brukerne har opplevd en treg oppstart av appen din.

Løs problemer

Hvis appen din har et høyt antall trege oppstartstider, kan du gå til nettstedet for Android-utviklere for å få anbefalte løsninger.

Grunner til at dette er viktig

Ved å bruke trege økter kan du få en forståelse av hvor god bildefrekvensen i spillet ditt er. Bildefrekvensen påvirker hvor jevnt spillet føles for brukerne.

Forstå dataene for appen din

På Trege økter-siden ser du informasjon om prosentandelen av daglige økter der brukerne opplevde at mer enn 25 % av bildene ble vist saktere enn enten 30 eller 20 bilder per sekund, avhengig av hvilken referansemåling du velger. Du kan også se fordelingen av økter etter bildefrekvens for spillet ditt. (Bildefrekvensen på øktnivå måles i den 75. persentilen, noe som betyr at 75 % av bildene oppnår minst denne bildefrekvensen.)

De fleste spill på Google Play bør ha minst 30 bilder per sekund. Dette gir brukerne en rimelig opplevelse, uavhengig av hva slags spill de spiller (men noen brukere foretrekker minst 60 bilder per sekund – spesielt på toppmodeller). Følg med på beregningen for frekvensen av trege økter (30 bilder per sekund) for å sørge for at du oppnår denne verdien. Vær oppmerksom på at denne beregningen bare omfatter økter der mer enn 25 % av bildene ikke oppnår 30 bilder per sekund, så den har noe toleranse for variasjon i bildefrekvensen.

Selv om 30 bilder per sekund gir en rimelig opplevelse, kan det av og til være lurt å redusere bildefrekvensen under dette, eller det kan hende at brukerne vil spille spillet på telefoner som ikke støtter 30 bilder per sekund. I slike scenarioer bør minst 75 % av bildene i økten fortsatt oppnå minst 20 bilder per sekund. Følg med på beregningen for frekvensen av trege økter (20 bilder per sekund) for å sørge for at du oppnår denne verdien.

Android-nøkkelstatistikken rapporterer trege økter (30 bilder per sekund) og trege økter (20 bilder per sekund) for hver enhet samt for alle enheter og økter. Bruk den overordnede beregningen for å forstå den generelle brukeropplevelsen, men vær også oppmerksom på ytelsen per enhet. Etter hvert begynner Play å styre brukerne bort fra spill som ikke kan oppnå 20 bilder per sekund på telefonene de bruker.

Nøkkelstatistikken begynner bare å overvåke bildefrekvensen når spillet ditt har kjørt i 1 minutt.

Informasjon om datainnsamling

Beregningen av trege økter er basert på data som er samlet inn fra SurfaceFlinger. Bildefrekvensen for en økt anslås basert på tiden mellom bildene som vises på plattformer appen eier, og omfatter bilder som gjengis av OpenGL, Vulkan og Android UI-verktøysettet. Denne beregningen er foreløpig bare tilgjengelig for spill.

Data om bildefrekvens for trege økter samles inn for enheter som har Android 9 eller nyere.

Dataene i oversikten

• Representativ bildefrekvens: Bildefrekvensen for spillet ditt på enheter med Android 9 eller nyere beregnet ved den 75. persentilen. Dette betyr at 75 % av øktene hadde denne bildefrekvensen eller en raskere bildefrekvens 75 % av tiden.
• Frekvens av trege økter over tid: En tidsserie som viser prosentandelen av økter som var trege økter.
• Distribusjon av bildefrekvens: Histogram som viser den 75. persentilen for bildefrekvens for flere økter. Dette betyr at 75 % av bildene i økten var raskere enn bildefrekvensen som ble brukt i økten.

Løs problemer

Hvis appen din har mange trege økter, kan du gå til nettstedet for Android-utviklere for å se anbefalte løsninger.

Forstå dataene for appen din

På siden «For mange trege bilder» ser du informasjon om prosentandelen av daglige økter der brukerne opplevde at mer enn 50 % av skjermbildene ikke nådde enhetens frist for gjengivelse. Brukerinteraksjoner med appen din skal kjøre med 60 bilder per sekund uten at skjermbilder hoppes over eller forsinkes.

Informasjon om datainnsamling

Google registrerer gjengivelsestiden for hvert bilde som gjengis av appen din når UI Toolkit-rammeverket brukes. Bilder som er gjengitt direkte ved bruk av OpenGL eller Vulkan, samles ikke inn.

Dataene i oversikten

Når du velger en rad, ser du dataene inndelt i persentiler.

• Berørte økter: prosentandelen av daglige økter der brukerne opplevde at minst 50 % av bildene hadde en gjengivelsestid på mer enn 16 ms. En daglig økt er en dag når appen din blir brukt. Hvis for eksempel to brukere bruker appen i to dager, fører det til fire daglige økter.
• Antall økter: omtrentlig antall registrerte økter.
• 90./99. persentil: 90 % / 99 % av det totale antallet skjermbilder hadde en gjengivelsestid under tallet som vises. Disse tallene er basert på alle innsamlede skjermbilder.

Når du klikker på en oppføring i tabellen, ser du diagrammet «Fordeling av UI-gjengivelsestid». Når du går gjennom diagrammet, må du sørge for at gjengivelsestiden for de fleste bildene i appen er 16 ms eller mindre.

Dataene under diagrammet viser gjengivelsesytelsen til appen din og kan hjelpe deg med å finne rotårsaken til eventuelle problemer med gjengivelsestiden. Hvis for eksempel prosentandelen «Høy inngangsforsinkelse» er høy, kan det være lurt å se på appkoden som håndterer inndata fra brukerne. Gå til testing av UI-ytelsen for å få mer informasjon om disse beregningene.

• Tapte Vsync-hendelser: antall tapte Vsync-hendelser delt på antall skjermbilder, for alle skjermbilder som gjengis på mer enn 16 ms.
• Høy inngangsforsinkelse: antall inndatahendelser som tar mer enn 24 ms, delt på antall skjermbilder, for alle skjermbilder som gjengis på mer enn 16 ms.
• Treg UI-tråd: antall ganger UI-tråden bruker mer enn 8 ms på å fullføres, delt på antall skjermbilder, for alle skjermbilder som gjengis på mer enn 16 ms.
• Trege gjengivelseskommandoer: antall ganger det tok mer enn 12 ms å sende gjengivelseskommandoer til GPU-en, delt på antall skjermbilder, for alle skjermbilder som gjengis på mer enn 16 ms.
• Trege punktgrafikkopplastinger: antall ganger det tok mer enn 3,2 ms å laste opp punktgrafikk til GPU-en, delt på antall skjermbilder, for alle skjermbilder som gjengis på mer enn 16 ms.

Løs problemer

Hvis appen din har et høyt antall bilder med gjengivelsestid på mer enn 16 ms, går du til nettstedet for Android-utviklere for å se anbefalte løsninger.

Forstå dataene for appen din

På siden «For mange trege bilder» ser du informasjon om prosentandelen av daglige økter der brukerne opplevde at mer enn 50 % av skjermbildene ikke nådde enhetens frist for gjengivelse. Brukerinteraksjoner med appen din skal kjøre med 60 bilder per sekund uten at skjermbilder hoppes over eller forsinkes.

Informasjon om datainnsamling

Google registrerer gjengivelsestiden for hvert bilde som gjengis av appen din når UI Toolkit-rammeverket brukes. Bilder som er gjengitt direkte ved bruk av OpenGL eller Vulkan, samles ikke inn.

Dataene i oversikten

Når du velger en rad, ser du dataene inndelt i persentiler.

• Berørte økter: prosentandelen av daglige økter der brukerne opplevde at minst 50 % av bildene hadde en gjengivelsestid på mer enn 16 ms. En daglig økt er en dag når appen din blir brukt. Hvis for eksempel to brukere bruker appen i to dager, fører det til fire daglige økter.
• Antall økter: omtrentlig antall registrerte økter.
• 90./99. persentil: 90 % / 99 % av det totale antallet skjermbilder hadde en gjengivelsestid under tallet som vises. Disse tallene er basert på alle innsamlede skjermbilder.

Når du klikker på en oppføring i tabellen, ser du diagrammet «Fordeling av UI-gjengivelsestid». Når du går gjennom diagrammet, må du sørge for at gjengivelsestiden for de fleste bildene i appen er 16 ms eller mindre.

Dataene under diagrammet viser gjengivelsesytelsen til appen din og kan hjelpe deg med å finne rotårsaken til eventuelle problemer med gjengivelsestiden. Hvis for eksempel prosentandelen «Høy inngangsforsinkelse» er høy, kan det være lurt å se på appkoden som håndterer inndata fra brukerne. Gå til testing av UI-ytelsen for å få mer informasjon om disse beregningene.

• Tapte Vsync-hendelser: antall tapte Vsync-hendelser delt på antall skjermbilder, for alle skjermbilder som gjengis på mer enn 16 ms.
• Høy inngangsforsinkelse: antall inndatahendelser som tar mer enn 24 ms, delt på antall skjermbilder, for alle skjermbilder som gjengis på mer enn 16 ms.
• Treg UI-tråd: antall ganger UI-tråden bruker mer enn 8 ms på å fullføres, delt på antall skjermbilder, for alle skjermbilder som gjengis på mer enn 16 ms.
• Trege gjengivelseskommandoer: antall ganger det tok mer enn 12 ms å sende gjengivelseskommandoer til GPU-en, delt på antall skjermbilder, for alle skjermbilder som gjengis på mer enn 16 ms.
• Trege punktgrafikkopplastinger: antall ganger det tok mer enn 3,2 ms å laste opp punktgrafikk til GPU-en, delt på antall skjermbilder, for alle skjermbilder som gjengis på mer enn 16 ms.

Løs problemer

Hvis appen din har et høyt antall bilder med gjengivelsestid på mer enn 16 ms, går du til nettstedet for Android-utviklere for å se anbefalte løsninger.

På sidene Delvise oppvekkingslåser som står fast og Delvise oppvekkingslåser som står fast (i bakgrunnen) ser du delvise oppvekkingslåser som er utløst av appen din gjennom PowerManager-klassen. Delvise oppvekkingslåser sikrer at prosessoren kjører, men at skjermen og bakgrunnslyset for tastaturet kan slås av.

Informasjon om datainnsamling

• Av personvernhensyn blir ID-merker for delvise oppvekkingslås-hendelser anonymisert.
• Data om delvise oppvekkingslåser samles inn når enheten ikke lades og skjermen er av.
• Data for delvise oppvekkingslåser (i bakgrunnen) samles bare inn når appen kjører i bakgrunnen.
• Google beregner den maksimale varigheten for delvise oppvekkingslåser per batteriøkt for å vise hvor mange økter som berøres av en lang oppvekkingslås. Hvis en bruker for eksempel utløser oppvekkingslåser på to timer, bruker Google en maksimal oppvekkingslås-verdi på én time.
• For apper som angir sharedUserId i manifestfilen: Du ser bare data hvis maksimalt én app med samme sharedUserId er installert.

Nøkkelstatistikk

• Berørte økter: prosentandelen av batteriøkter der brukerne opplevde minst én oppvekkingslås på mer enn én time.
• Antall økter: omtrentlig antall registrerte økter.
• 90./99. persentil: 10 %/1 % av daglige økter der brukerne opplevde delvise oppvekkingslåser som varte lenger enn tallet som vises.
• Terskel for dårlig funksjonalitet: Hvis appen din viser en forekomstfrekvens som er lik eller høyere enn terskelen som er vist, er den blant de nederste 25 % av de 1000 mest populære appene på Google Play (etter antall installasjoner).

Løs problemer

Hvis appen din har mange delvise oppvekkingslåser som står fast, går du til nettstedet for Android-utviklere for å se anbefalte løsninger.

På Overdreven vekking-siden ser du Alarm Manager-vekkingene som er utløst av appen din. Du ser vekkingsdata for klassene ELAPSED_REALTIME_WAKEUP eller RTC_WAKEUP.

Informasjon om datainnsamling

• Av personvernhensyn blir ID-merker for vekking anonymisert.
• Vekkinger samles inn når enheten ikke lades.
• For å generere en normalisert beregning blir antall vekkinger sammenlignet med tiden enheten går på batteri. Google beregner antall oppvekkingshendelser per bruker per time for å vise hvor mange brukere som berøres av en høy oppvekkingsfrekvens.
• For apper som angir sharedUserId i manifestfilen: Du ser bare data hvis maksimalt én app med samme sharedUserId er installert.

Nøkkelstatistikk

• Berørte økter: prosentandelen av batteriøkter der brukerne opplevde mer enn 10 vekkinger per time. En batteriøkt er en aggregering av alle batterirapporter som er mottatt i løpet av en periode på 24 timer. På Android 10 henviser batterirapporter til intervallet mellom to batteriladinger, enten fra under 20 % til over 80 % eller fra en hvilken som helst verdi og opp til 100 %. På Android 11 eller nyere henviser batterirapporter til en fast periode på 24 timer. Google samler bare inn data når enheten er koblet fra laderen.
• Antall økter: omtrentlig antall registrerte økter.
• 90./99. persentil: 10 % / 1 % av daglige økter der brukerne opplevde flere vekkinger per time enn tallet som vises.
• Terskel for dårlig funksjonalitet: Hvis appen din viser en forekomstfrekvens som er lik eller høyere enn terskelen som er vist, er den blant de nederste 25 % av de 1000 mest populære appene på Google Play (etter antall installasjoner).

Løs problemer

Hvis appen din har mange vekkinger, går du til nettstedet for Android-utviklere for å se anbefalte løsninger.

På siden Uforholdsmessig mye Wi-Fi-skanning (i bakgrunnen) ser du når Wi-Fi-skanninger resulterer i høyt batteriforbruk.

Informasjon om datainnsamling

Data om wifi-skanning samles inn når enheten ikke lades og appen kjører i bakgrunnen.

Nøkkelstatistikk

• Berørte økter: prosentandelen av batteriøkter der brukerne opplevde mer enn fire wifi-skanninger per time.
• Antall økter: omtrentlig antall registrerte økter.
• 90./99. persentil: 10 % / 1 % av daglige økter der brukerne opplevde flere wifi-skanninger i bakgrunnen per time enn tallet som vises.

Løs problemer

Hvis appen din har mye Wi-Fi-skanning i bakgrunnen, går du til nettstedet for Android-utviklere for å se anbefalte løsninger.

På siden Overdreven nettverksbruk ser du når mye nettverksdata er tilknyttet en bakgrunnstjeneste. Når bruk av mobilnettverk skjer i bakgrunnen, har ikke brukerne enkel tilgang til kontroller for å stoppe dataoverføringen.

Informasjon om datainnsamling

Data om mobilnettverksbruk samles inn når enheten ikke lades og appen kjører i bakgrunnen.

Nøkkelstatistikk

• Berørte økter: prosentandelen av batteriøkter der brukerne opplevde mer enn 50 MB med nettverksbruk i bakgrunnen per dag.
• Antall økter: omtrentlig antall registrerte økter.
• 90./99. persentil: 10 % / 1 % av daglige økter der brukerne opplevde mer nettverksbruk i bakgrunnen per dag enn tallet som vises.

Løs problemer

Hvis appen din har høy nettverksbruk i bakgrunnen, går du til nettstedet for Android-utviklere for å se anbefalte løsninger.

På Avvisning av tillatelser-siden kan du se detaljer om prosentandelen av daglige tillatelsesøkter der brukerne avviste tillatelser. En daglig tillatelsesøkt er en dag der appen din har bedt om minst én tillatelse fra brukeren.

Informasjon om datainnsamling

Data om avvisning av tillatelser registreres når brukeren svarer på forespørsler om tillatelser i appen din.

Nøkkelstatistikk

• Avslag: prosentandelen av daglige tillatelsesøkter der brukere avslo å gi tillatelser.
• Ikke spør igjen: prosentandelen av daglige tillatelsesøkter der brukerne avslo å gi tillatelser ved å velge Ikke spør igjen.
• Totalt antall økter: omtrentlig antall registrerte økter.

Løs problemer

Hvis appen din har svært mange avvisninger av tillatelser, kan du gå til nettstedet for Android-utviklere for å få anbefalte løsninger.

Google Play har definert terskler for dårlig funksjonalitet for brukeroppfattet ANR-frekvens:

• Dårlig funksjonalitet generelt: Minst 0,47 % av daglige aktive brukere opplever en brukeroppfattet ANR-feil på alle enhetsmodeller.

• Dårlig funksjonalitet på enheten: Minst 8 % av daglige aktive brukere opplever en brukeroppfattet ANR-feil for én enkelt enhetsmodell.

For å forbedre ANR-frekvensen må du fikse de underliggende ANR-gruppene som rapporteres på Krasj og ANR-feil-siden. Jo høyere antallet berørte brukere er, desto mer bidrar gruppen til ANR-frekvensen.

Hvis spesifikke aspekter ved enhetens maskinvare eller programvare kan bidra til ANR-frekvensen, varsler Android-nøkkelstatistikk deg. Du kan også utforske tilknytningene selv på oversiktssiden for rekkevidde og enheter (Utgave > Rekkevidde og enheter > Oversikt).

Google Play har definert terskler for dårlig funksjonalitet for brukeroppfattet krasjfrekvens:

• Dårlig funksjonalitet generelt: Minst 1,09 % av daglige brukere opplever et brukeroppfattet krasj på alle enhetsmodeller.

• Dårlig funksjonalitet på enheten: Minst 8 % av daglige brukere opplever et brukeroppfattet krasj på én enkelt enhetsmodell.

For å forbedre krasjfrekvensen må du fikse de underliggende krasjgruppene som er rapportert på Krasj og ANR-feil-siden. Jo høyere antallet berørte brukere er, desto mer bidrar gruppen til krasjfrekvensen.

Hvis spesifikke aspekter ved enhetens maskinvare eller programvare kan bidra til krasjfrekvensen, varsler Android-nøkkelstatistikk deg. Du kan også utforske tilknytningene selv på oversiktssiden for rekkevidde og enheter (Utgave > Rekkevidde og enheter > Oversikt).