Je třeba mít na paměti, že zatímco tento nástroj může být velmi užitečný pro nalezení odkazů na podezřelý únik, jeho použití pro nalezení neznámých úniků může být poměrně obtížné a složité a vyžaduje poměrně dlouhou analýzu. Přesto, pokud jej zvládnete – je to skvělý nástroj, který můžete mít pod palcem!
LeakCanary
Dalším způsobem, jak najít úniky paměti, je použití knihovny Leak Canary vytvořené společností Square, která vám pomůže odhalit úniky paměti. Funguje pomocí třídy ObjectWatcher, která uchovává slabé reference na zničené objekty v haldě. Pokud není reference vymazána v následujících pěti sekundách a Garbage Collector se spustil, objekt je považován za zachovaný a zaznamená to jako potenciální únik paměti v logcatu. Docela chytré, co?“
Chcete-li začít, jednoduše přidejte knihovnu uvnitř závislostí do souboru build.gradle, synchronizujte a zkompilujte.
Jakmile spustíte aplikaci, můžete v logcatu vidět výstup LeakCanary, jak sleduje instance a uchovává objekty. Pro spuštění úniku jsem do aplikace TaskManager přidal několik nových úloh. Netrvalo dlouho a od LeakCanary jsem dostal toto oznámení, které indikuje potenciální únik!
Pro prozkoumání potenciálního úniku stačí kliknout na oznámení „dump heap“ a v aplikaci se zobrazí tento dialog.
Leak Canary pak analyzuje haldu prostřednictvím lokalizace zachovaných objektů a najde stopu úniku, což je cesta odkazů na každý zachovaný objekt. Po dokončení se zobrazí oznámení shrnující počet zadržených objektů a úniků.
Vypadá to, že našel náš únik! Pokud na něj klikneme, uvidíme celou stopu úniku:
Říká nám, že uniká TaskActivity a podtržené odkazy ukazují stopu, uniká z mContext v SingletonExample – to zní povědomě! Nyní již víme, jak únik zjistit pomocí nástroje LeakCanary. 😃
Předcházení únikům paměti
Takže teď, když jsme našli náš únik paměti, jak se jim můžeme v budoucnu vyhnout? Níže uvádíme některé z nejčastějších příčin a vzorů.
Přijímače vysílání
Přijímače vysílání lze použít k naslouchání událostem nebo záměrům vysílání v rámci celého systému, které informují o zařízení, například o slabé baterii, datum a změny připojení – například že byl vypnut režim letadla. Při jejich používání musíme pamatovat na zrušení registrace vysílacích přijímačů, jinak si nevyhnutelně ponecháme odkaz na danou činnost.
Jak se tomu vyhnout:
Tento vzor se vyskytuje také u asyncTask, TimerTask a vláken, která je třeba zrušit v onDestroy(), aby nedošlo k úniku.
Kontext do třídy Singleton
Někdy potřebujeme předat kontext z aktivity do třídy Singleton. Příkladem může být třída utils, kde potřebujeme přistupovat ke zdrojům, službám nebo interním souborům. Předávání kontextu však znamená, že nevyhnutelně držíme odkaz na aktivitu.
Jak se tomu vyhnout: Místo předávání this z aktivity můžeme předat kontext aplikace, pokud je k dispozici (pokud se chcete dozvědět více o tom, kdy použít který kontext, velmi mi pomohl tento článek!). Alternativním řešením je zajistit, abychom uvnitř metody aktivity onDestroy() nastavili kontext Singleton na null.
Statické reference
Referencování pohledu nebo aktivity jako statické znamená, že odkaz na aktivitu nebude vybírán do koše. Tomu je třeba se jednoduše vždy vyhnout.
Jak se tomu vyhnout: Pokud to z nějakého důvodu musíte udělat, můžete zajistit její zničení tím, že ji nastavíte na null v onDestroy().
Vnitřní odkazy na třídy
Vnitřní třídy často způsobují úniky tím, že drží implicitní odkaz na vnější třídu. To se stává proměnná třídy je deklarována jako statická nebo pokud třída sama není deklarována jako statická. Je to matoucí? Ano, ale lze se tomu snadno vyhnout, pokud se budeme řídit jednoduchým pravidlem uvedeným níže.
Jak se tomu vyhnout: Udělejte vnitřní třídu statickou, abyste nemuseli držet odkaz na vnější třídu, a nikdy nevytvářejte statickou proměnnou vnitřní třídy. Totéž platí pro anonymní třídy.
To je vše! Doufám, že jste se dozvěděli něco o únicích paměti a o tom, jak se jim vyhnout. Šťastné kódování! 😄
Tady je řada článků a dokumentace, které mi při učení o únicích paměti přišly obzvlášť užitečné: