Ha az alkalmazásunk lassú egyes eszközökön, vagy az Android Studio azonnali futtatási funkciói véletlenszerűen nem működnek, akkor lehet, hogy memóriaszivárgást tapasztalunk.
Mikor történik a memóriaszivárgás?
A Java egyik nagyszerű tulajdonsága a szemétgyűjtő (GC). A szemétgyűjtő rendszeresen lefut, hogy ellenőrizze a nem használt objektumokat, és eltávolítsa őket. A memóriaszivárgás akkor következik be, ha vannak olyan objektumok, amelyeket nem használ az alkalmazás, de a szemétgyűjtő nem tudja felismerni őket. Ezért használatlanul maradnak a memóriában, csökkentve az alkalmazás számára rendelkezésre álló memória mennyiségét, ami váratlan eredményeket okoz.
Hogyan lehet felismerni a memóriaszivárgást?
Ez többféleképpen is történhet. Ebben a cikkben ezek közül néhányat tárgyalunk.
De először írjunk néhány olyan kódot, amely memóriaszivárgást okozhat. Létrehozunk egy alkalmazást két tevékenységgel. Az A tevékenységnek lesz egy gombja, amely megnyitja a B tevékenységet. Ezzel együtt létrehozunk egy singleton osztályt is, amely egy Context statikus hivatkozását tartja.
class Manager {
private static Manager ourInstance;
private Context context;
static Manager getInstance(Context context) {
if (ourInstance == null) {
ourInstance = new Manager(context);
}
return ourInstance;
}
private Manager(Context context) {
this.context = context;
}
}
}
Az A tevékenységből fogjuk meghívni ezt a singletont
Manager.getInstance(this);
Memóriaszivárgások felderítése az Android Studio monitorainak használatával
Android Studio praktikus eszközöket biztosít az alkalmazás teljesítményének profilozásához, és ezek egyike a Memory Monitor. A Memory Monitor segítségével a memóriaszivárgásokat a következő lépéseken keresztül észlelhetjük:
1. Futtassa az alkalmazást a mobileszközén vagy egy emulátoron.
2. Nyissa meg az Android Monitor-t (Macen nyomja meg a Cmd + 6 vagy Windowson az Alt + 6 billentyűkombinációt). A Memory Monitor tetején kattintson az Allokációkövetés indítása gombra.
3. Használja az alkalmazást azon rész körül, amelyről feltételezi, hogy memóriaszivárgást tapasztalhat. Példánkban egy másik tevékenységre megyünk.
4. Kattintson a Initiate GC gombra, hogy rákényszerítse a szemétgyűjtőt az éppen nem használt objektumok összegyűjtésének megkezdésére és eltávolítására. Látnia kell, hogy a memóriagrafikon egy kicsit csökken.
5. Kattintson a Dump Java Heap gombra, hogy az Android Studio generáljon egy .hprof fájlt, amely egy heap pillanatképet tartalmaz. A memóriaszivárgás ellenőrzésének legegyszerűbb módja az Analyzer Tasks
6. Nyissa meg az Analyzer Tasks lapot, majd kattintson a lap tetején a Run gombra. A kiszivárgott tevékenységeket az Analyzer Tasks lap alatti Analysis Results fülön kell látnia.
Detecting Memory Leaks Using Leak Canary
A Leak Canary egy Square által készített könyvtár, és nagyon gyors módja a memóriaszivárgások felderítésének. A Leak Canary lehetővé teszi a memóriaszivárgások felderítését hosszabb futások során, mivel nem kell csatlakoztatni a készüléket az Android Studio-hoz és hosszú ideig figyelni az alkalmazást. A Leak Canary értesítést küld, ha memóriaszivárgás van.
A Leak Canary integrálása nagyon egyszerű. Mindössze annyit kell tennie, hogy hozzáadja a következőket az alkalmazás szintű build.gradle fájljához:
dependencies {
debugCompile ‘com.squareup.leakcanary:leakcanary-android:1.5.1’
releaseCompile ‘com.squareup.leakcanary:leakcanary-android-no-op:1.5.1’
testCompile ‘com.squareup.leakcanary:leakcanary-android-no-op:1.5.1’
}
Ezután a következő kódot adjuk hozzá az Application osztályunkhoz:
@Override public void onCreate() {
super.onCreate();
if (LeakCanary.isInAnalyzerProcess(this)) {
// Ez a folyamat a LeakCanary számára van fenntartva a halomelemzéshez.
// Az alkalmazásodat nem ebben a folyamatban kell initálnod.
return;
}
LeakCanary.install(this);
// Normál alkalmazásinit kód…
}
És ennyi, készen állsz.
A lehetséges szivárgások felderítése az Inferrel
Az Infer a Facebook által készített statikus elemző eszköz, amely segít megtalálni a lehetséges nullmutató kivételeket és erőforrás-szivárgásokat, valamint a megjegyzések elérhetőségét, a hiányzó lock guardokat és az egyidejűség versenyfeltételeit. Ez egy jó eszköz, amit érdemes hozzáadni a CI-hez, hogy minden lehetséges hibát leküzdhessünk. Emellett nyílt forráskódú, így az eszköz fejlesztése még mindig fejlődik. Az Inferről bővebb információt a gyorsindítási dokumentációban találsz.