Изяжда памет и се подува — какво е, причини и как да избегнем

Какво е изтичане на памет и подуване на приложението?

Изтичане на памет (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 изтичанията. Ако статично поле или singleton съхранява референция към Activity, тя няма да бъде събрана от GC дори след finish(), докато singleton е жив. 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 да бъде събрана от GC.

• Handler със закъснение — ако Activity е унищожена, но Handler.postDelayed все още не е изпълнен, Activity изтича
• Thread и AsyncTask — при завъртане на екрана Activity се пресъздава, но старата Thread продължава да държи референция към старата Activity
• Retrofit/Callback — анонимен Callback задържа референция към presenter или fragment
• Наблюдатели (Observers) — LiveData или RxJava абонаменти без отмяна при onDestroy

В iOS основният проблем са retain циклите: два обекта държат силни референции един към друг и 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 компилация
        // чрез ContentProvider — настройка с нулев код
    }
}

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

Android Studio Profiler — вграденият инструмент за наблюдение на паметта в реално време. Позволява запис на heap dump, намиране на подозрителни обекти (Retained Size > 1 MB) и проследяване на GC root пътя до всеки обект.

За iOS използвайте Xcode Memory Graph Debugger. Той визуализира графа на обектите в паметта, показва retain цикли и позволява незабавно откриване на циклични референции. Също така е наличен Instruments > Allocations за дългосрочно наблюдение.

Стратегии за предотвратяване на изтичания

WeakReference — основният механизъм за референции, които не трябва да пречат на събирането на отпадъци. Ако GC реши да изтрие обекта, WeakReference връща null. Използва се за callback-и, listener-и и референции към 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 closure за предотвратяване на retain цикли
• Проверявайте Bitmap и големи обекти — те трябва да бъдат рециклирани или нулирани

Инструменти за профилиране на памет

Memory Profiler in Android Studio — основният инструмент за наблюдение на heap-а. Показва живи разпределения, моментни снимки на heap, брой обекти по типове. Позволява запис на dump и анализ в MAT (Memory Analyzer Tool) за намиране на подозрителни обекти.

Eclipse MAT — десктоп анализатор на heap dump. След зареждане на HPROF файл от Android Studio, MAT изгражда доминантно дърво, показва retain размера на всеки обект и предлага автоматичен анализ на подозрителни изтичания чрез Leak Suspects Report.

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

Според Google I/O 2023, приложенията, които използват LeakCanary в debug компилации, намаляват броя на crash-овете, свързани с памет, с 30-50% през първите 2 месеца след внедряване. Препоръчва се добавяне на LeakCanary във фазата на onboarding на проекта.