Inspecteer het geheugengebruik van uw app met Memory Profiler

De Memory Profiler is een onderdeel van de Android Profiler waarmee u geheugenlekken en geheugenverspilling kunt identificeren die kunnen leiden tot stotteren, vastlopen en zelfs app-crashes. Het toont een real-time grafiek van het geheugengebruik van uw app en kunt u een heap dump, forceer vuilnisophaal, en trackgeheugentoewijzingen.

Om het geheugenprofiler te openen, volg deze stappen:

Klik op Beeld > Tool Windows > Profiler (u kunt ook klikken op Profiel in de werkbalk).
Selecteer het apparaat en app-proces dat u wilt profileren van de AndroidProfiler werkbalk. Als u een apparaat via USB hebt aangesloten, maar het niet in de lijst ziet, zorg er dan voor dat u USB debugging hebt ingeschakeld.
Klik ergens in de MEMORY tijdlijn om de Memory Profiler te openen.

Aternatief kunt u het geheugen van uw app inspecteren vanaf de opdrachtregel metdumpsys, en ook GC-events bekijken in logcat.

Waarom u uw app geheugen moet profileren

Android biedt een beheerde geheugenomgeving – wanneer het bepaalt dat uw app sommige objecten niet langer gebruikt, geeft de vuilnisman het ongebruikte geheugen terug aan de heap. Hoe Android te werk gaat bij het vinden van ongebruikt geheugen wordt constant verbeterd, maar op een gegeven moment op alle Androidversies, moet het systeem uw code kort pauzeren. Meestal zijn de pauzes onmerkbaar. Als uw app echter sneller geheugen toewijst dan het systeem kan verzamelen, kan uw app worden vertraagd terwijl het verzamelprogramma voldoende geheugen vrijmaakt om aan uw toewijzingen te voldoen. De vertraging kan ertoe leiden dat uw app frames overslaat en zichtbare traagheid veroorzaakt.

Zelfs als uw app geen traagheid vertoont, als het geheugen lekt, kan het dat geheugen vasthouden, zelfs terwijl het op de achtergrond is. Dit gedrag kan de geheugenprestaties van de rest van het systeem vertragen door onnodige vuilnisophaalacties te forceren. Uiteindelijk is het systeem gedwongen om uw app proces te doden om het geheugen terug te krijgen. Wanneer de gebruiker vervolgens terugkeert naar uw app, moet deze volledig opnieuw worden opgestart.

Om deze problemen te helpen voorkomen, moet u de Memory Profiler gebruiken om het volgende te doen:

Zoek naar ongewenste geheugentoewijzingspatronen in de tijdlijn die mogelijk prestatieproblemen veroorzaken.
Dump de Java-heap om te zien welke objecten op een gegeven moment geheugen in gebruik hebben. Meerdere heap dumps over een langere periode kunnen helpen geheugenlekken te identificeren.
Record geheugentoewijzingen tijdens normale en extreme gebruikersinteractie om precies te identificeren waar uw code ofwel te veel objecten in korte tijd toewijst of objecten toewijst die weglekken.

Voor informatie over programmeerpraktijken die het geheugengebruik van uw app kunnen verminderen, leest u Geheugen van uw app beheren.

Memory Profiler-overzicht

Wanneer u de Memory Profiler voor het eerst opent, ziet u een gedetailleerde tijdlijn van het geheugengebruik van uw app en hebt u toegang tot hulpmiddelen om garbage collection te forceren, een heapdump vast te leggen en geheugentoewijzingen te registreren.

Figuur 1. De Memory Profiler

Zoals aangegeven in figuur 1, bevat de standaardweergave voor de Memory Profiler het volgende:

Een knop om een gebeurtenis voor afvalverzameling te forceren.
Een knop om een heapdump vast te leggen.

Opmerking: Een knop om geheugentoewijzingen vast te leggen verschijnt alleen rechts van de heap dump-knop wanneer deze is verbonden met een apparaat waarop Android 7.1 (API-niveau 25) of lager draait.
Een vervolgkeuzemenu om aan te geven hoe vaak de profiler geheugentoewijzingen vastlegt. Het selecteren van de juiste optie kan u helpen de prestaties van de app te verbeteren tijdens het profileren.
Knoppen om in/uit te zoomen op de tijdlijn.
Een knop om vooruit te springen naar de live geheugengegevens.
De gebeurtenistijdlijn, die de activiteitstoestanden, gebeurtenissen voor gebruikersinvoer en schermrotatiegebeurtenissen weergeeft.
De tijdlijn van het geheugengebruik, die het volgende omvat:
- Een gestapelde grafiek van hoeveel geheugen door elke geheugencategorie wordt gebruikt, zoals aangegeven door de y-as aan de linkerkant en de kleurentoets aan de bovenkant.
- Een stippellijn geeft het aantal toegewezen objecten aan, zoals aangegeven door de y-as aan de rechterkant.
- Een pictogram voor elke vuilnisophaalgebeurtenis.

Als u echter een apparaat gebruikt waarop Android 7.1 of lager wordt uitgevoerd, zijn niet alle profileringsgegevens standaard zichtbaar. Als u een bericht ziet dat zegt: “Geavanceerde profilering is niet beschikbaar voor het geselecteerde proces”, moet u geavanceerde profilering inschakelen om het volgende te zien:

Gebeurtenistijdlijn
Aantal toegewezen objecten
Garbage collection gebeurtenissen

Op Android 8.0 en hoger is geavanceerde profilering altijd ingeschakeld voor debuggableapps.

Hoe geheugen wordt geteld

De getallen die u bovenaan de Memory Profiler (figuur 2) ziet, zijn gebaseerd op alle privé-geheugenpagina’s die uw app heeft vastgelegd, volgens het Android-systeem. Deze telling omvat niet de pagina’s die worden gedeeld met het systeem of met andere apps.

Figuur 2. De legenda van de geheugentelling boven aan de Memory Profiler

De categorieën in de geheugentelling zijn als volgt:

Java: Geheugen van objecten toegewezen vanuit Java of Kotlin code.
Native: Geheugen van objecten die zijn toegewezen aan C- of C++-code.

Zelfs als u geen C++ gebruikt in uw app, ziet u hier mogelijk wat native geheugen gebruikt omdat het Android-framework native geheugen gebruikt om verschillende taken namens u uit te voeren, zoals het verwerken van beeldactiva en andere grafische elementen – zelfs als de code die u hebt geschreven in Java of Kotlin is.
Graphics: Geheugen dat wordt gebruikt voor grafische bufferwachtrijen om pixels op het scherm weer te geven, inclusief GL-oppervlakken, GL-texturen, enzovoort. (Merk op dat dit geheugen is dat wordt gedeeld met de CPU, niet speciaal GPU-geheugen.)
Stack: Geheugen dat wordt gebruikt door zowel native als Java-stacks in uw app. Dit heeft meestal betrekking op het aantal threads dat in uw app wordt uitgevoerd.
Code: Geheugen dat uw app gebruikt voor code en hulpbronnen, zoals dex-bytecode, geoptimaliseerde of gecompileerde dex-code, .so-bibliotheken en lettertypen.
Overige: Geheugen dat door uw app wordt gebruikt en waarvan het systeem niet weet hoe het moet worden gecategoriseerd.
Allocated: Het aantal Java/Kotlin-objecten dat door uw app is toegewezen. Objecten die zijn toegewezen in C of C++ worden niet meegeteld.

Als u bent verbonden met een apparaat waarop Android 7.1 en lager wordt uitgevoerd, begint deze toewijzingstelling pas op het moment dat de Memory Profiler verbinding heeft gemaakt met uw actieve app. Dus alle objecten die zijn toegewezen voordat u de profilering start, worden niet meegeteld. Android 8.0 en hoger bevat echter een on-device profiling tool die alle toewijzingen bijhoudt, dus dit aantal vertegenwoordigt altijd het totale aantal Java-objecten dat uitstaat in uw app op Android 8.0 en hoger.

In vergelijking met geheugentellingen van de vorige Android Monitor tool, registreert de nieuwe Memory Profiler uw geheugen anders, dus het kan lijken alsof uw geheugengebruik nu hoger is. De Memory Profiler controleert een aantal extra categorieën die het totaal verhogen, maar als u alleen geeft om het Java heap geheugen, zou het “Java” nummer vergelijkbaar moeten zijn met de waarde van de vorige tool. Hoewel het Java nummer waarschijnlijk niet precies overeenkomt met wat u zag in Android Monitor, houdt het nieuwe nummer rekening met alle fysieke geheugenpagina’s die zijn toegewezen aan de Java heap van uw app sinds deze werd afgesplitst van Zygote. Dus dit geeft een nauwkeurige weergave van hoeveel fysiek geheugen uw app daadwerkelijk gebruikt.

Bekijk geheugentoewijzingen

Geheugentoewijzingen laten u zien hoe elk Java-object en JNI-referentie in uw geheugen werd toegewezen. Specifiek, de Memory Profiler kan u het volgende laten zien over object toewijzingen:

Welke soorten objecten werden toegewezen en hoeveel ruimte ze gebruiken.
De stack trace van elke toewijzing, inclusief in welke thread.
Wanneer de objecten werden gedesalloceerd (alleen bij gebruik van een toestel met Android 8.0 of hoger).

Als uw toestel draait op Android 8.0 of hoger, kunt u uw objectallocaties op elk gewenst moment als volgt bekijken: Sleep in de tijdlijn om het gebied te selecteren waarvoor u de toewijzingen wilt bekijken (zoals getoond in video 1). U hoeft geen opnamesessie te beginnen, omdat Android 8.0 en hoger een profileringstool bevat die constant de toewijzingen van uw app bijhoudt.

Video 1. Met Android 8.0 en hoger selecteert u een bestaand tijdlijngebied om objecttoewijzingen te bekijken

Als uw toestel Android 7.1 of lager draait, klikt u op Geheugentoewijzingen opnemen in de werkbalk Memory Profiler. Terwijl u opneemt, houdt de Memory Profiler alle toewijzingen bij die in uw app plaatsvinden. Als u klaar bent, klikt u op Stop opname (dezelfde knop; zie video 2) om de toewijzingen te bekijken.

Video 2. Met Android 7.1 en lager moet u geheugentoewijzingen expliciet opnemen

Nadat u een regio van de tijdlijn selecteert (of wanneer u een opnamesessie beëindigt met een toestel waarop Android 7.1 of lager), verschijnt de lijst met toegewezen objecten onder de tijdlijn, gegroepeerd op klassenaam en gesorteerd op hun heap count.

Om de toewijzingsrecord te inspecteren, volgt u deze stappen:

Blader door de lijst om objecten te vinden die ongewoon grote heap counts hebben en die mogelijk gelekt zijn. Om bekende klassen te vinden, klikt u op de koptekst van de kolom Class Name om alfabetisch te sorteren. Klik vervolgens op een klassenaam. Rechts verschijnt het deelvenster Instance View, waarin elke instantie van die klasse wordt weergegeven, zoals in figuur 3.
- U kunt ook snel objecten vinden door op Filter te klikken, of door op Control+F (Command+F op de Mac) te drukken en een klasse- of pakketnaam in het zoekveld in te voeren. Je kunt ook zoeken op methode naam als jeArrange by callstack selecteert in het dropdown menu. Als u regelmatige expressies wilt gebruiken, vinkt u het vakje naast Regex aan. Schakel het selectievakje naastMatch case in als uw zoekopdracht hoofdlettergevoelig is.
Klik in het deelvenster Instance View op een instantie. Daaronder verschijnt het tabblad Call Stack (Aanroepstapel), dat laat zien waar die instantie is toegewezen en in welke thread.
In het tabblad Call Stack (Aanroepstapel) kunt u met de rechtermuisknop op een regel klikken en Springen naar bron kiezen om die code in de editor te openen.

Figuur 3. Details over elk toegewezen object verschijnen in de Instance View rechts

U kunt de twee menu’s boven de lijst van toegewezen objecten gebruiken om te kiezen welke heap moet worden geïnspecteerd en hoe de gegevens moeten worden geordend.

Kies uit het menu links welke heap moet worden geïnspecteerd:

standaardheap: Wanneer er geen heap is gespecificeerd door het systeem.
image heap: De systeem boot image, die klassen bevat die worden geladen tijdens het opstarten. Allocaties hier zijn gegarandeerd om nooit te verplaatsen of weg te gaan.
zygote heap: De copy-on-write heap waar een app proces van gevorkt wordt in het Android systeem.
app heap: De primaire heap waarop uw app geheugen toewijst.
JNI heap: De heap die laat zien waar Java Native Interface (JNI)-referenties worden toegewezen en vrijgegeven.

Kies in het menu aan de rechterkant hoe u de toewijzingen wilt rangschikken:

Rangschikken op klasse: Groepeert alle toewijzingen op basis van de naam van de klasse. Dit is de standaardinstelling.
Ordenen op pakket: Groepeert alle toewijzingen op basis van de naam van het pakket.
Rangschikken op callstack: Groepeert alle toewijzingen in hun corresponderende aanroepstack.

Verbeter de app-prestaties tijdens het profileren

Om de app-prestaties tijdens het profileren te verbeteren, neemt de geheugenprofiler standaard periodiek steekproeven van geheugentoewijzingen. Wanneer u test op apparaten met API-niveau 26 of hoger, kunt u dit gedrag wijzigen door de vervolgkeuzelijst Allocatie bijhouden te gebruiken. De beschikbare opties zijn als volgt:

Full: Vangt alle object-toewijzingen in het geheugen. Dit is het standaard gedrag in Android Studio 3.2 en eerder. Als u een app hebt die veel objecten toewijst, kunt u zichtbare vertragingen in uw app waarnemen tijdens het profileren.
Sampled: Samples object toewijzingen in het geheugen met regelmatige tussenpozen. Dit is de standaardoptie en heeft minder invloed op de prestaties van de app tijdens het profileren. Apps die veel objecten toewijzen in een korte tijdspanne kunnen nog steeds zichtbare vertragingen vertonen.
Uit: Stopt met het bijhouden van de geheugentoewijzing van uw app.

Bekijk globale JNI referenties

Java Native Interface (JNI) is een raamwerk dat Java code en native code in staat stelt elkaar aan te roepen.

JNI referenties worden handmatig beheerd door de native code, dus het is mogelijk dat Java objecten die door native code worden gebruikt, te lang in leven worden gehouden. Sommige objecten op de Java heap kunnen onbereikbaar worden als een JNI verwijzing wordt weggegooid zonder eerst expliciet te worden verwijderd. Ook is het mogelijk om de globale JNI-referentielimiet uit te putten.

Om dergelijke problemen op te lossen, kunt u de JNI-heap view in de Memory Profiler gebruiken om door alle globale JNI-referenties te bladeren en ze te filteren op Java-typen en native callstacks. Met deze informatie kunt u nagaan wanneer en waar globale JNI referenties worden aangemaakt en verwijderd.

Terwijl uw app draait, selecteert u een deel van de tijdlijn dat u wilt inspecteren en selecteert u JNI heap uit het uitklapmenu boven de klassenlijst.U kunt dan objecten in de heap inspecteren zoals u normaal zou doen en dubbelklikken op objecten in het tabblad Allocation Call Stack om te zien waar de JNI-referenties worden toegewezen en vrijgegeven in uw code, zoals getoond in figuur 4.

Figuur 4. Globale JNI-verwijzingen weergeven

Om geheugentoewijzingen voor de JNI-code van uw app te inspecteren, moet u uw app implementeren op een apparaat waarop Android 8.0 of hoger wordt uitgevoerd.

Voor meer informatie over JNI, zie JNI-tips.

Native Memory Profiler

De Android Studio Memory Profiler bevat een Native Memory Profiler voor apps die zijn geïmplementeerd op fysieke apparaten met Android 10; ondersteuning voor Android 11-apparaten is momenteel beschikbaar in de Android Studio 4.2 preview-release.

De Native Memory Profiler volgt toewijzingen/deallocaties van objecten in nativecode voor een specifieke tijdsperiode en biedt de volgende informatie:

Allocaties: Een telling van objecten toegewezen via malloc() of de newoperator gedurende de geselecteerde tijdsperiode.
Deallocaties: Een telling van via free() of dedeleteoperator gedesalloceerde objecten gedurende de geselecteerde tijdsperiode.
Allocations Size: De geaggregeerde grootte in bytes van alle toewijzingen gedurende de geselecteerde tijdsperiode.
Deallocaties Grootte: De geaggregeerde grootte in bytes van al het vrijgemaakte geheugen gedurende de geselecteerde tijdsperiode.
Total Count: De waarde in de kolom Allocaties minus de waarde in de kolom Deallocaties.
Resterende grootte: De waarde in de kolom Allocations Size min de waarde in de kolom Deallocations Size.

Om een opname te starten, klikt u op Record native allocations bovenaan hetMemory Profiler-venster:

Wanneer u klaar bent om de opname te voltooien, klikt u op Stop opname.

De standaardinstelling van de Native Memory Profiler is een steekproefgrootte van 32 bytes: Telkens wanneer 32 bytes geheugen worden gealloceerd, wordt een momentopname van het geheugen gemaakt. Een kleinere steekproefgrootte resulteert in meer frequente momentopnamen, wat meer nauwkeurige gegevens over geheugengebruik oplevert. Een grotere steekproefgrootte levert minder nauwkeurige gegevens op, maar verbruikt minder hulpbronnen op uw systeem en verbetert de prestaties tijdens het opnemen.

Om de steekproefgrootte van de Native Memory Profiler te wijzigen:

Selecteer Uitvoeren > Configuraties bewerken.
Selecteer uw app-module in het linkerdeelvenster.
Klik op het tabblad Profiling en voer de steekproefgrootte in het veldNative memory sampling interval (bytes) in.
Bouw uw app en voer deze opnieuw uit.

Maak een heapdump

Een heapdump laat zien welke objecten in uw app geheugen gebruiken op het moment dat u de heapdump maakt. Vooral na een lange gebruikerssessie kan een heap dump helpen geheugenlekken te identificeren door objecten te tonen die zich nog in het geheugen bevinden en waarvan u denkt dat ze er niet meer zouden moeten zijn.

Nadat u een heap dump hebt vastgelegd, kunt u het volgende bekijken:

Welke soorten objecten uw app heeft toegewezen, en hoeveel er van elk zijn.
Hoeveel geheugen elk object gebruikt.
Waar verwijzingen naar elk object worden vastgehouden in uw code.
De aanroepstapel voor waar een object werd toegewezen. (Oproepstapels zijn momenteel alleen beschikbaar met een heap dump met Android 7.1 en lager wanneer u de heap dump vastlegt tijdens het vastleggen van toewijzingen.)

Om een heap dump vast te leggen, klikt u op Dump Java heap in de Memory Profiler werkbalk.Tijdens het dumpen van de heap, kan de hoeveelheid Java-geheugen tijdelijk toenemen.Dit is normaal omdat de heapdump plaatsvindt in hetzelfde proces als uw app en geheugen nodig heeft om de gegevens te verzamelen.

De heapdump verschijnt onder de geheugentijdlijn en toont alle klassentypen in de heap, zoals weergegeven in figuur 5.

Figuur 5. De heapdump bekijken

Als u nauwkeuriger wilt weten wanneer de dump wordt gemaakt, kunt u een heapdump maken op het kritieke punt in uw app-code doordumpHprofData() op te roepen.

In de lijst met klassen kunt u de volgende informatie zien:

Allocaties: Aantal toewijzingen in de heap.
Native Size: Totale hoeveelheid native geheugen gebruikt door dit objecttype (in bytes). Deze kolom is alleen zichtbaar voor Android 7.0 en hoger.

U zult hier geheugen zien voor sommige objecten die in Java zijn toegewezen omdat Android native geheugen gebruikt voor sommige frameworkklassen, zoalsBitmap.
Omvang: Totale hoeveelheid Java-geheugen die door dit objecttype wordt gebruikt (in bytes).
Retained Size: Totale grootte van het geheugen dat wordt vastgehouden door alle instanties van deze klasse (in bytes).

U kunt de twee menu’s boven de lijst met toegewezen objecten gebruiken om te kiezen welke heapdumps moeten worden geïnspecteerd en hoe de gegevens moeten worden geordend.

Kies in het menu aan de linkerkant welke heap moet worden geïnspecteerd:

standaardheap: Wanneer er geen heap is gespecificeerd door het systeem.
app heap: De primaire heap waarop uw app geheugen toewijst.
image heap: Het systeem boot image, met klassen die worden geladen tijdens het opstarten. Allocaties hier zijn gegarandeerd om nooit te verplaatsen of weg te gaan.
zygote heap: De copy-on-write heap waar een app proces wordt gevorkt van in het Android systeem.

Van het menu aan de rechterkant, kies hoe de toewijzingen te rangschikken:

Rangschikken op klasse: Groepeert alle toewijzingen op basis van de naam van de klasse. Dit is de standaardinstelling.
Ordenen op pakket: Groepeert alle toewijzingen op basis van de naam van het pakket.
Rangschikken op callstack: Groepeert alle toewijzingen in hun corresponderende aanroepstack. Deze optie werkt alleen als u de heap dump vastlegt tijdens het opnemen van toewijzingen. Zelfs dan, zijn er waarschijnlijk objecten in de heap die werden gealloceerd voordat u begon met opnemen, dus die toewijzingen verschijnen eerst, gewoon gerangschikt op class name.

De lijst wordt standaard gesorteerd op de Retained Size kolom. Om op de waarden in een andere kolom te sorteren, klikt u op de kop van de kolom.

Klik op een klassenaam om het Instance View venster rechts te openen (zie figuur 6). Elke vermelde instantie bevat het volgende:

Diepte: Het kortste aantal hops van een GC root naar de geselecteerde instantie.
Native Size: Grootte van deze instantie in native geheugen.Deze kolom is alleen zichtbaar voor Android 7.0 en hoger.
Shallow Size: Grootte van deze instantie in het Java-geheugen.
Retained Size: Grootte van het geheugen dat deze instantie domineert (volgens de dominator tree).

Figuur 6. De tijd die nodig is om een heapdump te maken, wordt aangegeven in de tijdlijn

Om uw heap te inspecteren, volgt u deze stappen:

Blader door de lijst om objecten te vinden die ongewoon grote heap counts hebben en die mogelijk gelekt zijn. Om bekende klassen te vinden, klikt u op de kop van de kolom Class Name om alfabetisch te sorteren. Klik vervolgens op een klassenaam. Rechts verschijnt het deelvenster Instance View, waarin elke instantie van die klasse wordt weergegeven, zoals in figuur 6.
- U kunt ook snel objecten vinden door op Filter te klikken, of door op Control+F (Command+F op de Mac) te drukken en een klasse- of pakketnaam in het zoekveld in te voeren. U kunt ook zoeken op methode naam als uArrange by callstack selecteert in het dropdown menu. Als u regelmatige expressies wilt gebruiken, vinkt u het vakje naast Regex aan. Schakel het selectievakje naastMatch case in als uw zoekopdracht hoofdlettergevoelig is.
Klik in het deelvenster Instance View op een instantie. Het verwijzingsstabblad verschijnt eronder en toont elke verwijzing naar dat object.
Of klik op de pijl naast de naam van de instantie om alle velden ervan weer te geven, en klik vervolgens op een veldnaam om alle verwijzingen ervan weer te geven. Als u de details van een instantie voor een veld wilt bekijken, klikt u met de rechtermuisknop op het veld en selecteert u Go to Instance.
In het tabblad References kunt u, als u een verwijzing ziet die mogelijk geheugenverlies veroorzaakt, er met de rechtermuisknop op klikken en Go to Instance selecteren. Dit selecteert de corresponderende instantie van de heap dump, waardoor u de eigen instantie gegevens.

In uw heap dump, kijk voor geheugenlekken veroorzaakt door een van de volgende:

Langlevende verwijzingen naar Activity, Context,View, Drawable, en andere objecten die een verwijzing naar de Activity of Context container zou kunnen bevatten.
Niet-statische binnenklassen, zoals een Runnable, die een Activity-instantie kunnen bevatten.
Caches die objecten langer vasthouden dan nodig is.

Een heap dump opslaan als een HPROF-bestand

Nadat u een heap dump hebt vastgelegd, zijn de gegevens alleen zichtbaar in de Memory Profiler terwijl de profiler wordt uitgevoerd. Wanneer u de profileringsessie afsluit, verliest u de heap dump. Dus, als u het wilt bewaren om later te bekijken, exporteer de heap dump dan naar een HPROF bestand. In Android Studio 3.1 en lager, is de Exporteren capture naar bestand knop aan de linkerkant van de werkbalk onder de tijdlijn; in Android Studio 3.2 en hoger, is er een Export Heap Dump knop aan de rechterkant van elke Heap Dump entry in het Sessions deelvenster. In de Export Asdialoog die verschijnt, slaat u het bestand op met de .hprof bestandsnaamextensie.

Om een andere HPROF analyzer zoalsjhat te gebruiken, moet u het HPROF bestand converteren van het Android formaat naar het Java SE HPROF formaat. U kunt dit doen met het hprof-conv gereedschap dat u vindt in deandroid_sdk/platform-tools/ directory. Voer het hprof-convcommando uit met twee argumenten: het originele HPROF bestand en de locatie om het geconverteerde HPROF bestand te schrijven. Bijvoorbeeld:

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

Een heap dump bestand importeren

Om een HPROF (.hprof) bestand te importeren, klikt u op Start a new profiling session in het deelvensterSessions, selecteert u Load from file, en kiest u het bestand uit de bestandsbrowser.

U kunt ook een HPROF bestand importeren door het vanuit de bestandsbrowser naar eeneditor venster te slepen.

Leak detectie in Memory Profiler

Bij het analyseren van een heap dump in de Memory Profiler, kunt u profiling data filteren waarvan Android Studio denkt dat het zou kunnen wijzen op geheugenlekken voor Activity enFragment instanties in uw app.

De soorten gegevens die het filter toont, omvatten het volgende:

Activity instanties die zijn vernietigd, maar waarnaar nog steeds wordt verwezen.
Fragment instanties die geen geldige FragmentManager hebben, maar waarnaar nog steeds wordt verwezen.

In bepaalde situaties, zoals de volgende, kan het filter valse positieven opleveren:

Een Fragment is gemaakt, maar is nog niet gebruikt.
Een Fragment wordt gecached, maar niet als onderdeel van een FragmentTransaction.

Om deze functie te gebruiken, maakt u eerst een heap dump of importeert u een heap dump bestand in Android Studio. Om de fragmenten en activiteiten weer te geven die mogelijk geheugen lekken, selecteert u het selectievakje Activity/Fragment Leaks in het deelvenster heapdump van de Memory Profiler, zoals weergegeven in figuur 7.

Figuur 7. Een heapdump filteren op geheugenlekken.

Technieken voor het profileren van uw geheugen

Tijdens het gebruik van de Memory Profiler moet u uw app-code onder druk zetten en proberen geheugenlekken op te sporen. Een manier om geheugenlekken in uw app uit te lokken is deze een tijdje te laten draaien alvorens de heap te inspecteren. Lekken kunnen doorsijpelen naar de top van de toewijzingen in de heap. Hoe kleiner het lek, hoe langer u de app moet laten draaien om het te zien.

U kunt ook een geheugenlek veroorzaken op een van de volgende manieren:

Roteer het apparaat van staand naar liggend en weer terug, meerdere keren terwijl het in verschillende activiteitstoestanden is. Het draaien van het apparaat kan er vaak voor zorgen dat eenActivity,Context, ofView object lekt omdat het systeem de Activity aanmaakt en als uw app ergens anders een verwijzing naar een van deze objecten vasthoudt, kan het systeem het niet ophalen.
Schakel tussen uw app en een andere app terwijl u zich in verschillende activiteitstoestanden bevindt (navigeer naar hetHome-scherm, keer dan terug naar uw app).

Tip: U kunt de bovenstaande stappen ook uitvoeren door gebruik te maken van hetonkeyrunner testframework.