The playground

More information here

Geheugen lekken in Android – identificeren, behandelen en voorkomen

Johan Olsson Volgen Apr 13, 2016 · 9 min lezen In ons dagelijks streven naar het bouwen van betere apps, wij als ontwikkelaars moeten veel dingen rekening houden om op koers te blijven, een daarvan is om ervoor te zorgen dat onze apps niet crashen. Een veel voorkomende oorzaak van crashes zijn geheugenlekken. Dit specifieke […]
Johan Olsson
Johan Olsson

Volgen

Apr 13, 2016 · 9 min lezen

In ons dagelijks streven naar het bouwen van betere apps, wij als ontwikkelaars moeten veel dingen rekening houden om op koers te blijven, een daarvan is om ervoor te zorgen dat onze apps niet crashen. Een veel voorkomende oorzaak van crashes zijn geheugenlekken. Dit specifieke probleem kan zich in verschillende vormen manifesteren. In de meeste gevallen zien we een gestage toename van het geheugengebruik totdat de app niet meer middelen kan toewijzen en onvermijdelijk crasht. In Java resulteert dit vaak in een Outofmemoryuitzondering wordt gegooid. In sommige zeldzame gevallen, gelekt klassen kunnen zelfs blijven voor lang genoeg om geregistreerde callbacks te ontvangen, waardoor een aantal echt vreemde bugs en maar al te vaak gooien de beruchte IllegalStateException.

om anderen te helpen de tijd die besteed wordt aan code-analyse te minimaliseren zal ik een paar voorbeelden van geheugenlekken presenteren, hoe ze te identificeren in Android Studio en vooral hoe ze te verwijderen.

Disclaimer

Het doel van deze post en zijn codevoorbeelden is om een beter begrip van geheugenbeheer te bevorderen, vooral in Java. De algemene architectuur, het beheer van threads en de afhandeling van het uitvoeren van HTTP-verzoeken getoond zijn niet ideaal voor een productie-omgeving en alleen dienen als drager van het punt wordt gemaakt: geheugenlekken in Android is een ding om te worden beschouwd.

het registreren van luisteraars

Dit zou niet echt een probleem moeten zijn, maar al te vaak zie ik oproepen naar verschillende registermethoden, maar hun niet-geregistreerde tegenhangers zijn nergens te zien. Dit is een Potentiële Bron van lekken, aangezien deze methoden duidelijk zijn ontworpen om door elkaar te worden afgewogen. Zonder het aanroepen van de unregistreren methode, de instantie zal waarschijnlijk houden een referentie rond lang nadat het object waarnaar wordt verwezen is beëindigd en zal dus beginnen met het lekken van het geheugen. In Android is dit vooral lastig als dat object een activiteit is, omdat ze vaak een grote hoeveelheid gegevens bevatten. Ik zal je laten zien hoe dat eruit ziet.

in dit voorbeeld laten we de Android LocationManager ons informeren over locatie-updates. Alles wat we nodig hebben om dit op te zetten is de systeemservice zelf en een callback om de updates te ontvangen. Hier implementeren we de locatie-interface in de activiteit zelf, wat betekent dat de LocationManager een verwijzing naar onze activiteit zal bevatten. Nu als het apparaat zou worden geroteerd, een nieuwe activiteit zou worden gemaakt ter vervanging van de oude al geregistreerd voor locatie-updates. Aangezien een systeemservice zeker elke activiteit zal overleven, zal de LocationManager nog steeds een verwijzing naar de vorige activiteit bevatten, waardoor het onmogelijk is voor de garbage collector om de middelen terug te vorderen die nog steeds verbonden zijn aan die specifieke activiteit, wat resulteert in geheugen wordt gelekt. Herhaalde rotatie van het apparaat zal dan leiden tot niet-terugvorderbare activiteiten om het geheugen te vullen, uiteindelijk leidt tot een Outofmemoryexceptie.

maar om een geheugenlek op te lossen, moeten we het eerst kunnen vinden. Gelukkig Android Studio heeft een ingebouwde tool genaamd Android Monitor we kunnen gebruiken om geheugengebruik te observeren onder andere dingen. Het enige wat we echt hoeven te doen is het openen van de Android-Monitor en ga naar het tabblad monitoren om te zien hoeveel geheugen wordt gebruikt en toegewezen in real time.

de Android Monitor in Android Studio 2.0

alle interacties die brontoewijzing veroorzaken, worden hier weergegeven, waardoor het een ideale plek is om het gebruik van uw applicatie bij te houden. Om ons geheugenlek te vinden, moeten we weten wat het geheugen bevat op een moment dat we vermoeden dat het geheugen is gelekt. Voor dit specifieke voorbeeld hoeven we alleen maar onze applicatie te starten, het apparaat een keer te draaien en vervolgens de Dump Java Heap actie aan te roepen (naast het geheugen, het derde icoon van links). Dit zal een hprof bestand genereren, dat een geheugen snapshot bevat op het moment dat we de actie aanroepen. Na een paar seconden, Android Studio opent automatisch het bestand, waardoor we een nette visuele weergave van het geheugen voor eenvoudige analyse.

Ik zal niet dieper ingaan op het navigeren door de enorme geheugenhoop. In plaats daarvan zal ik uw aandacht richten op de Analyzer taken in de rechterbovenhoek van de screenshot hieronder. Het enige wat u hoeft te doen om het geheugenlek te detecteren dat in het bovenstaande voorbeeld is geïntroduceerd, is het detecteren van gelekte activiteiten controleren en vervolgens op Afspelen drukken om de gelekte activiteit te laten verschijnen onder analyseresultaten.

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.