OutOfMemoryError در توسعه برنامه‌ها: چیست، علل و روش‌های پیشگیری

OutOfMemoryError چیست

OutOfMemoryError (OOM) — استثنایی از خانواده VirtualMachineError در Java/Kotlin است که عدم امکان تخصیص حافظه برای یک شیء جدید را نشان می‌دهد. برخلاف استثناهای checked، OOM یک Error است و نیازی به مدیریت از طریق catch ندارد — اگرچه از نظر فنی می‌توان آن را گرفت. پس از وقوع OOM، برنامه معمولاً در وضعیت ناپایداری قرار دارد و توصیه می‌شود آن را خاتمه دهید.

در اندروید، هر برنامه دارای محدودیت Heap تعیین‌شده توسط سازنده دستگاه است. برای گوشی‌های هوشمند مدرن با 6+ گیگابایت رم، محدودیت 256–512 مگابایت است، برای دستگاه‌های اقتصادی — 128–192 مگابایت. هنگامی که حجم کل همه اشیاء زنده از این محدودیت فراتر رود، ART خطای OutOfMemoryError را صادر می‌کند.

مهم است بدانیم: OOM همیشه به معنای اتمام حافظه فیزیکی دستگاه نیست. به این معنی است که برنامه محدودیت Heap تعیین‌شده توسط سیستم را تمام کرده است. سایر برنامه‌ها ممکن است حافظه آزاد داشته باشند، اما برنامه شما به دلیل ایزوله‌سازی فرآیندها در اندروید نمی‌تواند از آن استفاده کند.

علل اصلی OutOfMemoryError

پنج سناریو به طور منظم منجر به OOM در برنامه‌های موبایل می‌شوند. هر سناریو با نوع خاصی از داده یا عملیات مرتبط است.

Bitmap بدون مقیاس‌بندی

Bitmap — مصرف‌کننده اصلی حافظه در برنامه‌های اندروید. بارگذاری تصویر FullHD (1920 × 1080) در اندازه اصلی 8.3 مگابایت در فرمت ARGB_8888 اشغال می‌کند. اگر 50 تصویر از این نوع در RecyclerView وجود داشته باشد — این 415 مگابایت است که از Heap هر دستگاهی فراتر می‌رود. بارگذاری تصاویر بدون inSampleSize — OOM تضمینی در دستگاه‌های ضعیف.

از Glide یا Coil برای مقیاس‌بندی خودکار استفاده کنید. این کتابخانه‌ها تصاویر را در اندازه‌ای متناسب با View بارگذاری می‌کنند، نه رزولوشن اصلی. برای استفاده مستقیم از BitmapFactory.Options از inSampleSize استفاده کنید: آن را به عنوان توانی از دو محاسبه کنید تا اندازه نهایی از 2048 × 2048 پیکسل تجاوز نکند. همچنین برای تصاویر بدون شفافیت از 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)
}

نشت حافظه (انباشتگی)

یک نشت چند کیلوبایتی باعث OOM نمی‌شود. اما ده‌ها نشت در هر صفحه انباشته می‌شوند: هر بار که به صفحه‌ای می‌روید، یک نشت اضافه می‌شود، GC نمی‌تواند اشیاء را آزاد کند، Heap پر می‌شود. الگوی معمول: کاربر 20 بار صفحه پروفایل را باز و بسته می‌کند → Heap 200 مگابایت رشد می‌کند → برنامه با OOM سقوط می‌کند.

LeakCanary را در پروژه برای تشخیص خودکار نشت‌ها نصب کنید. این ابزار هر شیء نشت‌یافته را با stack trace دقیق نشان می‌دهد. پس از رفع همه نشت‌ها، مصرف Heap پایدار می‌شود: پس از بسته شدن صفحه، حافظه به سطح پایه بازمی‌گردد.

فایل‌های حجیم در حافظه

بارگذاری کامل فایل‌ها در byte[] — مسیر مستقیم به OOM. یک فایل JSON 50 مگابایتی هنگام تجزیه، رشته‌ای به همان اندازه به علاوه مدل DOM ایجاد می‌کند. فایل‌های ویدئویی بارگذاری‌شده در حافظه، بافرهای صوتی و مجموعه‌داده‌های بزرگ protobuf — همه می‌توانند محدودیت Heap را در یک عملیات رد کنند.

داده‌های بزرگ را با جریان پردازش کنید: InputStream با بافر 4–8 کیلوبایت، تجزیه‌کننده JSON جریانی (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 حل می‌کند.

تکه‌تکه شدن Heap

تکه‌تکه شدن — وضعیتی است که در آن حافظه آزاد به طور کلی کافی است، اما بلوک پیوسته‌ای برای شیء جدید وجود ندارد. ART در هنگام GC، Heap را فشرده می‌کند، اما همیشه با موفقیت نیست. آرایه‌های بزرگ (Bitmap، byte[]) بیشترین حساسیت را به تکه‌تکه شدن دارند.

ART در اندروید 8+ از Generational GC استفاده می‌کند که با جداسازی اشیاء جوان و پیر، تکه‌تکه شدن را کاهش می‌دهد. با این حال، از تخصیص تکه‌هایی با اندازه‌های مختلف در یک استخر خودداری کنید — سعی کنید از بافرهای از پیش تخصیص‌یافته با اندازه ثابت استفاده کنید.

محدودیت‌های Heap در اندروید

محدودیت Heap در اندروید ثابت نیست — به سازنده، مدل دستگاه و نسخه سیستم‌عامل بستگی دارد. گوگل حداقل نیازها را از طریق Compatibility Definition Document (CDD) تعیین می‌کند، اما سازندگان مقادیر واقعی را تنظیم می‌کنند.

می‌توانید محدودیت افزایش‌یافته را از طریق android:largeHeap="true" در مانیفست درخواست کنید. با احتیاط از آن استفاده کنید: افزایش 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 در بیلد دیباگ کاهش دهید یا از DDMS با فراخوانی دستی GC استفاده کنید.

مرحله 2: در زمان اوج بار (قبل از OOM) Heap Dump بگیرید. Dump را در Android Studio باز کنید: برگه Classes بر اساس Retained Size مرتب شده است. بزرگترین اشیاء — Bitmap، byte[]، String. برای هر Bitmap اندازه (width × height × 4 بایت) و مسیر بارگذاری را از طریق 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 را قبل از سقوط نشان می‌دهد. برای اندروید 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%
}