Latens og junk med Perfetto på Android: en komplett guide

Når en Android-app føles treg, hakker eller har hakkete animasjoner (deaktiver systemanimasjoner)Det lurer nesten alltid en skjult synder i bakgrunnen: latens og den fryktede juksen. Android tilbyr flere diagnostiske verktøy, men et av de kraftigste og mest fleksible er perfetto, kombinert med den klassiske kommandoen dumpsys og datakilder som f.eks. ftrace, atrace o heapprofdÅ forstå hvordan du bruker dem riktig lar deg gå fra den vage følelsen av at «appen min oppfører seg rart» til å ha konkrete tall, spor og årsaker.

I denne artikkelen skal vi gå gjennom det rolig, men direkte, hvordan virker det perfetto Hvilke bruksmoduser har den på Android, hvilke datakilder kan den aktivere, og hvordan utfyller den andre nøkkelkommandoer som dumpsys gfxinfo, dumpsys meminfo o dumpsys batterystatsTanken er å gi deg en fullstendig oversikt over alt du kan måle og hvordan du bruker det til å optimalisere latens, eliminere støt og for øvrig forbedre minne-, nettverks- og batteriforbruk.

Hva er Perfetto, og hvorfor er det så nyttig for latens og janking?

perfetto Det er et ytelsessporingsverktøy integrert i Android. som vanligvis kalles fra datamaskinen ved hjelp av Android Debug Bridge (ADB) med kommandoer som adb shell perfetto ...Dens oppgave er å samle inn lavnivåinformasjon om hva som skjer på enheten: kjerneaktiviteter, brukerannoteringer, minnebruk, prosessstatistikk osv., alt i et sporingsformat som du deretter kan analysere med visningsprogrammer som nettstedet til. perfetto.dev.

Perfetto benytter seg av flere spesialiserte «datakilder», blant annet står:

• ftrace, som fanger opp kjernehendelser (trådplanlegging, filsystem osv.).
• atrace, fokusert på annoteringer fra brukerområdet for tjenester og applikasjoner.
• heapprofd, fokusert på å sample naturlig minnebruk i tjenester og apper.

Ved å kombinere disse kildene på riktig måteDu kan registrere nøyaktig den informasjonen du trenger for å spore problemer med UI-forsinkelse, rammer som er hoppet over, CPU-topper eller I/O-relaterte låsinger. UFS lagring.

Grunnleggende syntaks for Perfetto og driftsmoduser

Perfetto kan brukes i to hovedmoduser: lett og normalBegge kalles fra ADB, men de er svært forskjellige i hvordan de konfigurerer hva som plottes og hvordan det lagres.

Den generelle ideen er alltid den samme: utfør en kommando adb shell perfetto spesifiserer varighet, bufferstørrelse, datakilder og utdatasporingsfil. Den resulterende filen genereres vanligvis i henhold til protokollformatet. trace.proto fra AOSP, som du deretter kan åpne i Perfettos analyseverktøy.

Generelle alternativer når du aktiverer Perfetto

Uansett modus (lys eller normal)Det finnes en rekke vanlige flagg som styrer hvordan opptak utføres, hva som gjøres med den genererte filen, og hvordan den integreres med varslings- eller eksterne opplastingssystemer:

• --background o -d: lager perfetto Avslutt kommandolinjegrensesnittet og fortsett opptaket i bakgrunnen.
• --background-wait o -DLigner på den forrige, men venter opptil 30 sekunder på at alle datakilder bekrefter at de har startet. Avslutningskoden vil være 0 hvis alt fungerer som det skal, og alt annet enn 0 hvis det er en feil eller tidsavbrudd.
• --alert-id, --config-id, --config-uid y --subscription-id: identifikatorer som kobler sporingen til varsler eller utløserkonfigurasjoner definert i systemet, nyttig i automatiserte overvåkingsscenarier.
• --out OUT_FILE o -o OUT_FILE: fullstendig sti der sporingsfilen skal lagres, eller - hvis du foretrekker at jeg går til stdoutEn katalog brukes vanligvis som /data/misc/perfetto-traces.
• --upload: når opptaket er fullført, lever sporingsfilen til pakken spesifisert i meldingen IncidentReportConfig i prototypekonfigurasjonen.
• --no-guardrails y --reset-guardrails: De kontrollerer sikkerhetsmekanismene og ressursbegrensningene når automatisk opplasting er aktivert (--upload), designet for testing og ikke så mye for produksjon.
• --rsave-for-bugreport: hvis opptaket har en bugreport_score større enn 0, lagrer sporet til en fil og viser banen når den er fullført, for enkelt vedlegg i feilrapporter.
• --query y --query-rawDe spør om statusen til sporingstjenesten. Den første gir lesbar utdata, den andre returnerer det protokollkodede innholdet av tracing_service_state.proto.
• --help o -h: Skriver ut verktøyets innebygde hjelp.

Perfettos lysmodus: rask og lik Systrace

Perfettos lysmodus er designet for raske sporveldig likt hvordan det ble brukt historisk sett systraceDen lar deg velge bare et grunnleggende delsett av kilder: i hovedsak atrace y ftraceog det er nyttig ved siden av apper for å optimalisere ytelsen.

Typisk syntaks i lettvektsmodus Det er noe sånt som dette:

adb shell perfetto ... --out FILE

Blant de mest relevante spesifikke alternativene for lysmodus Vi finner:

• --time TIME o -t TIME: sporingens varighet i sekunder, minutter eller timer. For eksempel, --time 1m Ta opp i ett minutt. Hvis ingenting er spesifisert, brukes 10 sekunder som standard.
• --buffer SIZE o -b SIZE: størrelsen på den sirkulære bufferen i minnet. Standardverdien er vanligvis noe sånt som --buffer 32mb.
• --size SIZE o -s SIZEMaksimal filstørrelsesgrense på disk. Hvis ikke konfigurert, kan Perfetto bare skrive til minnebufferen.
• --app o -a: navnet på Android-apppakken som skal brukes i annoteringer av atrace.

Etter disse flaggene er det listet opp «hendelsesspesifikasjoner»som bestemmer hvilke kategorier eller hendelser som skal registreres:

• ATRACE_CATkategorier av atrace som du vil aktivere (for eksempel wm (for WindowManager). En typisk kommando ville være: adb shell perfetto --out FILE wm.
• FTRACE_GROUP/FTRACE_NAME: spesifikke hendelser av ftraceSom sched/sched_switchDu kan kjøre: adb shell perfetto --out FILE sched/sched_switch.

Perfettos normale modus: maksimal kontroll og flere kilder

Perfettos normale modus er mye kraftigere og mer konfigurerbar.I stedet for å sende individuelle kategorier, får du en konfigurasjonsfil (en proto) som beskriver i detalj hvilke datakilder som skal aktiveres, hvordan du skal sample, hvilke buffere som skal brukes osv.

Den vanlige syntaksen for normal modus er:

adb shell perfetto --config CONFIG_FILE --out FILE

De spesifikke flaggene som er viktige i denne modusen er:

• --config CONFIG_FILE o -c CONFIG_FILE: sti til konfigurasjonsfilen som følger skjemaet til trace_config.proto i AOSP. Innenfor denne prototypen finnes elementer som TraceConfig y DataSourceConfig (definert i data_source_config.proto) for å velge og parameterisere datakildene.
• --txt: indikerer at konfigurasjonsfilen er i tekstformat pbtxt i stedet for binær. Veldig praktisk for lokal prototyping, men ikke anbefalt som et endelig produksjonsformat.

Perfetto-kompatible datakilder

Perfettos sanne styrke ligger i de ulike ressursene den kan muliggjøre.Hver enkelt er konfigurert fra prototypen gjennom en blokk med DataSourceConfigOg avhengig av enheten, Android-versjonen og kjernen, vil du ha flere eller færre alternativer tilgjengelig.

Kjernehendelser med ftrace

Kilden ftrace Perfetto lar deg fange opp interne kjernehendelsersom er rent gull når du vil forstå hvorfor en tråd ikke planlegger i tide, eller hva som blokkerer CPU-en til enhver tid.

Å aktivere ftrace fra innstillinger feltet må defineres ftrace_config innenfor DataSourceConfig...ved å velge hvilke spesifikke hendelser vi ønsker å spore. Noen vanlige eksempler knyttet til prosessplanlegging er:

• sched/sched_switch
• sched/sched_wakeup
• sched/sched_wakeup_new
• sched/sched_process_exec
• sched/sched_process_exit
• sched/sched_process_fork
• sched/sched_process_free
• sched/sched_process_hang
• sched/sched_process_wait

Filsystemhendelser og tilbakesporingsannoteringer kan også aktiveres.slik at et enkelt spor fanger opp både kjernedata og hendelser på høyere nivå. Listen over faktiske hendelser vil alltid avhenge av enheten og kjernen, så det anbefales å konsultere de relevante konfigurasjonsprotokollene.

Prosess- og systemstatistikk

En annen veldig praktisk kilde er prosessstatistikk og selve systemet.Det tillater periodiske tellere av ressursbruk, både globalt og per individuell prosess, ideelt for å korrelere CPU- eller minnetopper med spesifikke junk-hendelser og med bakgrunnsapper.

For å bruke den, må du konfigurere feltene. process_stats_config y sys_stats_config innenfor DataSourceConfigDataene som innhentes inkluderer blant annet informasjon om CPU-tid, minnebruk og andre målinger som kan variere avhengig av enhet og operativsystemversjon.

Innfødte minneprofiler med heapprofd

heapprofd Det er nøkkelbrikken når du trenger å forstå bruken av innebygd minne. av applikasjonen eller systemtjenestene dine. Det fungerer ved å ta samplinger, og generere profiler som indikerer hvilke deler av koden som reserverer minne.

Å tenne heapprofd i et spor av Perfetto Du må fylle ut seksjonen heapprofd_config de DataSourceConfig. Resultatet er ProfilePackets med informasjon om kallestakken, inkludert Java-rammeverk når tilgjengelig. Det er en kraftig måte å jakte på native lekkasjer eller ineffektive allokeringsmønstre.

Offentlig dokumentasjon i perfetto.dev Den går inn på hvordan du konfigurerer disse profilene, filtrerer etter spesifikke prosesser, justerer samplingsfrekvensen osv., slik at du kan skreddersy kostnaden for instrumentasjonen til detaljnivået du trenger.

Andre tilleggsdatakilder

I tillegg til det ovennevnte er flere kilder tilgjengelige avhengig av enhet og Android-versjon.Noen er rettet mot energi, andre mot nettverket eller mot mer spesifikke rammeverksmålinger. For å se dem i detalj, må du se gjennom de ulike konfigurasjonsskjemaene for Perfetto-datakilder som er publisert på AOSP.

Uansett gjentar mønsteret seg alltidDu velger kilden, du konfigurerer blokken DataSourceConfig i prototypen av TraceConfig og du starter sporingen med perfettoDeretter analyserer du den resulterende filen med visualiseringsverktøyene.

dumpsys: den perfekte pluginen for å måle latens og ytelse

Selv om Perfetto er stjernen for lavnivåsporveteranverktøyet dumpsys Det er fortsatt viktig når du ønsker diagnostikk på høyt nivå, gruppert etter systemtjeneste: inngang, grafikk, nettverk, batteri, minne osv.

dumpsys Den kjører på Android-enheten. og den påkalles fra ADB med kommandoer som adb shell dumpsysHvis du kjører den uten parametere, dumper den informasjon fra alle systemtjenester, noe som vanligvis er for mye. Det er best å spesifisere den spesifikke tjenesten du er interessert i for å fokusere utelukkende på den delen.

Generell syntaks for dumpsys-kommandoen

Den generelle måten å ringe på dumpsys er:

adb shell dumpsys | -c | -h]

Noen vanlige bruksområder ville:

• adb shell dumpsys: omstøter alle tjenester (svært ordrikt).
• adb shell dumpsys inputstatus for inndatasystem (tastaturer, berøringsskjermer osv.).
• adb shell dumpsys -l: liste opp alle tilgjengelige tjenester.

Blant de viktigste kommandolinjealternativene inkluderer:

• -t timeout: maksimal tid i sekunder gitt til dumpsys for å fullføre operasjonen (standard, 10 sekunder).
• --help: hjelp med generisk verktøy.
• -lliste over systemtjenester.
• --skip services: indikerer én eller flere tjenester du vil ekskludere fra utdataene når du ikke spesifiserer noen spesifikk tjeneste.
• service Spesifiser den spesifikke tjenesten du vil inspisere, med valgfrie argumenter. Hvis du er usikker, godtar mange tjenester -h å vise sin egen hjelp, for eksempel adb shell dumpsys procstats -h.
• -c: fører til at visse tjenester returnerer data i et format som er mer egnet for forbruk av skript eller verktøy.
• -hI noen tjenester, skriv ut spesifikk tilleggshjelp.

Inndatadiagnostikk: berøringer, tastetrykk og hendelsesforsinkelser

For latensproblemer knyttet til berøring eller tastaturinndataNøkkeltjenesten er input. Med adb shell dumpsys input Du får en dump av tilstanden til inndataenhetene og flyten av hendelser fra de genereres til de når vinduene.

Utgangen inneholder tre viktige logiske blokkerstatusen til Event Hub, statusen til InputReader og tilstanden til InputDispatcherHver av dem hjelper deg med å oppdage feil i en del av arrangementets reise.

Event Hub: Tilgjengelige enheter og konfigurasjonen deres

«Hendelseshubstatus» viser alle inndataenheter som systemet kjenner til., med informasjon som enhetsbanen, klassen, tastelayoutfiler, nøkkeltegn og konfigurasjon, samt den innebygde tastaturidentifikatoren (BuiltInKeyboardId).

Når du gjennomgår denne delen, er det lurt å sjekke:

• At alle forventede fysiske enheter er korrekt oppført.
• Hver tast har sin egen tildelte tastlayoutfil, tegnkart og konfigurasjonsfil. Hvis disse mangler eller inneholder syntaksfeil, vil de ikke lastes inn, og inndataopplevelsen vil bli dårligere.
• At feltet Classes ha de riktige bitene, kartlagt til konstanter som INPUT_DEVICE_CLASS_TOUCH_MT en EventHub.h.
• At BuiltInKeyboardId sjø -2 Når det ikke finnes et integrert tastatur, eller hvis ID-en til det interne tastaturet samsvarer på annen måte. Hvis du ser at det ikke er det -2 Og det burde det være; det mangler sannsynligvis et spesialtegnkart for et funksjonstastatur, som bare skal inneholde type SPECIAL_FUNCTION.

InputReader: Hvordan inndatahendelser tolkes

InputReader Den er ansvarlig for å "oversette" lavnivå kjernehendelser til noe rammeverket kan forstå: berøringskoordinater, trykk, berøringsstørrelse osv. I dumpen ser du den detaljerte konfigurasjonen av hver enhet (for eksempel en spesifikk berøringsskjerm) og de siste handlingene som ble utført.

Når det gjelder berøringsskjermer, er det viktig å sjekke:

• X- og Y-områdene (minimum, maksimum, presisjon, toleranser).
• Kalibreringsparametrene (størrelsesskalaer, trykk, orientering osv.).
• Størrelsen på overflaten (bredde og høyde i piksler).
• Translasjons- og skaleringsfaktorer, som bestemmer hvordan råkoordinater kartlegges til skjermrommet.

Globale parametere er også oppført på slutten av denne delen. som for eksempel tappeintervall, terskler for pekerhastighet eller bevegelsesinnstillinger (dobbelt tappetid, minimumsavstand osv.), som direkte påvirker følelsen av flyt.

InputDispatcher: sending av hendelser til Windows og ANR

InputDispatcher Den håndterer sending av innkommende hendelser til de forskjellige vindueneStatusen viser hvilket vindu som er i fokus, hvilke som er berøringsfølsomme, statusen til inndatakøene og om det pågår en ANR (Application Not Responding).

I praksis lar denne delen deg sjekke:

• Hvilket vindu mottok tappingene da tappingen skjedde? dumpsys.
• Hvis det er ventende hendelser eller blokkerte køer som kan øke den opplevde ventetiden.
• Hvordan innkommende tilkoblinger er fordelt mellom ulike vinduer og om noen av dem metter køen sin.

En enkel, men svært avslørende sjekk Det er bare et trykk på skjermen, start det umiddelbart adb shell dumpsys input og se om linjen til TouchStates Identifiser riktig hvilket vindu du berørte. Hvis ikke, er det noe galt med fokushåndteringen eller berøringsområdetilordningen.

Måling av brukergrensesnittytelse med gfxinfo og framesstats

Når hovedbekymringen er juks i animasjoner og rulling, tjenesten gfxinfo Han er din venn. Gjennom dumpsys gfxinfo Du kan få data om de gjengitte rammene for en bestemt app.

Den grunnleggende kommandoen for en bestemt app er:

adb shell dumpsys gfxinfo package-name

Hvis du legger til alternativet framestatsDiagnosen blir enda mer detaljert:

adb shell dumpsys gfxinfo package-name framestats

Dette vil gi deg statistikk over forsinkelse bilde for bilde Disse dataene fra nylige animasjoner er svært nyttige for å identifisere spesifikke overganger eller skjermbilder der gjengivelsestiden øker. Denne informasjonen kan deretter integreres i automatiserte tester eller makrobenchmarks for å overvåke regresjoner mellom appversjoner.

Nettverksdiagnostikk med dumpsys netstats

For å forstå om UI-forsinkelse er relatert til tregt nettverk eller trafikktopper, tjenesten netstats Det er veldig nyttig. Det samler inn statistikk om nettverksbruk fra det øyeblikket enheten slås på.

Den typiske kommandoen mer detaljert er:

adb shell dumpsys netstats detail

Avreisen er organisert i flere seksjoner.:

• Aktive grensesnitt og aktive UID-grensesnitt, der navn som wlan0 og dens nettverksidentifikator.
• «Dev»- og «Xt»-statistikk, som viser historiske data med tidsintervaller (f.eks. i trinn på én time) og felt som mottatte byte (rb), pakker mottatt (rp), overførte byte (tb), Etc.
• Statistikk etter UID, der du kan analysere nettverksforbruket til en bestemt app, og skille mellom mobil og Wi-Fi.

Slik finner du appens UIDNoe slikt brukes:

adb shell dumpsys package your-package-name | grep userId

Når du først vet verdien av userId, kan du se på utgangen av netstats linjene med uid=ese_valor og se for eksempel hvor mange byte og pakker den har brukt i hver totimersperiode, og om den var i forgrunnen (set=DEFAULT) eller i bakgrunnen (set=BACKGROUND).

Batteri- og energiforbruk med batterystats

Latens og støt er ikke bare fikset med bedre ytelseNoen ganger er det også verdt å se på hvordan optimaliseringer påvirker energiforbruket. dumpsys batterystats Den gir en svært omfattende rapport om batteribruk etter UID og etter komponent.

Basiskommandoen for denne tjenesten er:

adb shell dumpsys batterystats options

Hvis du vil fokusere på en bestemt app siden forrige opplastingDet brukes:

adb shell dumpsys batterystats --charged package-name

Den vanlige avreisen inkluderer:

• Batterirelatert hendelseshistorikk.
• Global enhetsstatistikk.
• Energiforbruksestimater etter UID og etter systemkomponenter.
• Brukstid for mobilnettverk per app og pakke.
• Global statistikk over system- og app-UID-er.

Innsjekkingsformat (CSV) for automatisert analyse

Hvis du trenger å behandle batteridata ved hjelp av skript eller eksterne verktøyDu kan generere en "maskinvennlig" utdata med:

adb shell dumpsys batterystats --checkin

Dette formatet presenterer hver observasjon i en CSV-linje.med en seksjonsidentifikator som bestemmer hvordan de andre feltene skal tolkes. Noen eksempler på seksjoner er:

• vers: innsjekkings-, pakke- og plattformversjoner.
• uidUID – forholdet mellom pakkenavn.
• apk, pr, sr, vib, fgosv.: bruk av prosesser, sensorer, vibrator, forgrunnstid, synkroniseringer, jobber osv.
• nt y gnnettverksstatistikk (byte og mobil-/Wi-Fi-pakker, oppetid osv.).
• bt, dc, lvBatteridata som tider, nivåer og utladninger.
• wfl, gwfl, gblespesifikk Wi-Fi- og Bluetooth-informasjon, inkludert tider og estimert forbruk i mAh.

I nyere versjoner av Android (6.0 og nyere)Energiforbruket til Wi-Fi, mobilradio og Bluetooth rapporteres som elementer pwi med dedikerte etiketter (wifi, blue, cell), mens den i eldre versjoner var gruppert i seksjonen m (diverse).

Minneinspeksjon over tid med procstats

Hvis du mistenker at juksen kommer fra minnelekkasjer eller tunge apper som kjører i bakgrunnen, dumpsys procstats Den lar deg se hvordan applikasjonen din oppfører seg over tid: hvor lenge den har vært aktiv, i hvilken tilstand og med hvilket minneforbruk.

En typisk bruk er å be om statistikk fra de siste timene, for eksempel:

adb shell dumpsys procstats --hours 3

Resultatet oppsummerer for hver app. Prosentandelen av tiden prosessen har vært aktiv, sammen med PSS-, USS- og RSS-verdier i form av minimum, gjennomsnitt og maksimum, sammen med antall prøver som er tatt. Den viser også et minnesammendrag etter prosesstype (kjerne, native, persistent, top, services, cached processes, etc.).

Denne aggregerte visningen bidrar til å oppdage mønstre som for eksempel applikasjoner som forblir i bakgrunnstilstander for lenge, eller som opprettholder en veldig høy gjennomsnittlig eller maksimal PSS, er potensielle kandidater for optimalisering eller kan til og med forårsake minnepress som forringer systemytelsen.

Detaljert minnebilde med meminfo

Når du trenger et svært detaljert øyeblikksbilde av minnebruken til en bestemt prosessVerktøyet er dumpsys meminfoMed den kan du se hvordan RAM er fordelt mellom native heaps, Dalvik/ART, kodekart, grafikkbuffere osv.

Den grunnleggende syntaksen er:

adb shell dumpsys meminfo package_name|pid

Alternativet -d Mer informasjon om Dalvik/ARTviser interne detaljer som plass til store objekter (.LOS), GC-overbelastning, JIT-cache, zygoteplass osv. Med -h Du kan se alle tilgjengelige flagg.

De viktigste kolonnene å observere er vanligvis Pss Total y Private DirtyDisse tallene gjenspeiler henholdsvis RAM-bruken justert ved deling og mengden modifisert privat minne som frigjøres først ved prosessavslutning. Noen ganger er de også av interesse. Private Clean y Heap AllocHvis du oppdager unormalt forbruk, sjekk hvordan frigjør RAM å dempe dem.

Noen relevante kategorier i tabellen:

• Native Heap y Dalvik Heap: bruk av innebygd minne og heap-minne for virtuelle maskiner. Heap Alloc Den viser hva allokatorene mener er reservert, noe som kan være høyere enn PSS på grunn av zygote-effekten og delt minne.
• .so mmap, .dex mmap, .oat mmap y .art mmapRAM brukt av native koder og bytekoder, inkludert ART-bilder og deres delte områder.
• .Heap, .LOS, .GC, .JITCache, .Zygote, .NonMoving, .IndirectRef (med -d): bryte ned den interne bruken av minne som administreres av ART ytterligere.
• Unknown: sider som ikke kunne klassifiseres i tidligere kategorier, ofte native oppgaver sett via ASLR.

TOTAL-linjen grupperer den totale PSS-en for prosessensom kan sammenlignes med PSS for andre prosesser og tilgjengelig RAM. Private Dirty + Private Clean De indikerer minnet som vil bli frigjort når prosessen blir drept.

I tillegg er det listet opp objekttellere på høyt nivå på slutten av rapporten. som et antall ViewRootImpl, AppContexts o ActivitiesDette bidrar til å oppdage typiske lekkasjer av kontekster eller aktiviteter som holdes av statiske referanser eller av visninger/tegnbare elementer som fortsetter å peke til dem.

Det er verdt å huske hva en View det er Drawable De opprettholder også referansen til Activity som de kommer fra, så feil lagring av dem kan føre til lekkasjer av all aktivitet og tilhørende ressurser.

Kombinering av Perfettos detaljerte spor med Dumpsys-diagnostikk (input, grafikk, minne, nettverk og batteri) gir et 360-graders bilde av hvordan en Android-app oppfører seg: fra når en tråd planlegges til hvor mange millisekunder det tar å gjengi en ramme eller hvor mye overflødig minne og energi den bruker. Regelmessig bruk av disse verktøyene i utvikling og testing utgjør forskjellen mellom en app som «mer eller mindre fungerer» og en som føles virkelig flytende, stabil og effektiv, selv på beskjedne enheter. optimalisere Android.