OutOfMemoryError στην ανάπτυξη εφαρμογών: τι είναι, αιτίες και μέθοδοι πρόληψης

Τι είναι το OutOfMemoryError

OutOfMemoryError (OOM) — είναι μια εξαίρεση από την οικογένεια VirtualMachineError σε Java/Kotlin που σηματοδοτεί την αδυναμία διάθεσης μνήμης για ένα νέο αντικείμενο. Σε αντίθεση με τις checked εξαιρέσεις, το OOM είναι Error και δεν απαιτεί χειρισμό μέσω catch — αν και τεχνικά μπορεί να πιαστεί. Μετά την εμφάνιση OOM, η εφαρμογή βρίσκεται συνήθως σε ασταθή κατάσταση και συνιστάται το κλείσιμό της.

Σε Android, κάθε εφαρμογή έχει ένα όριο Heap που ορίζεται από τον κατασκευαστή της συσκευής. Για σύγχρονα smartphone με 6+ GB RAM, το όριο είναι 256–512 MB, για οικονομικές συσκευές — 128–192 MB. Όταν ο συνολικός όγκος όλων των ζώντων αντικειμένων υπερβαίνει αυτό το όριο, το ART πετάει OutOfMemoryError.

Σημαντικό να καταλάβετε: το OOM δεν σημαίνει πάντα ότι η φυσική μνήμη της συσκευής εξαντλήθηκε. Σημαίνει ότι η εφαρμογή έχει εξαντλήσει το όριο Heap που ορίζει το σύστημα. Άλλες εφαρμογές μπορεί να έχουν διαθέσιμη μνήμη, αλλά η εφαρμογή σας δεν μπορεί να τη χρησιμοποιήσει λόγω της απομόνωσης διεργασιών σε Android.

Κύριες αιτίες OutOfMemoryError

Πέντε σενάρια οδηγούν τακτικά σε OOM σε κινητές εφαρμογές. Κάθε σενάριο σχετίζεται με έναν συγκεκριμένο τύπο δεδομένων ή λειτουργία.

Bitmap χωρίς κλίμακα

Bitmap — ο κύριος καταναλωτής μνήμης σε εφαρμογές Android. Η φόρτωση μιας εικόνας FullHD (1920 × 1080) σε αρχικό μέγεθος καταλαμβάνει 8.3 MB σε μορφή ARGB_8888. Εάν υπάρχουν 50 τέτοιες εικόνες σε ένα RecyclerView — αυτό είναι 415 MB, που υπερβαίνει το Heap οποιασδήποτε συσκευής. Η φόρτωση εικόνων χωρίς inSampleSize — εγγυημένο OOM σε αδύναμες συσκευές.

Χρησιμοποιήστε Glide ή Coil για αυτόματη κλίμακα. Αυτές οι βιβλιοθήκες φορτώνουν εικόνες σε μέγεθος που ταιριάζει με το View, όχι στην αρχική ανάλυση. Για άμεση χρήση BitmapFactory.Options, εφαρμόστε inSampleSize: υπολογίστε το ως δύναμη του δύο έτσι ώστε το τελικό μέγεθος να μην υπερβαίνει τα 2048 × 2048 pixel. Επιπλέον, χρησιμοποιήστε RGB_565 αντί για ARGB_8888 για εικόνες χωρίς διαφάνεια — αυτό μειώνει την κατανάλωση μνήμης κατά το ήμισυ.

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)
}

Διαρροές μνήμης (συσσώρευση)

Μία διαρροή λίγων KB δεν θα προκαλέσει OOM. Αλλά δεκάδες διαρροές σε κάθε οθόνη συσσωρεύονται: κάθε μετάβαση σε μια οθόνη προσθέτει μια διαρροή, το GC δεν μπορεί να απελευθερώσει τα αντικείμενα, το Heap γεμίζει. Τυπικό μοτίβο: ο χρήστης ανοίγει και κλείνει την οθόνη προφίλ 20 φορές → το Heap αυξάνεται κατά 200 MB → η εφαρμογή καταρρέει με OOM.

Εγκαταστήστε το LeakCanary στο έργο για αυτόματη ανίχνευση διαρροών. Θα εμφανίσει κάθε αντικείμενο που διαρρέει με ακριβές stack trace. Μετά την επισκευή όλων των διαρροών, η κατανάλωση Heap γίνεται σταθερή: μετά το κλείσιμο της οθόνης, η μνήμη επιστρέφει στο βασικό επίπεδο.

Μεγάλα αρχεία στη μνήμη

Η φόρτωση αρχείων στο σύνολό τους σε byte[] — ο άμεσος δρόμος προς OOM. Ένα JSON αρχείο 50 MB κατά την ανάλυση θα δημιουργήσει ένα string ίδιου μεγέθους συν το μοντέλο DOM. Τα αρχεία βίντεο που φορτώνονται στη μνήμη, οι προφυλακτικές audio και τα μεγάλα σύνολα δεδομένων protobuf — όλα μπορούν να υπερβούν το όριο Heap σε μία μόνο λειτουργία.

Επεξεργαστείτε μεγάλα δεδομένα με ροή: InputStream με buffer 4–8 KB, streaming JSON parser (Jackson ή Gson με JsonReader), MediaCodec για βίντεο. Ποτέ μην καλείτε File.readBytes() σε αρχεία μεγαλύτερα από 10% του διαθέσιμου Heap.

Δημιουργία πολλών αντικειμένων σε βρόχο

Η εντατική δημιουργία αντικειμένων σε βρόχο χωρίς ενδιάμεσο GC μπορεί να οδηγήσει σε OOM, ιδιαίτερα σε συσκευές με μικρό Heap. Παράδειγμα: η δημιουργία 100.000 αντικειμένων σε έναν βρόχο for που δεν χωρούν στο Heap πριν το GC προλάβει να τα συλλέξει. Αυτό συμβαίνει συχνότερα σε παιχνίδια και γραφικούς επεξεργαστές.

Χρησιμοποιήστε Object Pool για αντικείμενα που δημιουργούνται και καταστρέφονται μαζικά. Για αριθμητικά δεδομένα, χρησιμοποιήστε πρωτόγονους τύπους (FloatArray αντί List<Float>). RecyclerView με ViewHolder Pool λύνει αυτό το πρόβλημα για τα UI components.

Κατακερματισμός Heap

Κατακερματισμός — κατάσταση κατά την οποία υπάρχει συνολικά αρκετή ελεύθερη μνήμη, αλλά δεν υπάρχει συνεχές μπλοκ για ένα νέο αντικείμενο. Το ART συμπυκνώνει το Heap κατά τη διάρκεια GC, αλλά όχι πάντα με επιτυχία. Οι μεγάλοι πίνακες (Bitmap, byte[]) είναι οι πιο ευαίσθητοι σε κατακερματισμό.

Το ART σε Android 8+ χρησιμοποιεί Generational GC, που μειώνει τον κατακερματισμό διαχωρίζοντας τα νέα και παλιά αντικείμενα. Παρόλα αυτά, αποφύγετε τη διάθεση τμημάτων διαφορετικού μεγέθους σε ένα pool — προσπαθήστε να χρησιμοποιείτε προ-διατεθειμένα buffer σταθερού μεγέθους.

Όρια Heap σε Android

Το όριο Heap σε Android δεν είναι σταθερό — εξαρτάται από τον κατασκευαστή, το μοντέλο της συσκευής και την έκδοση OS. Η Google καθορίζει ελάχιστες απαιτήσεις μέσω Compatibility Definition Document (CDD), αλλά οι κατασκευαστές ορίζουν τις πραγματικές τιμές.

Μπορείτε να ζητήσετε αυξημένο όριο μέσω android:largeHeap="true" στο manifest. Χρησιμοποιήστε το με προσοχή: η αύξηση Heap δεν λύνει το πρόβλημα των διαρροών και μπορεί να χειροτερέψει την εμπειρία χρήστη αν το σύστημα αναγκαστεί να τερματίσει άλλες εφαρμογές για να ελευθερώσει μνήμη. Για Wear OS, το όριο Heap είναι ελάχιστο — μόνο 32–64 MB, εδώ το largeHeap δεν είναι διαθέσιμο και η εξοικονόμηση μνήμης είναι διπλά κρίσιμη.

Διάγνωση OutOfMemoryError

Η διάγνωση OOM απαιτεί ανάλυση Heap Dump και κατανόηση ποια αντικείμενα καταναλώνουν μνήμη. Το Android Studio παρέχει όλα τα απαραίτητα εργαλεία.

Βήμα 1: Πιάστε τη στιγμή OOM. Στο Android Memory Profiler, πατήστε Record memory allocations και εκτελέστε το σενάριο που προκαλεί κατάρρευση. Το profiler θα δείξει άλμα διαθέσεων πριν το OOM. Αν το OOM δεν αναπαράγεται, μειώστε το Heap μέσω android:smallHeap σε debug έκδοση ή χρησιμοποιήστε DDMS με χειροκίνητη κλήση GC.

Βήμα 2: Λάβετε Heap Dump τη στιγμή της αιχμής φόρτωσης (πριν το OOM). Ανοίξτε το Dump στο Android Studio: η καρτέλα Classes είναι ταξινομημένη κατά Retained Size. Τα μεγαλύτερα αντικείμενα — Bitmap, byte[], String. Για κάθε Bitmap, ελέγξτε το μέγεθος (width × height × 4 bytes) και τη διαδρομή φόρτωσης μέσω Stack Trace.

Βήμα 3: Αναλύστε τον αριθμό των επαναλαμβανόμενων αντικειμένων. Αν βλέπετε 200 ίδια Fragment ή Activity — αυτό είναι διαρροή. Αν 500 Bitmap ίδιου μεγέθους — πρόβλημα με την προσωρινή μνήμη εικόνων. Το MAT (Memory Analyzer Tool) παρέχει βαθύτερη ανάλυση με Dominator Tree, δείχνοντας ποια αντικείμενα κρατούν 80% του Heap.

// Εντολή για Heap Dump μέσω adb
adb shell am dumpheap com.example.app /data/local/tmp/dump.hprof
adb pull /data/local/tmp/dump.hprof.

Στρατηγικές πρόληψης OOM

Μια ολοκληρωμένη στρατηγική πρόληψης OOM περιλαμβάνει πέντε επίπεδα προστασίας: από αρχιτεκτονικές λύσεις έως παρακολούθηση σε παραγωγή.

Αρχιτεκτονικές λύσεις

ViewModel + Repository μοτίβο διαχωρίζει τα δεδομένα από το UI και αποτρέπει την κατάσχεση View κατά την περιστροφή οθόνης. Το ViewModel επιζεί περισσότερο από το Activity, τα δεδομένα του δεν χάνονται και το View μπορεί να αναδημιουργηθεί χωρίς διπλασιασμό δεδομένων στη μνήμη. Χρησιμοποιήστε StateFlow αντί LiveData για ρητή διαχείριση καταστάσεων.

Διαχείριση Bitmap και εικόνων

Glide — υποχρεωτική βιβλιοθήκη για εργασία με εικόνες. Κλιμακώνει αυτόματα, προσωρινά αποθηκεύει (δίσκος + μνήμη) και ανακυκλώνει Bitmap. Διαμορφώστε diskCacheStrategy και skipMemoryCache για μεγάλες λίστες. Για κινούμενες εικόνες, χρησιμοποιήστε Glide με GIF/WebP — καταλαμβάνουν λιγότερη μνήμη από μια ακολουθία Bitmap.

Παρακολούθηση σε παραγωγή

Firebase Performance Monitoring παρακολουθεί την κατανάλωση μνήμης σε πραγματικό χρόνο. Ορίστε ειδοποίηση όταν το Heap είναι πάνω από 80% του ορίου — αυτό είναι σήμα για έλεγχο. Το Crashlytics συλλέγει το OOM ως εξαίρεση και δείχνει την τελευταία γνωστή κατάσταση Heap πριν την κατάρρευση. Για Android 11+, χρησιμοποιήστε ApplicationExitInfo για ανίχνευση τερματισμού OOM.

Δοκιμή σε αδύναμες συσκευές

Υποχρεωτικά δοκιμάστε την εφαρμογή σε συσκευές με ελάχιστο Heap (128–192 MB). Ένας εξομοιωτής με μικρή οθόνη και μικρό Heap προσομοιώνει μια οικονομική συσκευή. Αν η εφαρμογή λειτουργεί σε τέτοια συσκευή, στις κορυφαίες συσκευές δεν θα υπάρχουν προβλήματα OOM. Χρησιμοποιήστε Firebase Test Lab με πραγματικές συσκευές από διαφορετικές κατηγορίες τιμής.

// Έλεγχος διαθέσιμου Heap πριν από βαριά λειτουργία
fun canAllocate(requiredBytes: Long): Boolean {
    val runtime = Runtime.getRuntime()
    val free = runtime.freeMemory()
    return free > requiredBytes * 2 // απόθεμα 50%
}