تسرب الذاكرة: ما هو، السيناريوهات النموذجية والتشخيص

ما هو تسرب الذاكرة في التطبيقات المحمولة?

تسرب الذاكرة — حالة لا يتم فيها إرجاع الذاكرة المخصصة إلى النظام بعد أن لم يعد الكائن مطلوبًا من قبل البرنامج. يعتبر جامع القمامة أن هذا الكائن حي لأن هناك سلسلة مراجع نشطة من GC Root تشير إليه.

في Java/Kotlin، يعمل جامع القمامة تلقائيًا، لكنه لا يستطيع تحديد أن الكائن غير ضروري منطقيًا إذا كان هناك مرجع تقني إليه. يجب على المطور قطع الاتصالات غير الضرورية بشكل صريح. في Swift/Objective-C، يقوم ARC تلقائيًا بعد المراجع، لكن دورات الاحتفاظ تمنع إنقاص العداد.

الخطر الرئيسي للتسربات هو التأثير التراكمي. كل تسرب يستهلك كمية صغيرة من الذاكرة، ولكن مع الانتقالات المتكررة بين الشاشات (تدوير الشاشة، فتح/إغلاق Activities) تتراكم التسربات حتى استنفاد حد الكومة.

كيف يختلف التسرب عن الانتفاخ?

التسرب — الكائن غير متاح للكود ولكن لم يتم إزالته بواسطة GC. الانتفاخ — الكائن مطلوب منطقيًا ولكنه مخزن بكمية زائدة. مثال على الانتفاخ: ذاكرة تخزين مؤقت للصور بحجم 100 MB مع مجموعة عمل بحجم 30 MB. كلتا المشكلتين تؤديان إلى OOM، لكن الأسباب وطرق العلاج مختلفة.

كيف يعمل جامع القمامة ولماذا تحدث التسربات?

ART (Android Runtime) يستخدم جمع القمامة بالأجيال مع الضغط المتزامن. تنقسم الذاكرة إلى جيل الشباب (Young)، الجيل القديم (Old) والكائنات الكبيرة (Large). الكائنات التي تنجو من عدة دورات GC تنتقل إلى الجيل القديم، حيث يحدث الجمع بشكل أقل — وهذا يسرع الدورات العادية.

يبدأ GC عندما تصل الكومة إلى حد إشغال معين (عادة 75-85%). أثناء GC، يتم إيقاف جميع سلاسل التطبيق (STW — Stop The World). كلما زادت الكائنات الحية، زادت فترة التوقف. تزيد التسربات من عدد الكائنات الحية، مما يطيل فترات توقف GC.

يحدد المجمع الكائنات الحية عن طريق اجتياز الرسم البياني من GC Roots: الحقول الثابتة ومتغيرات المكدس للسلاسل النشطة ومراجع JNI. أي كائن يمكن الوصول إليه عبر المراجع من هذه الجذور يعتبر حيًا — حتى إذا كان المطور يعلم أنه لم يعد مطلوبًا.

// مثال: مجموعة ثابتة كـ GC Root — تسرب دائم
object GlobalHolder {
    val listeners = mutableListOf<WeakReference<Any>>()
}

class LeakingFragment : Fragment() {
    override fun onCreate(savedInstanceState: Bundle ?= null) {
        super.onCreate(savedInstanceState)
        GlobalHolder.listeners.add(WeakReference(this))
        // WeakReference لا يمنع GC — سلوك صحيح
    }
}

WeakReference يحل المشكلة: يتجاهل GC المراجع الضعيفة عند تحديد الكائنات الحية. إذا بقيت مراجع ضعيفة فقط لكائن، فسيتم جمعه في أقرب دورة GC.

السيناريوهات النموذجية للتسربات في Android و iOS

Activity Context — السيناريو الأكثر انتشارًا للتسربات في Android. إذا كان المفرد أو الحقل الثابت أو الخدمة طويلة العمر تخزن مرجعًا إلى Activity Context، فلا يمكن جمع كل Activity مع جميع Views بواسطة GC. الحل: استخدم Application Context للكائنات طويلة العمر.

Handler والرسائل المرسلة — Handler.postDelayed(runnable, delay) يضع رسالة في قائمة Main Looper. إذا تم تدمير Activity قبل انتهاء التأخير، تظل الرسالة في القائمة وتحتفظ بمرجع عبر Runnable → فئة مجهولة → فئة خارجية (Activity).

class SafeActivity : AppCompatActivity() {
    private val mainHandler = Handler(Looper.getMainLooper())
    private val callback = Runnable { /* update UI */ }

    override fun onResume() {
        super.onResume()
        mainHandler.postDelayed(callback, 5000)
    }

    override fun onPause() {
        mainHandler.removeCallbacks(callback) // إلزامي: مسح قائمة الانتظار
        super.onPause()
    }
}

الفئات الداخلية — الفئة الداخلية غير الثابتة لها مرجع ضمني لمثيل الفئة الخارجية. إذا كانت الفئة الخارجية هي Activity وتم تمرير الفئة الداخلية إلى مكان خارجي (على سبيل المثال، إلى RecyclerView.Adapter)، فلا يمكن جمع Activity.

• TimerTask و ScheduledExecutorService — المهام المجدولة قبل تدمير Activity
• BroadcastReceiver — غير المسجل في onPause/onDestroy يستمر في الاحتفاظ بـ Context
• ViewModel مع مرجع إلى View — ViewModel يعيش أطول من Activity، المرجع إلى View يؤدي إلى تسرب
• Retrofit Call — إذا لم يتم إلغاء Call، يصل الرد إلى Fragment مدمر

أدوات تشخيص تسرب الذاكرة

Android Studio Memory Profiler — أداة مدمجة لمراقبة الكومة في الوقت الفعلي. تعرض رسمًا بيانيًا للذاكرة المستخدمة وعدد التخصيصات والكائنات حسب النوع. تسمح بتسجيل heap dump وتصديره بتنسيق HPROF للتحليل في MAT.

Eclipse MAT (Memory Analyzer Tool) — محلل سطح مكتب لـ heap dump. يقوم تلقائيًا ببناء تقارير Leak Suspects التي تبرز الكائنات ذات الحجم المحتفظ به الأكبر وتقترح سلسلة GC Root المحتملة لكل كائن مشبوه.

Xcode Memory Graph Debugger — لنظام iOS. يوقف التطبيق ويصور الرسم البياني للكائنات. يتم تمييز دورات الاحتفاظ باللون الأحمر؛ يمكن النقر على أي كائن لرؤية عدد مرات الاحتفاظ به ومراجعه.

وفقًا لـ Uber Engineering Blog، يؤدي دمج التنميط التلقائي للذاكرة (LeakCanary + تحليل heap dump) في خط أنابيب CI/CD إلى تقليل الحوادث المرتبطة بالذاكرة في الإنتاج بنسبة 60% خلال 3 أشهر.

طرق إزالة التسربات

استبدال Context — إذا كان الكائن يعيش أطول من Activity، استخدم applicationContext. يجب أن تتلقى جميع الكائنات طويلة العمر (المفردات، المستودعات، مساعدي قواعد البيانات) Application Context، وليس Activity Context. الاستثناء: مكونات واجهة المستخدم التي تحتاج إلى الوصول إلى السمة أو الموارد الخاصة بـ Activity.

المكونات الواعية لدورة الحياة — استخدام LifecycleObserver أو DefaultLifecycleObserver أو الامتدادات التفاعلية يلغي الاشتراكات تلقائيًا عند onDestroy. يوفر Android Jetpack lifecycleScope و viewModelScope، اللذين يتم تنظيفهما بواسطة حدث دورة الحياة المقابل.

فئة داخلية ثابتة — إذا كانت الفئة الداخلية لا تحتاج إلى الوصول إلى حقول الفئة الخارجية، اجعلها static. الفئة الداخلية الثابتة ليس لها مرجع ضمني للفئة الخارجية. إذا كان الوصول مطلوبًا، استخدم WeakReference للمرجع الصريح.

class MyActivity : AppCompatActivity() {

    // ❌ فئة داخلية غير ثابتة — مرجع ضمني إلى MyActivity
    inner class BadListener : SomeListener {
        override fun onEvent() { /*...*/ }
    }

    // ✅ فئة داخلية ثابتة — بدون مرجع ضمني
    class GoodListener(private val activityRef: WeakReference<MyActivity>) : SomeListener {
        override fun onEvent() { /*...*/ }
    }
}

في iOS، استخدم قوائم الالتقاط: [weak self] في الإغلاقات التي قد تعيش أطول من منشئها. للمفوضين، استخدم المراجع الضعيفة (weak var delegate). للإغلاقات المضمون استدعاؤها فقط أثناء عمر self، يمكن استخدام [unowned self]، ولكن بحذر — الوصول إلى كائن تم تحريره سيؤدي إلى تعطل.