The playground

More information here

Memory leaks i Android – identificere, behandle og undgå

Johan Olsson Følg Apr 13, 2016 · 9 min læse I vores daglige udøvelse af bygning bedre apps, vi som udviklere er nødt til at tage mange ting i betragtning for at være på rette spor, hvoraf den ene er at sørge for, at vores apps ikke kører galt. En almindelig årsag til nedbrud er […]
Johan Olsson
Johan Olsson

Følg

Apr 13, 2016 · 9 min læse

I vores daglige udøvelse af bygning bedre apps, vi som udviklere er nødt til at tage mange ting i betragtning for at være på rette spor, hvoraf den ene er at sørge for, at vores apps ikke kører galt. En almindelig årsag til nedbrud er hukommelseslækager. Dette særlige problem kan manifestere sig i forskellige former. I de fleste tilfælde ser vi en jævn stigning i hukommelsesforbruget, indtil appen ikke kan allokere flere ressourcer og uundgåeligt går ned. I Java resulterer dette ofte i en Outofmemoryundtagelse bliver kastet. I nogle sjældne tilfælde, lækkede klasser kan endda holde sig længe nok til at modtage registrerede tilbagekald, forårsager nogle virkelig mærkelige bugs og kaster alt for ofte den berygtede ulovlige undtagelse.

for at hjælpe andre med at minimere tid brugt på kodeanalyse vil jeg præsentere et par eksempler på hukommelseslækager, hvordan man identificerer dem i Android Studio og vigtigst af alt, hvordan man fjerner dem.

ansvarsfraskrivelse

formålet med dette indlæg og dets kodeeksempler er at fremme en dybere forståelse af hukommelsesstyring, især i Java. Den generelle arkitektur, styring af tråde og håndtering af kørende HTTP-anmodninger, der vises, er ikke ideel til et produktionsmiljø og tjener kun som bærer af det punkt, der gøres: hukommelseslækager i Android er en ting, der skal overvejes.

registrering af lyttere

Dette burde ikke rigtig være et problem, men alt for ofte ser jeg opkald til forskellige registermetoder, men deres uregistrerede kolleger er ingen steder at se. Dette er en potentiel kilde til lækager, da disse metoder klart er designet til at blive afbalanceret af hinanden. Uden at kalde unregister-metoden, vil forekomsten sandsynligvis holde en reference længe efter, at det refererede objekt er afsluttet og vil således begynde at lække hukommelse. I Android er dette især besværligt, hvis objektet er en aktivitet, da de ofte indeholder en stor mængde data. Lad mig vise dig, hvordan det kan se ud.

i dette eksempel lader vi Android LocationManager informere os om placeringsopdateringer. Alt, hvad vi har brug for for at konfigurere dette, er selve systemtjenesten og et tilbagekald for at modtage opdateringerne. Her implementerer vi placeringsgrænsefladen i selve aktiviteten, hvilket betyder, at LocationManager vil have en henvisning til vores aktivitet. Hvis enheden nu skulle roteres, oprettes en ny aktivitet, der erstatter den gamle, der allerede er registreret til placeringsopdateringer. Da en systemtjeneste helt sikkert vil overleve enhver aktivitet, LocationManager vil stadig have en henvisning til den tidligere aktivitet, hvilket gør det umuligt for affaldssamleren at genvinde de ressourcer, der stadig er bundet til den pågældende aktivitet, hvilket resulterer i, at hukommelsen lækkes. Gentagen rotation af enheden vil derefter medføre, at ikke-genanvendelige aktiviteter fylder hukommelsen, hvilket i sidste ende fører til en usædvanlig undtagelse.

men for at rette en hukommelseslækage skal vi først kunne finde den. Heldigvis har Android Studio et indbygget værktøj kaldet Android Monitor, som vi blandt andet kan bruge til at observere hukommelsesforbrug. Alt, hvad vi virkelig skal gøre, er at åbne Android-skærmen og gå til fanen skærme for at se, hvor meget hukommelse der bruges og tildeles i realtid.

Android Monitor i Android Studio 2.0

eventuelle interaktioner, der forårsager ressourceallokering, afspejles her, hvilket gør det til et ideelt sted at holde styr på din applikations ressourceforbrug. For at finde vores hukommelseslækage skal vi vide, hvad hukommelsen indeholder på et tidspunkt, hvor vi har mistanke om, at hukommelsen er lækket. I dette særlige eksempel er alt, hvad vi skal gøre, at starte vores applikation, rotere enheden en gang og derefter påkalde Dump Java Heap-handlingen (ved siden af hukommelsen, det tredje ikon fra venstre). Dette genererer en hprof-fil, der indeholder et hukommelsesbillede på det tidspunkt, hvor vi påberåbte handlingen. Efter et par sekunder åbner Android Studio automatisk filen, hvilket giver os en pæn visuel repræsentation af hukommelsen til nem analyse.

Jeg vil ikke gå i dybden om, hvordan man navigerer i den enorme hukommelseshaug. I stedet vil jeg rette din opmærksomhed mod Analysatoropgaverne i øverste højre hjørne af skærmbilledet nedenfor. Alt hvad du skal gøre for at opdage hukommelseslækage introduceret i eksemplet ovenfor er at kontrollere opdage lækkede aktiviteter og derefter trykke på play for at få den lækkede aktivitet til at dukke op under analyseresultater.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.