Inspicer din app's hukommelsesforbrug med Memory Profiler

Hukommelsesprofileren er en komponent i Android Profiler, der hjælper dig med at identificere hukommelseslækager og hukommelsessvigt, der kan føre til stutteri, frysning og endda app-nedbrud. Den viser en realtidsgraf over din apps hukommelsesforbrug og giver dig mulighed for at registrere et heap dump, fremtvinge garbage collections og spore hukommelsesallokeringer.

Følg disse trin for at åbne Memory Profiler:

Klik på Vis > Værktøjsvinduer > Profiler (du kan også klikke på Profil på værktøjslinjen).
Vælg den enhed og app-proces, du vil profilere, på AndroidProfiler-værktøjslinjen. Hvis du har tilsluttet en enhed via USB, men ikke kan se den på listen, skal du sikre dig, at du har aktiveret USB-debugging.
Klik et sted på MEMORY-tidslinjen for at åbne Memory Profiler.

Alternativt kan du inspicere din app-hukommelse fra kommandolinjen meddumpsys og også se GC-hændelser i logcat.

Hvorfor du bør profilere din app-hukommelse

Android tilbyder et administreret hukommelsesmiljø – når det fastslår, at din app ikke længere bruger nogle objekter, frigiver garbage collector den ubrugte hukommelse tilbage til heap’en. Hvordan Android finder ubrugt hukommelse bliver hele tiden forbedret, men på et tidspunkt i alle Android-versioner skal systemet kortvarigt holde en pause i din kode. For det meste er pauserne ikke til at få øje på. Men hvis din app allokerer hukommelse hurtigere, end systemet kan indsamle den, kan din app blive forsinket, mens opsamleren frigør nok hukommelse til at opfylde dine allokeringer. Forsinkelsen kan få din app til at springe frames over og forårsage synlig langsommelighed.

Selv om din app ikke udviser langsommelighed, kan den, hvis den lækker hukommelse, beholde denne hukommelse, selv mens den er i baggrunden. Denne adfærd kan gøre resten af systemets hukommelsesydelse langsommere ved at fremtvinge unødvendige affaldsindsamlingsbegivenheder. Til sidst er systemet tvunget til at dræbe din app-proces for at genvinde hukommelsen. Når brugeren så vender tilbage til din app, skal den genstartes helt.

For at undgå disse problemer bør du bruge Memory Profiler til at gøre følgende:

Læs efter uønskede hukommelsesallokeringsmønstre i tidslinjen, der kan forårsage ydelsesproblemer.
Dump Java-heap’en for at se, hvilke objekter der bruger hukommelse på et givet tidspunkt. Flere heap-dumps over en længere periode kan hjælpe med at identificere hukommelseslækager.
Optag hukommelsesallokeringer under normal og ekstrem brugerinteraktion for at identificere præcis, hvor din kode enten allokerer for mange objekter på kort tid eller allokerer objekter, der bliver lækket.

For oplysninger om programmeringspraksis, der kan reducere din apps hukommelsesforbrug, kan du læse Administrer din apps hukommelse.

Oversigt over Memory Profiler

Når du åbner Memory Profiler første gang, får du vist en detaljeret tidslinje over din apps hukommelsesforbrug og adgang til værktøjer til at fremtvinge garbage collection, optage et heapdump og registrere hukommelsesallokeringer.

Figur 1. Memory Profiler

Som angivet i figur 1 omfatter standardvisningen for Memory Profiler følgende:

En knap til at fremtvinge en garbage collection-hændelse.
En knap til at optage et heap dump.

Bemærk: En knap til at registrere hukommelsesallokeringer vises kun til højre for knappen heap dump, når den er tilsluttet en enhed, der kører Android 7.1 (API-niveau 25) eller lavere.
En rullemenuen til at angive, hvor ofte profilen optager hukommelsesallokeringer. Valg af den relevante indstilling kan hjælpe dig med at forbedre appens ydeevne under profilering.
Knapper til at zoome ind/ud på tidslinjen.
En knap til at springe fremad til de levende hukommelsesdata.
Hændelsestidslinjen, som viser aktivitetstilstande, brugerinputhændelser og skærmens rotationshændelser.
Tidslinjen for hukommelsesforbrug, som indeholder følgende:
- En stablet graf over, hvor meget hukommelse der bruges af hver hukommelseskategori, som angivet af y-aksen til venstre og farvenøglen øverst.
- En stiplet linje angiver antallet af allokerede objekter, som angivet af y-aksen til højre.
- Et ikon for hver garbage collection-hændelse.

Hvis du bruger en enhed, der kører Android 7.1 eller lavere, er det dog ikke alle profileringsdata, der er synlige som standard. Hvis du får vist en meddelelse med teksten “Avanceret profilering er ikke tilgængelig for den valgte proces”, skal du aktivere avanceret profilering for at se følgende:

Hændelsestidslinje
Antal allokerede objekter
Hændelser vedrørende affaldsindsamling

På Android 8.0 og højere er avanceret profilering altid aktiveret for debuggableapps.

Sådan tælles hukommelse

De tal, du ser øverst i hukommelsesprofileren (figur 2), er baseret påalle de private hukommelsessider, som din app har engageret, i henhold tilAndroid-systemet. Denne optælling omfatter ikke sider, der deles med systemet eller andre apps.

Figur 2. Legenden om hukommelsestallet øverst i Memory Profiler

Kategorierne i hukommelsestallet er som følger:

Java: Hukommelse fra objekter allokeret fra Java- eller Kotlin-kode.
Native: Hukommelse fra objekter allokeret fra C- eller C++-kode.

Selv om du ikke bruger C++ i din app, kan du se, at der bruges noget indfødt hukommelse her, fordi Android-rammen bruger indfødt hukommelse til at håndtere forskellige opgaver på dine vegne, f.eks. ved håndtering af billedaktiver og anden grafik – også selv om den kode, du har skrevet, er i Java eller Kotlin.
Grafik: Hukommelse, der bruges til grafikbuffer-køer til at vise pixels på skærmen, herunder GL-overflader, GL-teksturer osv. (Bemærk, at dette er hukommelse, der deles med CPU’en, og ikke dedikeret GPU-hukommelse.)
Stack: Hukommelse, der bruges af både native og Java-stacks i din app. Dette hænger normalt sammen med, hvor mange tråde din app kører.
Kode: Hukommelse, som din app bruger til kode og ressourcer, f.eks. dex-bytekode, optimeret eller kompileret dex-kode, .so-biblioteker og skrifttyper.
Andre: Hukommelse, der bruges af din app, som systemet ikke er sikker på, hvordan det skal kategoriseres.
Allokeret: Antallet af Java/Kotlin-objekter, der er allokeret af din app. Dette tæller ikke objekter, der er allokeret i C eller C++.

Når du er tilsluttet en enhed, der kører Android 7.1 og lavere, starter denne allokeringstælling kun på det tidspunkt, hvor Memory Profiler har oprettet forbindelse til din kørende app. Så eventuelle objekter, der er allokeret, før du starter profileringen, er ikke medregnet. Android 8.0 og højere omfatter dog et profileringsværktøj på enheden, der holder styr på alle allokeringer, så dette tal repræsenterer altid det samlede antal udestående Java-objekter i din app på Android 8.0 og højere.

Ved sammenligning med hukommelsestællinger fra det tidligere Android Monitor-værktøj registrerer den nyeMemory Profiler din hukommelse på en anden måde, så det kan se ud som om dithukommelsesforbrug nu er højere. Memory Profiler overvåger nogle ekstra kategorier, der øger det samlede tal, men hvis du kun bekymrer dig om Java-heap-hukommelsen, bør tallet “Java” svare til værdien fra det tidligere værktøj.Selv om Java-tallet sandsynligvis ikke svarer nøjagtigt til det, du så i AndroidMonitor, tager det nye tal højde for alle fysiske hukommelsessider, der er blevet allokeret til din app’s Java-heap, siden den blev gaflet fra Zygote. Så dette giver en nøjagtig repræsentation af, hvor meget fysisk hukommelse din app rent faktisk bruger.

Se hukommelsesallokeringer

Hukommelsesallokeringer viser dig, hvordan hvert Java-objekt og JNI-reference i din hukommelse blev allokeret. Hukommelsesprofileren kan specifikt vise dig følgende om objektallokeringer:

Hvilke typer objekter der blev allokeret, og hvor meget plads de bruger.
Stacktrace for hver allokering, herunder i hvilken tråd.
Hvornår objekterne blev deallokeret (kun når du bruger en enhed med Android 8.0 eller højere).

Hvis din enhed kører Android 8.0 eller højere, kan du til enhver tid se dine objektallokeringer på følgende måde: Træk i tidslinjen for at vælge det område, som du ønsker at se allokeringerne for (som vist i video 1). Det er ikke nødvendigt at starte en optagelsessession, da Android 8.0 og højere versioner indeholder et værktøj til profilering uden for enheden, der konstant registrerer din app’s allokeringer.

Video 1. Med Android 8.0 og højere skal du vælge et eksisterende tidslinjeområde for at få vist objektallokeringer

Hvis din enhed kører Android 7.1 eller lavere, skal du klikke på Optag hukommelsesallokeringer i værktøjslinjen Hukommelsesprofiler. Mens du optager, sporerMemory Profiler alle allokeringer, der forekommer i din app. Når du er færdig, skal du klikke på Stop optagelse(den samme knap; se video 2) for at få vist allokeringerne.

Video 2. Med Android 7.1 og lavere skal du eksplicit registrere hukommelsesallokeringer

Når du har valgt et område på tidslinjen (eller når du afslutter en optagelsessession med en enhed, der kører Android 7.1 eller lavere), vises listen over allokeredeobjekter under tidslinjen, grupperet efter klassens navn og sorteret efter deres heap-tælling.

Følg disse trin for at inspicere allokeringsoptegnelsen:

Gennemse listen for at finde objekter, der har usædvanligt store heap-tællinger, og som muligvis er blevet lækket. For at hjælpe med at finde kendte klasser kan du klikke på kolonneoverskriften Klassens navn for at sortere alfabetisk. Klik derefter på et klassenavn. RudenInstance View (Instansvisning) vises til højre og viser hver enkelt instans af den pågældende klasse, som vist i figur 3.
- Alternativt kan du hurtigt finde objekter ved at klikke på Filter eller ved at trykke på Control+F (Command+F på Mac) og indtaste et klasse- eller pakkenavn i søgefeltet. Du kan også søge efter metodebetegnelse, hvis du vælgerArrange by callstack i rullemenuen. Hvis du vil bruge regulativudtryk, skal du markere feltet ud for Regex. Markér afkrydsningsfeltet ud forMatch case, hvis din søgeforespørgsel er case-sensitiv.
I ruden Instancevisning skal du klikke på en instans. Fanen Call Stack vises nedenfor og viser, hvor den pågældende instans blev allokeret og i hvilken tråd.
Højreklik på en hvilken som helst linje i fanen Call Stack, og vælgJump to Source for at åbne den pågældende kode i editoren.

Figur 3. Detaljer om hvert allokeret objekt vises i Instance View til højre

Du kan bruge de to menuer over listen over allokerede objekter til at vælge, hvilken heap der skal inspiceres, og hvordan dataene skal organiseres.

Vælg i menuen til venstre, hvilken heap der skal inspiceres:

standardheap: Når der ikke er angivet nogen heap af systemet.
image heap: Systemets boot-image, der indeholder klasser, som indlæses under opstart. Allokeringer her er garanteret aldrig at flytte eller gå væk.
zygote heap: Zygote heap: Copy-on-write heap, hvorfra en app-proces er gafflet i Android-systemet.
app heap: Den primære heap, som din app allokerer hukommelse på.
JNI-heap: Den primære heap, som din app allokerer hukommelse på.
JNI-heap: Den heap, der viser, hvor Java Native Interface-referencer (JNI) allokeres og frigives.

Vælg i menuen til højre, hvordan allokeringerne skal arrangeres:

Arranger efter klasse: Grupperer alle allokeringer baseret på klassens navn. Dette er standardindstillingen.
Sorter efter pakke:
Sortere efter callstack:

Forbedre appens ydeevne under profileringen

For at forbedre appens ydeevne under profileringen, prøver hukommelsesprofileren hukommelsesallokeringer med jævne mellemrum som standard. Når du tester på enheder, der kører APIlevel 26 eller højere, kan du ændre denne adfærd ved at bruge rullelisten Allokeringssporing. De tilgængelige indstillinger er som følger:

Fuldt: Registrerer alle objektallokeringer i hukommelsen. Dette er standardadfærden i Android Studio 3.2 og tidligere. Hvis du har en app, der allokerer mange objekter, kan du måske observere synlige nedsat hastighed i din app under profilering.
Samplet: Prøver objektallokeringer i hukommelsen med jævne intervaller. Dette er standardindstillingen og har mindre indvirkning på appens ydeevne under profilering. Apps, der allokerer mange objekter over et kort tidsrum, kan stadig udvise synlige nedsat hastighed.
Off: Stopper med at spore din apps hukommelsesallokering.

Se globale JNI-referencer

Java Native Interface (JNI) er en ramme, der gør det muligt for Java-kode og nativekode at kalde hinanden.

JNI-referencer håndteres manuelt af den native kode, så det er muligt, atJava-objekter, der bruges af nativekode, holdes i live for længe. Nogle objekter på Java-heap’en kan blive uopnåelige, hvis en JNI-reference kasseres uden først at blive slettet eksplicit. Det er også muligt at opbruge den globale JNI-referencegrænse.

For at løse sådanne problemer kan du bruge JNI-heap-visning i Memory Profiler til at gennemse alle globale JNI-referencer og filtrere dem efter Java-typer og native callstacks. Med disse oplysninger kan du finde ud af, hvornår og hvor globale JNI-referencer oprettes og slettes.

Mens din app kører, skal du vælge en del af tidslinjen, som du vil inspicere, og vælge JNI-heap i rullemenuen over klasselisten.Du kan derefter inspicere objekter i heap’en, som du normalt ville gøre, og dobbeltklikke på objekter i fanen Allocation Call Stack for at se, hvor JNI-referencerne allokeres og frigives i din kode, som vist i figur 4.

Figur 4. Visning af globale JNI-referencer

For at inspicere hukommelsesallokeringer for din app’s JNI-kode skal du distribuere din app til en enhed, der kører Android 8.0 eller nyere.

For yderligere oplysninger om JNI, se JNI-tips.

Native Memory Profiler

Android Studio Memory Profiler indeholder en Native Memory Profiler tilapper, der distribueres til fysiske enheder, der kører Android 10. Understøttelse for Android 11-enheder er i øjeblikket tilgængelig i Android Studio 4.2 preview-udgaven.

Den Native Memory Profiler sporer allokeringer/tildelinger af objekter i nativekode i en bestemt tidsperiode og giver følgende oplysninger:

Allokeringer: En optælling af objekter, der er allokeret via malloc() eller operatoren new i den valgte tidsperiode.
Deallokeringer: En optælling af objekter, der er deallokeret via free() eller operatorendelete i den valgte tidsperiode.
Allokeringer Størrelse: Den samlede størrelse i bytes af alle allokeringer i den valgte tidsperiode.
Deallokeringer Størrelse: Den samlede størrelse i bytes af al frigjort hukommelse i den valgte periode.
Samlet antal: Den samlede størrelse i bytes af al frigjort hukommelse i den valgte periode: Værdien i kolonnen Allokeringer minus værdien i kolonnen Deallokeringer.
Resterende størrelse:

For at starte en optagelse skal du klikke på Optag native allokeringer øverst i vinduetHukommelsesprofiler for at starte en optagelse:

Når du er klar til at afslutte optagelsen, skal du klikke på Stop optagelse.

Som standard bruger Native Memory Profiler en prøvestørrelse på 32 bytes: Hver gang der allokeres 32 bytes hukommelse, tages der et øjebliksbillede af hukommelsen. En mindre prøvestørrelse resulterer i hyppigere snapshots, hvilket giver mere nøjagtige data om hukommelsesbrug. En større prøvestørrelse giver mindre nøjagtige data, men den vil forbruge færre ressourcer på dit system og forbedre ydeevnen under registrering.

For at ændre prøvestørrelsen for Native Memory Profiler:

Vælg Kør > Rediger konfigurationer.
Vælg dit appmodul i venstre rude.
Klik på fanen Profilering, og indtast prøvestørrelsen i feltet med titlenNative memory sampling interval (bytes).
Opbyg og kør din app igen.

Optag et heap dump

Et heap dump viser, hvilke objekter i din app der bruger hukommelse på det tidspunkt, hvor duoptager heap dump’et. Især efter en længere brugersession kan et heap dump hjælpe med at identificere hukommelseslækager ved at vise objekter, der stadig er i hukommelsen, som du tror, ikke længere burde være der.

Når du har optaget et heap dump, kan du se følgende:

Hvilke typer objekter din app har allokeret, og hvor mange af hver type.
Hvor meget hukommelse hvert objekt bruger.
Hvor henvisninger til hvert objekt opbevares i din kode.
Kaldestakken for hvor et objekt blev allokeret. (Call stacks er i øjeblikket kun tilgængelige med et heap-dump med Android 7.1 og lavere, når du optager heap-dumpet, mens du registrerer allokeringer.)

For at optage et heap-dump skal du klikke på Dump Java-heap i værktøjslinjen Hukommelsesprofiler.Under dumpning af heapet kan mængden af Java-hukommelse øges midlertidigt.Dette er normalt, fordi heap-dumpet sker i samme proces som din appog kræver noget hukommelse til at indsamle dataene.

Heap-dumpet vises under hukommelsestidslinjen og viser alle klassetyper i heapet, som vist i figur 5.

Figur 5. Visning af heap dump

Hvis du har brug for at være mere præcis med hensyn til, hvornår dumpet oprettes, kan du oprette et heap dump på det kritiske punkt i din app-kode ved at kaldedumpHprofData().

I listen over klasser kan du se følgende oplysninger:

Allokationer: Antal allokeringer i heap.
Nativ størrelse:
Nativ størrelse: Den samlede mængde native hukommelse, der bruges af denne objekttype (i bytes). Denne kolonne er kun synlig for Android 7.0 og højere.

Du vil se hukommelse her for nogle objekter, der er allokeret i Java, fordi Androidanvender indfødt hukommelse til nogle rammeklasser, f.eks.Bitmap.
Skål størrelse: Samlet mængde Java-hukommelse, der bruges af denne objekttype (i bytes).
Retained Size (tilbageholdt størrelse):

Du kan bruge de to menuer over listen over allokerede objekter til at vælge, hvilkeheap-dumps der skal inspiceres, og hvordan dataene skal organiseres.

Vælg i menuen til venstre, hvilken heap der skal inspiceres:

standardheap: Når der ikke er angivet nogen heap af systemet.
app heap: Den primære heap, som din app allokerer hukommelse på.
image heap: Den primære heap, som din app allokerer hukommelse på: Systemets boot-image, der indeholder klasser, som indlæses under opstart. Allokeringer her er garanteret aldrig at flytte eller gå væk.
zygote heap: I Android-systemet.

I menuen til højre kan du vælge, hvordan allokeringerne skal arrangeres:

Arranger efter klasse: Grupperer alle allokeringer baseret på klassens navn. Dette er standardindstillingen.
Sorter efter pakke:
Sortere efter callstack: Grupperer alle allokeringer i deres tilsvarende call stack. Denne indstilling fungerer kun, hvis du optager heapdumpet, mens du registrererallokeringer. Alligevel vil der sandsynligvis være objekter i heap’en, der blevallokeret, før du begyndte at optage, så disse allokeringer vises først,blot anført efter klassens navn.

Listen er som standard sorteret efter kolonnen Bevaret størrelse. Hvis du vil sortere efter værdierne i en anden kolonne, skal du klikke på kolonnens overskrift.

Klik på et klassenavn for at åbne vinduet Instancevisning til højre (vist i figur 6). Hver listet instans indeholder følgende:

Dybde: Det korteste antal hop fra en GC-root til den valgte instans.
Native Size:
Native Size: Det korteste antal hop fra en GC-root til den valgte instans: Denne kolonne er kun synlig for Android 7.0 og højere.
Shallow Size: Størrelse af denne instans i den native hukommelse.
Shallow Size: Størrelse af denne instans i den native hukommelse: Størrelsen af denne instans i Java-hukommelse.
Retained Size: Størrelse af den hukommelse, som denne instans dominerer (ifølge dominatortræet).

Figur 6. Den varighed, der kræves for at optage et heapdump, er angivet i tidslinjen

Følg disse trin for at inspicere din heap:

Søg på listen for at finde objekter, der har usædvanligt store heaptællinger, ogsom måske er lækket. For at hjælpe med at finde kendte klasser kan du klikke på kolonneoverskriften Klassens navn for at sortere alfabetisk. Klik derefter på et klassenavn. Til højre vises ruden Instance View (Instansvisning), som viser hver enkelt instans af den pågældende klasse, som vist i figur 6.
- Alternativt kan du hurtigt finde objekter ved at klikke på Filter eller ved at trykke på Control+F (Command+F på Mac) og indtaste et klasse- eller pakkenavn i søgefeltet. Du kan også søge efter metodebetegnelse, hvis du vælgerArrange by callstack i rullemenuen. Hvis du vil bruge regulativudtryk, skal du markere feltet ud for Regex. Markér afkrydsningsfeltet ud forMatch case, hvis din søgeforespørgsel er case-sensitiv.
I ruden Instancevisning skal du klikke på en instans. Referencetabellen vises nedenfor og viser alle referencer til dette objekt.
Og klik på pilen ud for instansnavnet for at få vist alle felter, og klik derefter på et feltnavn for at få vist alle dets referencer. Hvis du vil se instansdetaljerne for et felt, skal du højreklikke på feltet og vælge Gå til instans.
Hvis du identificerer en reference, der muligvis bruger hukommelse, skal du højreklikke på den under fanen Referencer og vælge Gå til instans. Dette vælger den tilsvarende instans fra heapdumpet og viser dig dens egne instansdata.

I dit heapdump skal du kigge efter hukommelseslækager, der skyldes et af følgende:

Langvarige referencer til Activity, Context,View, Drawable og andre objekter, der kan indeholde en reference til Activity– eller Context-containeren.
Non-statiske indre klasser, f.eks. en Runnable, der kan indeholde en Activity-instans.
Caches, der holder objekter længere end nødvendigt.

Spar et heapdump som en HPROF-fil

Når du har optaget et heapdump, kan dataene kun ses i Memory Profiler, mens profileringen kører. Når du afslutter profileringssessionen, mister du heap-dumpet. Så hvis du vil gemme den til gennemsyn senere, skal du eksportere heapdumptet til en HPROF-fil. I Android Studio 3.1 og lavere er knappen Export capture to file på venstre side af værktøjslinjen under tidslinjen; iAndroid Studio 3.2 og højere er der en knap Export Heap Dump til højre for hver Heap Dump-post i ruden Sessions (sessioner). I dialogboksen Export Asdialog, der vises, skal du gemme filen med filtypenavnet .hprof.

For at bruge en anden HPROF-analysator somjhat skal du konvertere HPROF-filen fra Android-formatet til Java SE HPROF-formatet.Det kan du gøre med hprof-conv-værktøjet, der findes i mappenandroid_sdk/platform-tools/. Kør hprof-convkommandoen med to argumenter: den originale HPROF-fil og den placering, hvor du skal skrive den konverterede HPROF-fil. For eksempel:

hprof-conv heap-original.hprof heap-converted.hprof

Import a heap dump file

For at importere en HPROF-fil (.hprof) skal du klikke på Start a new profiling session i rudenSessions , vælge Load from file og vælge filen fra filebrowseren.

Du kan også importere en HPROF-fil ved at trække den fra filebrowseren ind i eteditorvindue.

Detektion af lækager i Memory Profiler

Når du analyserer et heap-dump i Memory Profiler, kan du filtrere profildata, som Android Studio mener kan indikere hukommelseslækager for Activity og Fragment instanser i din app.

De typer data, som filteret viser, omfatter følgende:

Activity instanser, der er blevet ødelagt, men som der stadig henvises til.
Fragment instanser, der ikke har en gyldig FragmentManager, men som der stadig henvises til.
Fragment instanser, der ikke har en gyldig FragmentManager, men som der stadig henvises til.

I visse situationer, som f.eks. følgende, kan filteret give falske positive resultater:

En Fragment er oprettet, men er endnu ikke blevet brugt.
En Fragment er cachet, men ikke som en del af en FragmentTransaction.

For at bruge denne funktion skal du først optage en heap dumpporfil i Android Studio. Hvis du vil vise de fragmenter og aktiviteter, der måske lækker hukommelse, skal du markere afkrydsningsfeltet Aktivitet/Fragmentlækager i heapdump-ruden i Hukommelsesprofiler, som vist i figur 7.

Figur 7. Filtrering af et heapdump for hukommelseslækager.

Teknikker til profilering af din hukommelse

Mens du bruger Memory Profiler, bør du stresse din app-kode og forsøge at finde hukommelseslækager. En måde at fremprovokere hukommelseslækager i din app er at lade den køre i et stykke tid, før du inspicerer heap’en. Lækager kan sive op til toppen afallokeringerne i heap’en. Men jo mindre lækagen er, jo længere tid skal du køre appen for at se den.

Du kan også udløse en hukommelseslækage på en af følgende måder:

Rotér enheden fra portræt til landskab og tilbage igen flere gange, mens den er i forskellige aktivitetstilstande. Drejning af enheden kan ofte medføre, at en app lækker etActivity,Context ellerView-objekt, fordi systemet opretter Activity, og hvis din app har en reference til et af disse objekter et andet sted, kan systemet ikke indsamle det i skraldespanden.
Skift mellem din app og en anden app, mens du er i forskellige aktivitetstilstande (naviger tilHome-skærmen og vend derefter tilbage til din app).

Tip: Du kan også udføre ovenstående trin ved at bruge themonkeyrunner testframework.