Tətbiq inkişafında OutOfMemoryError: bu nədir, səbəbləri və qarşısının alınması üsulları

OutOfMemoryError nədir

OutOfMemoryError (OOM) — Java/Kotlin-də VirtualMachineError ailəsindən olan və yeni obyekt üçün yaddaş ayırmanın mümkünsüzlüyünü bildirən istisnadır. Yoxlanılan istisnalardan fərqli olaraq, OOM Error-dır və catch vasitəsilə işlənmə tələb etmir — texniki olaraq tutmaq mümkün olsa da. OOM baş verdikdən sonra tətbiq adətən qeyri-sabit vəziyyətdə olur və onu bağlamaq tövsiyə olunur.

Android-də hər tətbiqin istehsalçı tərəfindən təyin edilmiş Heap limiti var. 6+ GB RAM-lı müasir smartfonlar üçün limit 256–512 MB, büdcə cihazları üçün — 128–192 MB təşkil edir. Bütün canlı obyektlərin ümumi həcmi bu limiti keçdikdə, ART OutOfMemoryError atır.

Vacibdir anlamaq: OOM həmişə cihazda fiziki yaddaşın bitdiyi demək deyil. Bu, tətbiqin sistem tərəfindən təyin edilmiş Heap limitini tükətdiyi deməkdir. Digər tətbiqlərin boş yaddaşı ola bilər, lakin Android-də proses izolyasiyası səbəbindən sizin tətbiqiniz ondan istifadə edə bilməz.

OutOfMemoryError-un əsas səbəbləri

Beş ssenari mobil tətbiqlərdə müntəzəm olaraq OOM-a gətirib çıxarır. Hər ssenari müəyyən məlumat növü və ya əməliyyatla bağlıdır.

Bitmap miqyaslanmadan

Bitmap — Android tətbiqlərində yaddaşın əsas istehlakçısıdır. FullHD şəklin (1920 × 1080) orijinal ölçüdə yüklənməsi ARGB_8888 formatında 8.3 MB yer tutur. RecyclerView-də 50 belə şəkil varsa — bu 415 MB-dır və istənilən cihazın Heap-ni aşır. Şəkillərin inSampleSize olmadan yüklənməsi — zəif cihazlarda zəmanətli OOM-dur.

Avtomatik miqyaslama üçün Glide və ya Coil istifadə edin. Bu kitabxanalar şəkilləri orijinal rezolyusiyaya deyil, View-ə uyğun ölçüdə yükləyir. Birbaşa BitmapFactory.Options istifadəsi üçün inSampleSize tətbiq edin: onu ikinin qüvvəti olaraq hesablayın ki, son ölçü 2048 × 2048 pikseli keçməsin. Şəffaflığı olmayan şəkillər üçün ARGB_8888 əvəzinə RGB_565 istifadə edin — bu yaddaş istehlakını iki dəfə azaldır.

fun loadScaledBitmap(path: String, reqWidth: Int): Bitmap? {
    val opts = BitmapFactory.Options().apply {
        inJustDecodeBounds = true
    }
    BitmapFactory.decodeFile(path, opts)
    opts.inSampleSize = calculateSampleSize(opts.outWidth, reqWidth)
    opts.inJustDecodeBounds = false
    return BitmapFactory.decodeFile(path, opts)
}

Yaddaş sızmaları (yığılma)

Bir neçə KB-lıq sızma OOM-a səbəb olmaz. Lakin hər ekranda onlarla sızma yığılır: hər ekrana keçid sızma əlavə edir, GC obyektləri boşalda bilmir, Heap dolur. Tipik nümunə: istifadəçi profil ekranını 20 dəfə açıb bağlayır → Heap 200 MB artır → tətbiq OOM ilə çökür.

Avtomatik sızma aşkarlanması üçün layihəyə LeakCanary quraşdırın. O, dəqiq stack trace ilə hər sızan obyekti göstərəcək. Bütün sızmalar düzəldildikdən sonra Heap istehlakı sabit olacaq: ekran bağlandıqdan sonra yaddaş baza səviyyəsinə qayıdır.

Böyük fayllar yaddaşda

Faylların tamamilə byte[]-ə yüklənməsi — OOM-a birbaşa yoldur. 50 MB-lıq JSON faylı parsings zamanı eyni ölçüdə string üstəgəl DOM modeli yaradacaq. Yaddaşa yüklənmiş video fayllar, audio buferlər və böyük protobuf məlumat dəstləri — hamısı bir əməliyyatda Heap limitini keçə bilər.

Böyük məlumatları axınlarla emal edin: 4–8 KB buferli InputStream, Streaming JSON-parser (Jackson və ya Gson JsonReader ilə), video üçün MediaCodec. Heç vaxt mövcud Heap-in 10%-dən böyük fayllarda File.readBytes() çağırmayın.

Dövrədə çoxlu obyekt yaratma

Dövrədə intensiv obyekt yaratma, aralıq GC olmadan, xüsusilə kiçik Heap-li cihazlarda OOM-a gətirib çıxara bilər. Nümunə: for dövrəsində GC-nin toplamağa vaxtı olmayan 100 000 obyektin yaradılması. Bu, oyunlarda və qrafik redaktorlarda daha çox rast gəlinir.

Kütləvi şəkildə yaradılıb məhv edilən obyektlər üçün Object Pool istifadə edin. Rəqəmsal məlumatlar üçün primitiv tiplərdən istifadə edin (List<Float> əvəzinə FloatArray). ViewHolder Pool ilə RecyclerView bu problemi UI komponentləri üçün həll edir.

Heap fragmentasiyası

Fragmentasiya — ümumi boş yaddaşın kifayət etdiyi, lakin yeni obyekt üçün fasiləsiz blokun olmadığı haldır. ART GC zamanı Heap-i kompaktlaşdırır, lakin həmişə uğurla deyil. Böyük massivlər (Bitmap, byte[]) fragmentasiyaya ən həssas olanlardır.

Android 8+-da ART gənc və yaşlı obyektləri ayırmaqla fragmentasiyanı azaldan Generational GC istifadə edir. Buna baxmayaraq, bir hovuzda müxtəlif ölçülü fraqmentlər ayırmaqdan çəkinin — sabit ölçülü pre-allocated buferlərdən istifadə etməyə çalışın.

Android-də Heap limitləri

Heap limiti Android-də sabit deyil — istehsalçıdan, cihaz modelindən və OS versiyasından asılıdır. Google Compatibility Definition Document (CDD) vasitəsilə minimum tələbləri müəyyən edir, lakin istehsalçılar faktiki dəyərləri təyin edir.

Artırılmış limiti manifestdə android:largeHeap="true" vasitəsilə tələb etmək olar. Ehtiyatla istifadə edin: Heap-i artırmaq sızma problemini həll etmir və sistem digər tətbiqləri öldürməyə məcbur olarsa, istifadəçi təcrübəsini pisləşdirə bilər. Wear OS üçün Heap limiti minimaldır — cəmi 32–64 MB, burada largeHeap mövcud deyil və yaddaş qənaəti ikiqat vacibdir.

OutOfMemoryError diaqnostikası

OOM diaqnostikası Heap Dump analizi və hansı obyektlərin yaddaş istehlak etdiyini anlamağı tələb edir. Android Studio bütün lazımi alətləri təmin edir.

Addım 1: OOM anını yaxalayın. Android Memory Profiler-də Record memory allocations düyməsini basın və çökməyə səbəb olan ssenarini icra edin. Profiler OOM-dan əvvəl alokasiya sıçrayışını göstərəcək. OOM təkrarlanmırsa, debug-build-də android:smallHeap vasitəsilə Heap-i azaldın və ya əl ilə GC çağırışı ilə DDMS istifadə edin.

Addım 2: Pik yük anında (OOM-dan əvvəl) Heap Dump çıxarın. Dump-ı Android Studio-da açın: Classes sekmesi Retained Size-a görə sıralanmışdır. Ən böyük obyektlər — Bitmap, byte[], String. Hər Bitmap üçün ölçüyü (width × height × 4 bayt) və Stack Trace vasitəsilə yükləmə yolunu yoxlayın.

Addım 3: Təkrarlanan obyektlərin sayını analiz edin. 200 eyni Fragment və ya Activity görürsünüzsə — bu sızmadır. Eyni ölçülü 500 Bitmap varsa — şəkil keşləmə problemi. MAT (Memory Analyzer Tool) Heap-in 80%-ni saxlayan obyektləri göstərən Dominator Tree ilə daha dərin analiz təmin edir.

// Heap Dump üçün əmr adb vasitəsilə
adb shell am dumpheap com.example.app /data/local/tmp/dump.hprof
adb pull /data/local/tmp/dump.hprof.

OOM-un qarşısının alınması strategiyaları

Kompleks OOM qarşısının alınması strategiyası beş qoruma səviyyəsini əhatə edir: memarlıq həllərindən prodakşn monitorinqinə qədər.

Memarlıq həlləri

ViewModel + Repository nümunəsi məlumatları UI-dən ayırır və ekran döndərmə zamanı View-in saxlanmasının qarşısını alır. ViewModel Activity-dən uzun yaşayır, onun məlumatları itmir və View yaddaşda məlumatların təkrarlanmadan yenidən yaradıla bilər. Vəziyyətləri idarə etmək üçün LiveData əvəzinə StateFlow istifadə edin.

Bitmap və şəkillərin idarə edilməsi

Glide — şəkillərlə iş üçün məcburi kitabxanadır. Avtomatik miqyaslayır, keşləyir (disk + yaddaş) və Bitmap-i recycl edir. Böyük siyahılar üçün diskCacheStrategy və skipMemoryCache konfiqurasiya edin. Animasiyalı şəkillər üçün Glide-i GIF/WebP ilə istifadə edin — onlar Bitmap ardıcıllığından daha az yaddaş tutur.

Prodakşn monitorinqi

Firebase Performance Monitoring yaddaş istehlakını real vaxtda izləyir. Heap-in limitin 80%-dən çox olmasına alert qoyun — bu yoxlama siqnalıdır. Crashlytics OOM-u istisna kimi toplayır və çökmədən əvvəl son Heap vəziyyətini göstərir. Android 11+ üçün OOM-qapanmalarını aşkarlamaq üçün ApplicationExitInfo istifadə edin.

Zəif cihazlarda sınaq

Məcburi olaraq tətbiqi minimal Heap (128–192 MB) olan cihazlarda sınaqdan keçirin. Kiçik ekranlı və kiçik Heap-li emulator büdcə cihazını simulyasiya edir. Tətbiq belə bir cihazda işləyirsə, flaqmanlarda OOM problemi olmayacaq. Müxtəlif qiymət kateqoriyalarından real cihazlarla Firebase Test Lab istifadə edin.

// Ağır əməliyyatdan əvvəl mövcud Heap-in yoxlanılması
fun canAllocate(requiredBytes: Long): Boolean {
    val runtime = Runtime.getRuntime()
    val free = runtime.freeMemory()
    return free > requiredBytes * 2 // 50% ehtiyat
}