تسريب الذاكرة في تطبيقات الويب: تشخيص التراكم الذي لا يظهر في أول اختبار

قد تعمل صفحة الويب بسرعة في أول خمس دقائق ثم تتباطأ بعد ساعات من الاستخدام. ليس كل ارتفاع في الذاكرة تسريبًا؛ فقد يحتفظ المحرك بذاكرة قابلة لإعادة الاستخدام. التشخيص يتطلب مقارنة الذاكرة بعد دورات عمل متكررة، لا لقطة واحدة من مدير المهام.

ابنِ سيناريو قابلًا للتكرار

حدد إجراءً يشتبه أنه يراكم الموارد: فتح نافذة، إغلاقها، الانتقال بين صفحات، أو استقبال رسائل. كرر الدورة عشرات المرات في بيئة ثابتة وسجل توقيتات الأداء والذاكرة. قارن بعد فترات خمول تسمح بجمع القمامة بدل الحكم من أعلى قيمة لحظية.

اقرأ Heap Snapshots بحذر

قارن لقطات الذاكرة قبل السيناريو وبعده وابحث عن كائنات كان ينبغي تحريرها وما زالت قابلة للوصول. راقب سلاسل المراجع التي تبقيها حيّة، مثل مستمع حدث أو مؤقت أو متغير عام. زيادة حجم Heap وحدها ليست دليلًا قاطعًا دون تفسير سبب بقاء الكائنات.

لا تنس موارد خارج JavaScript

قد يأتي التسريب من صور كبيرة أو عناصر Canvas أو WebGL أو تدفقات وسائط أو مخازن أصلية في إضافات المتصفح. افحص عدد العناصر والعُقد المنفصلة ومقابض الملفات والاتصالات المفتوحة. أغلق الاشتراكات وحرر الموارد في دورة حياة المكوّن عند إزالته.

افصل أثر الكاش عن التسريب

التخزين المؤقت قد يرفع الاستهلاك ثم يستقر عند حد معروف، بينما التسريب يواصل الارتفاع مع تكرار العملية نفسها. جرّب إعادة استخدام المكونات بدل إنشاء نسخ جديدة، وقارن ذاكرة التبويب وذاكرة العملية ككل. لا تجعل استدعاء جمع القمامة يدويًا هو الحل الإنتاجي.

حوّل الإصلاح إلى اختبار انحدار

ضع اختبارًا طويلًا يكرر السيناريو ويقيس اتجاه الذاكرة وزمن الاستجابة، مع حدود تسمح بتذبذب الأجهزة. تأكد من عدم تعطيل ميزة ضرورية أثناء التنظيف، مثل استقبال الإشعارات. النتيجة المطلوبة استقرار الاستهلاك بعد الدورات المتكررة لا رقم ذاكرة واحد.