Ждере меморију и надувава се — шта је то, узроци и како избећи

Шта је цурење меморије и надувавање апликације?

Цурење меморије (memory leak) — ситуација када објекат који више није потребан апликацији наставља да се задржава у heap-у јер постоји активна референца из коренског скупа (GC Root). Сакупљач отпада сматра такав објекат живим и не брише га.

Надувавање меморије (memory bloat) — шири проблем када апликација троши више меморије него што је потребно за обављање текућих задатака. Узроци: прекомерно кеширање, дуплирање објеката, неоптималне структуре података и фрагментација heap-а.

У Android-у свакој апликацији је додељен ограничен heap (обично 64-512 MB у зависности од уређаја и верзије ОС-а). У iOS-у ограничење је мање строго, али систем шаље упозорење о меморији при приближавању граници.

Према Facebook Engineering Blog, цурења меморије су узрок ~15% crash извештаја у мобилним апликацијама. У Android-у се томе додају ANR због честих GC пауза при недостатку меморије.

Типични обрасци цурења меморије у Android и iOS

Статичка референца на Activity — класика Android цурења. Ако статичко поље или синглтон чува референцу на Activity, она неће бити сакупљена од GC чак ни након finish(), док је синглтон жив. Activity је тежак објекат који садржи View хијерархију, ресурсе и Context.

object LeakHolder {
    var activityRef: Activity ?= null // цурење: статичка референца на Activity
}

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle ?= null) {
        super.onCreate(savedInstanceState)
        LeakHolder.activityRef = this // ❌ MainActivity никада неће бити сакупљен од GC
    }
}

Анонимне класе и ламбде — имплицитно задржавају референцу на спољашњу класу. Ако се Runnable или Callback проследи спољашњем сервису, а Activity се уништи, објекат анонимне класе још увек виси у реду и не дозвољава Activity-ју да оде на сакупљање отпада.

• Handler са кашњењем — ако је Activity уништен, а Handler.postDelayed још није извршен, Activity цури
• Thread и AsyncTask — при ротацији екрана Activity се поново креира, а стари Thread наставља да држи референцу на старо Activity
• Retrofit/Callback — анонимни Callback задржава референцу на презентер или фрагмент
• Посматрачи (Observers) — LiveData или RxJava претплате без отказа при onDestroy

У iOS-у главни проблем су retain cycles: два објекта држе снажне референце један на другог, а ARC не може да нулира бројач референци ни за један. Типичан случај: closure који снажно хвата self, и self који држи референцу на closure.

Како открити цурења меморије?

LeakCanary — библиотека од Square за аутоматско откривање цурења у Android-у. Након уништења Activity или Fragment проверава да ли је објекат сакупљен од GC. Ако није — прави heap dump и приказује trace цурења.

// LeakCanary 2.x — ауто-интеграција преко Application
class ExampleApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        // LeakCanary се аутоматски инсталира у debug build-у
        // преко ContentProvider-а — подешавање без кода
    }
}

// Принудни позив провере
AppWatcher.objectWatcher.watch(watchedObject, "leak description")

Android Studio Profiler — уграђени алат за праћење меморије у реалном времену. Омогућава снимање heap dump-а, проналажење сумњивих објеката (Retained Size > 1 MB) и праћење GC root пута до сваког објекта.

За iOS користите Xcode Memory Graph Debugger. Он визуализује граф објеката у меморији, приказује retain cycles и омогућава тренутно откривање кружних референци. Такође је доступан Instruments > Allocations за дугорочно праћење.

Стратегије спречавања цурења

WeakReference — основни механизам за референце које не треба да ометају сакупљање отпада. Ако GC одлучи да обрише објекат, WeakReference враћа null. Користи се за повратне позиве, слушаоце и референце на UI компоненте из позадинских нити.

Lifecycle-aware компоненте — архитектонски приступ имплементиран у Android Jetpack (Lifecycle, LiveData, Flow, coroutines). Претплате се аутоматски отказују при onDestroy, што елиминише главну класу цурења.

class MyViewModel : ViewModel() {
    private val _data = MutableLiveData<List<User>>()
    val data: LiveData<List<User>> get() = _data

    fun loadData() {
        viewModelScope.launch {
            val result = repository.fetchData()
            _data.postValue(result)
            // корутина се аутоматски отказује при onCleared()
        }
    }
}

viewModelScope и lifecycleScope — уграђени CoroutineScope у Android-у који се отказују при одговарајућем догађају животног циклуса. Ово елиминише цурења кроз корутине — најчешћи сценарио у савременом Android развоју.

• Немојте користити статичке референце на Context, Activity, View или Fragment
• Откажите све RxJava претплате у disposeBag / CompositeDisposable при onDestroy
• Користите [weak self] / [unowned self] у iOS замыкањима за спречавање retain cycles
• Проверавајте Bitmap и велике објекте — треба их рециклирати или поништити

Алати за профилисање меморије

Memory Profiler in Android Studio — главни алат за праћење heap-а. Приказује живе алокације, снимке heap-а, број објеката по типовима. Омогућава снимање dump-а и анализу у MAT (Memory Analyzer Tool) за проналажење сумњивих објеката.

Eclipse MAT — десктоп анализатор heap dump-а. Након учитавања HPROF датотеке из Android Studio, MAT гради стабло доминатора, приказује retain size сваког објекта и нуди аутоматску анализу сумњивих цурења кроз Leak Suspects Report.

Xcode Memory Graph — визуелни дебагер retain cycles. При клику на дугме Memory Graph Debugger, Xcode зауставља апликацију, гради потпун граф објеката у меморији и истиче retain cycles црвеном бојом.

Према Google I/O 2023, апликације које користе LeakCanary у debug верзијама смањују број crash-ова везаних за меморију за 30-50% у прва 2 месеца након имплементације. Препоручује се додавање LeakCanary у фази онбординга пројекта.