ارتفاع RAM أثناء استخدام المتصفح ليس دليلًا على Memory Leak. Chromium يحتفظ ب ـcaches، V8 يؤجل garbage collection، والصفحات نفسها قد تستخدم ذاكرة حسب نشاطها. التسرب يظهر عندما ينمو الاستهلاك مع تكرار workload ولا يعود إلى نطاق مستقر بعد فترات هدوء و GC طبيعي. جلسة ثماني ساعات مفيدة لأنها تكشف slopes صغيرة لا تظهر في اختبار عشر دقائق.
صمم Workload متكررًا وثابتًا
اختر دورة تمثل الاستخدام: فتح صفحات، تبديل تبويبات، تشغيل Automation، إغلاقها، ثم idle. كرر نفس الدورة بدل تصفح عشوائي. سجل رقم الدورة حتى تربط الذاكرة بما حدث. إذا تغير workload خلال الاختبار فلن تعرف هل الارتفاع تسرب أم نشاط إضافي.
قس Process-level و Total Memory
سجل RSS/Private Working Set للعملية الرئيسية وال renderers و GPU/utility، بالإضافة إلى إجمالي التطبيق. Process واحد يتسرب قد يختفي داخل رقم إجمالي كبير. احتفظ ب ـPID ودور العملية و Profile ID إن أمكن، مع الحذر من إعادة إنشاء renderer ب PID جديد.
أضف فترات Quiescence
كل 30 أو 60 دقيقة، توقف عن إنشاء عمل جديد واترك التطبيق في idle مدة قصيرة. راقب هل الذاكرة تنخفض أو تستقر. لا تجبر GC في كل run لأن ذلك لا يمثل المستخدم، لكن في build تشخيصية يمكن استخدام GC forced لمقارنة retained objects ومعرفة هل الذاكرة قابلة للتحرير.
خطوات عملية
- شغل workload عدة دورات.
- ادخل فترة idle.
- سجل memory قبل وبعد.
- كرر النمط طوال الاختبار.
راقب Heap و Native Memory كلًا على حدة
V8 heap قد تكون مستقرة بينما native buffers أو images أو WebContents resources تتزايد. استخدم heap snapshots لعينات محدودة و OS/process metrics لل native. لا تأخذ snapshot كل دقيقة لأنها تغير الحمل وتستهلك مساحة.
قائمة مراجعة
- JS heap trend.
- RSS trend.
- عدد WebContents.
- عدد event listeners أو handles إذا توفر.
احسب Slope لا الفرق بين البداية والنهاية فقط
Fit بسيط أو حتى فرق متوسط كل ساعة يوضح معدل النمو. إذا ارتفعت الذاكرة أول ساعة ثم استقرت، قد يكون warm cache. إذا تزيد 50MB كل ساعة مع نفس workload فالإشارة أقوى. قارن أكثر من run لتجنب حادث عابر.
اختبر Release/Close Paths
ركز على الأشياء التي تُنشأ وتُغلق: tabs، Fast View، DevTools، extensions، downloads. بعد إغلاقها تحقق أن references و listeners تُزال. Leak شائعة تأتي من map يحتفظ ب ـWebContents بعد destroy أو timer لا يُلغى.
ضع معيار فشل قابلًا للتفسير
بدل حد RAM ثابت لكل الأجهزة، عرّف slope قصوى بعد warm-up ونسبة memory التي يجب أن تستقر بعد idle. إذا فشل الاختبار، احفظ الفترة و process الأكثر نموًا و event الذي سبقه لتسهيل reproduction.
ابنِ Baseline ثم قارن
لتطبيق «قياس Memory Leak في جلسة متصفح تمتد 8 ساعات» بصورة عملية، ثبت جهاز الاختبار وعدد البروفايلات والنسخة والروابط المستخدمة، ثم خذ baseline قبل أي تغيير. سجّل المتوسط وأيضًا أسوأ الحالات الملحوظة مثل p95 عند توفر عدد كافٍ من العينات. أعد السيناريو بعد تنظيف ما يجب تنظيفه فقط، لأن مسح كل cache قد يصنع اختبارًا غير واقعي. إذا ظهر regression، ضيق النطاق بتغيير متغير واحد: نسخة Electron، إضافة، proxy، أو feature flag. بهذه الطريقة يصبح الأداء أو الاستقرار رقمًا يمكن تفسيره لا مجرد إحساس بأن النسخة أسرع أو أبطأ.
قائمة مراجعة
- Baseline قبل التغيير.
- نفس الجهاز والبيانات.
- قياس أكثر من تشغيل.
- تغيير متغير واحد عند العزل.
شارك في تقييم ونقاش المقال
رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.
النقاش
جارٍ تحميل التعليقات…