Yaddaşı yeyir və şişir — bu nədir, səbəbləri və necə qarşısını almaq olar

Yaddaş sızması və tətbiqin şişməsi nədir?

Yaddaş sızması (memory leak) — tətbiqə artıq lazım olmayan bir obyektin, kök dəstindən (GC Root) aktiv istinad olduğu üçün yaddaşda qalmağa davam etdiyi vəziyyət. Zibil toplayıcı belə bir obyekti canlı hesab edir və onu silmir.

Yaddaşın şişməsi (memory bloat) — tətbiqin cari tapşırıqları yerinə yetirmək üçün lazım olduğundan daha çox yaddaş istehlak etdiyi daha geniş bir problemdir. Səbəblər: həddindən artıq keşləmə, obyektlərin təkrarlanması, optimal olmayan məlumat strukturları və yaddaş parçalanması.

Android tətbiqləri üçün məhdud yaddaş ayrılır (adətən cihazdan və ƏS versiyasından asılı olaraq 64-512 MB). iOS məhdudiyyəti daha az sərtdir, lakin sistem limitə yaxınlaşdıqda xəbərdarlıq göndərir.

Facebook Engineering Blog məlumatlarına görə, yaddaş sızmaları mobil tətbiqlərdə crash hesabatlarının təxminən ~15%-nin səbəbidir. Androiddə buna yaddaş çatışmazlığı zamanı tez-tez GC fasilələri səbəbindən ANR da əlavə olunur.

Android və iOS-da tipik yaddaş sızması nümunələri

Activity-ə statik istinad — Android sızmalarının klassikası. Statik sahə və ya sinqlton Activity-yə istinad saxlayırsa, sinqlton canlı olduğu müddətcə finish()-dən sonra belə GC tərəfindən toplanmayacaq. Activity View hierarchy, resurslar və Context-i ehtiva edən ağır bir obyektdir.

object LeakHolder {
    var activityRef: Activity ?= null // sizma: Activity-yə statik istinad
}

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle ?= null) {
        super.onCreate(savedInstanceState)
        LeakHolder.activityRef = this // ❌ MainActivity heç vaxt GC tərəfindən toplanmayacaq
    }
}

Anonim siniflər və lambdalar — gizli şəkildə xarici sinfə istinad saxlayır. Runnable və ya Callback xarici xidmətə ötürülərsə və Activity məhv edilərsə, anonim sinif obyekti hələ də növbədə qalır və Activity-nin zibil toplanmasına getməsinə mane olur.

• Handler gecikmə ilə — Activity məhv edilibsə, lakin Handler.postDelayed hələ icra olunmayıbsa, Activity sızır
• Thread və AsyncTask — ekran döndərildikdə Activity yenidən yaradılır, köhnə Thread isə köhnə Activity-yə istinad saxlayır
• Retrofit/Callback — anonim Callback presenter və ya fragment-ə istinad saxlayır
• Müşahidəçilər (Observers) — onDestroy zamanı ləğv edilməmiş LiveData və ya RxJava abunəlikləri

iOS-da əsas problem retain cycles-dır: iki obyekt bir-birinə güclü istinadlar saxlayır və ARC heç biri üçün istinad sayını sıfırlaya bilmir. Tipik hal: self-i güclü şəkildə tutan closure və self-in closure-a istinad saxlaması.

Yaddaş sızmalarını necə aşkar etmək olar?

LeakCanary — Androiddə avtomatik sızma aşkarlanması üçün Square kitabxanası. Activity və ya Fragment məhv edildikdən sonra obyektin GC tərəfindən toplanıb-toplanmadığını yoxlayır. Əgər yoxsa — heap dump edir və sızma trace-ni göstərir.

// LeakCanary 2.x — Application vasitəsilə avto-inteqrasiya
class ExampleApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        // LeakCanary debug qurmasında avtomatik quraşdırılır
        // ContentProvider vasitəsilə — sıfır kod quraşdırması
    }
}

// Məcburi yoxlama çağırışı
AppWatcher.objectWatcher.watch(watchedObject, "leak description")

Android Studio Profiler — real vaxtda yaddaşı izləmək üçün quraşdırılmış alət. Heap dump yazmağa, şübhəli obyektləri (Retained Size > 1 MB) tapmağa və hər bir obyektə qədər GC root yolunu izləməyə imkan verir.

iOS üçün Xcode Memory Graph Debugger istifadə edin. O, yaddaşdakı obyektlərin qrafikini vizuallaşdırır, retain cycles göstərir və dairəvi istinadları dərhal aşkar etməyə imkan verir. Uzunmüddətli izləmə üçün Instruments > Allocations da mövcuddur.

Sızmaların qarşısının alınması strategiyaları

WeakReference — zibil toplanmasına mane olmamalı olan istinadlar üçün əsas mexanizm. GC obyekti silmək qərarına gələrsə, WeakReference null qaytarır. Geri çağırışlar, dinləyicilər və fon iplərindən UI komponentlərinə istinadlar üçün istifadə olunur.

Lifecycle-aware komponentləri — Android Jetpack-də (Lifecycle, LiveData, Flow, coroutines) tətbiq edilmiş memarlıq yanaşması. Abunəliklər onDestroy zamanı avtomatik ləğv edilir ki, bu da əsas sızma sinfini aradan qaldırır.

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)
            // korutina onCleared() zamanı avtomatik ləğv olunur
        }
    }
}

viewModelScope və lifecycleScope — Android-də həyat dövrü hadisəsi zamanı ləğv edilən quraşdırılmış CoroutineScope-lardır. Bu, müasir Android inkişafında ən çox yayılmış ssenari olan korutinlar vasitəsilə sızmaları aradan qaldırır.

• İstifadə etməyin Context, Activity, View və ya Fragment-ə statik istinadlar
• Ləğv edin bütün RxJava abunəliklərini disposeBag / CompositeDisposable ilə onDestroy zamanı
• İstifadə edin [weak self] / [unowned self] iOS closure-larında retain cycles qarşısını almaq üçün
• Yoxlayın Bitmap və böyük obyektləri — onlar təkrar emal edilməli və ya sıfırlanmalıdır

Yaddaş profilləmə alətləri

Memory Profiler in Android Studio — yaddaşı izləmək üçün əsas alət. Canlı ayırmaları, yaddaş şəkillərini, növlərə görə obyektlərin sayını göstərir. Dump yazmağa və şübhəli obyektləri tapmaq üçün MAT (Memory Analyzer Tool) ilə təhlil etməyə imkan verir.

Eclipse MAT — yaddaş dump-ları üçün masaüstü analizator. Android Studio-dan HPROF faylı yükləndikdən sonra MAT dominator ağacı qurur, hər bir obyektin retain ölçüsünü göstərir və Leak Suspects Report vasitəsilə şübhəli sızmaların avtomatik təhlilini təklif edir.

Xcode Memory Graph — retain cycles üçün vizual debugger. Memory Graph Debugger düyməsini kliklədikdə Xcode tətbiqi dayandırır, yaddaşdakı obyektlərin tam qrafikini qurur və retain cycles qırmızı rənglə vurğulayır.

Google I/O 2023 məlumatlarına görə, debug qurmalarında LeakCanary istifadə edən tətbiqlər tətbiqdən sonra ilk 2 ay ərzində yaddaşla bağlı crash-ların sayını 30-50% azaldır. LeakCanary-nin layihəyə onboarding mərhələsində əlavə edilməsi tövsiyə olunur.