Érdemes szem előtt tartani, hogy míg ez az eszköz nagyon hasznos lehet a feltételezett szivárgásra utaló hivatkozások megtalálásában, az ismeretlen szivárgások felkutatásához elég nehéz és összetett lehet, és meglehetősen sok elemzést igényel. Ennek ellenére, ha elsajátítod – nagyszerű eszköz a kezedben!

LeakCanary

Egy másik módja a memóriaszivárgások keresésének a Leak Canary használata, egy Square által létrehozott könyvtár, amely segít a memóriaszivárgások felderítésében. Ez egy ObjectWatcher osztály használatával működik, amely gyenge hivatkozásokat tart a halomban lévő megsemmisített objektumokra. Ha a hivatkozás nem törlődik a következő öt másodpercben, és a Garbage Collector lefutott, az objektumot megtartottnak tekinti, és ezt potenciális memóriaszivárgásként naplózza a logcatben. Elég okos, nem?

Az induláshoz egyszerűen add hozzá a könyvtárat a függőségeken belül a build.gradle fájlodhoz, szinkronizáld és fordítsd le.

Amint elindítod az alkalmazást, a logcatben láthatod a LeakCanary kimenetét, amint figyeli a pillanatokat és megtartja az objektumokat. A szivárgás kiváltásához hozzáadtam néhány új feladatot a TaskManager alkalmazásomban. Nem sokkal később ezt az értesítést kaptam a LeakCanary-tól, amely egy lehetséges szivárgást jelez!

Egyszerűen kattintson az értesítésre, hogy “dump heap” a lehetséges szivárgás vizsgálatához, és ez a párbeszédpanel jelenik meg az alkalmazásban.

A Leak Canary ezután elemzi a kupacot a visszatartott objektumok felkutatásán keresztül, és megtalálja a szivárgás nyomát, amely az egyes visszatartott objektumokra való hivatkozások útvonala. Ha ez megtörtént, megjelenik egy értesítés, amely összefoglalja a visszatartott objektumok és a szivárgások számát.

Úgy tűnik, megtalálta a szivárgásunkat! Ha rákattintunk, láthatjuk a teljes szivárgás nyomvonalát:

Ez azt mondja, hogy a TaskActivity szivárog, és az aláhúzott hivatkozások mutatják a nyomvonalat, a mContext-ból szivárog a SingletonExample-be – ismerősen hangzik! Most már tudjuk, hogyan találjuk meg a szivárgást a LeakCanary segítségével. 😃

Memóriaszivárgások elkerülése

Szóval most, hogy megtaláltuk a memóriaszivárgást, hogyan kerülhetjük el őket a jövőben? Az alábbiakban bemutatjuk a leggyakoribb okokat és mintákat.

Broadcast receivers

A broadcast receivers arra használható, hogy figyelje a rendszerszintű broadcast eseményeket vagy intenteket, amelyek az eszközzel kapcsolatos információkat, például az akkumulátor alacsony töltöttségét jelzik, dátum és kapcsolódási változások – például, hogy a repülőgépes üzemmódot kikapcsolták. Használatuk során nem szabad elfelejtenünk, hogy a broadcast-vevőkészülékeket le kell törölnünk, különben elkerülhetetlenül megmarad a tevékenységre való hivatkozás.

Hogyan kerüljük el: Mindössze annyit kell tennünk, hogy meghívjuk a unregister() broadcast vevőnket a onStop()-ben az aktivitásunkban.

Ez a minta megtalálható az asyncTask, TimerTask és szálak esetében is, amelyeket a onDestroy()-ben kell törölni a szivárgás elkerülése érdekében.

Context to Singleton class

Néha kontextust kell átadnunk egy aktivitásból egy Singleton osztályba. Erre példa lehet egy utils osztály, ahol erőforrásokat, szolgáltatásokat vagy belső fájlokat kell elérnünk. A kontextus átadása azonban azt jelenti, hogy elkerülhetetlenül megtartjuk a tevékenységre való hivatkozást.

Hogyan kerüljük el: Ahelyett, hogy átadnánk this egy aktivitásból, átadhatjuk az alkalmazás kontextusát, ha az rendelkezésre áll (ha többet szeretne megtudni arról, hogy mikor melyik kontextust kell használni, akkor ezt a cikket nagyon hasznosnak találtam!) Egy alternatív megoldás, ha biztosítjuk, hogy a Singleton kontextust nullára állítjuk a tevékenység onDestroy() metódusán belül.

Statikus hivatkozások

Egy nézet vagy tevékenység statikusként való hivatkozása azt jelenti, hogy a tevékenységre való hivatkozás nem kerül szemétgyűjtésre. Ezt egyszerűen mindig el kell kerülni.

Hogyan kerüljük el: onDestroy().

Belső osztályok hivatkozásai

A belső osztályok gyakran okoznak szivárgást azzal, hogy implicit hivatkozást tartanak a külső osztályra. Ez akkor történik, ha az osztály változója statikusnak van deklarálva, vagy ha maga az osztály nincs statikusnak deklarálva. Zavaró? Igen, de könnyen elkerülhető, ha betartjuk az alábbi egyszerű szabályt.

Hogyan kerüljük el: Tegyük a belső osztályt statikussá, hogy elkerüljük a külső osztályra való hivatkozás tartását, és soha ne hozzunk létre egy belső osztály statikus változóját. Ugyanez vonatkozik az anonim osztályokra is.

Ez az! Remélem, tanultál néhány dolgot a memóriaszivárgásról és annak elkerüléséről. Boldog kódolást! 😄

Itt van néhány cikk és dokumentáció, amit különösen hasznosnak találtam a memóriaszivárgások megismerése során: