أوقف تسرب الذاكرة في Monosnap — التبديل في 60 ثانية

التسرب ليس من جهاز الكمبيوتر الخاص بك

إذا كنت تتساءل عما إذا كان السبب هو جهازك — برنامج تشغيل قديم، أو غرائب Windows 11، أو علامة تبويب Chrome جامحة — فالأمر ليس كذلك. التسرب موجود داخل Monosnap وقد استمر لسنوات. ابحث في r/monosnap وستجد موضوعًا تلو الآخر يصف نفس النمط.

إليك ما يحدث في الكواليس. في كل مرة يلتقط فيها Monosnap منطقة، فإنه يخصص مخزن إطار (frame buffer) كبيرًا بما يكفي لاحتواء بيانات البكسل الخام. لشاشة 2560 × 1440، يبلغ حجم ذلك حوالي 14 ميجابايت. عندما يغلق المحرر، يجب تحرير هذه المخازن وإعادتها إلى نظام التشغيل. في Monosnap، غالبًا لا يتم ذلك — يتم الاحتفاظ بها بواسطة كومة (heap) معالج Electron، في انتظار تمريرة جمع البيانات المهملة (garbage-collection) التي إما لا تعمل أبدًا أو تعمل متأخرة جدًا. على مدار يوم عمل يتضمن أكثر من 40 لقطة، تتراكم المخازن المحتفظ بها لتصل إلى مئات الميجابايت من ذاكرة الوصول العشوائي الوهمية (phantom RAM).

الحل هو تطبيق مختلف

تربط بنية Monosnap التسرب بـ Electron نفسه، وتصحيحه سيتطلب إعادة كتابة مسار الالتقاط (capture pipeline). لم تحدث هذه الإعادة في خمس سنوات. الحل العملي هو أداة صُممت بدون هذه المشكلة من الأساس.

تم بناء Maxisnap على PyQt6 وتم تجميعه باستخدام PyInstaller في ملف تنفيذي واحد لـ Win32. لا توجد عملية Chromium. كل لقطة تخصص QImage، يشير المحرر إليه، وعندما تغلق النافذة يتم إسقاط الإشارة وتعود الذاكرة إلى نظام التشغيل فورًا — لأن نموذج ملكية PyQt وعدّ المراجع في Python كلاهما يحرران الذاكرة بسرعة بدلاً من انتظار جمع البيانات المهملة (GC) الأجيالي.

تجريبيًا: يبلغ حجم Maxisnap في وضع الخمول عند التشغيل حوالي 50 ميجابايت. بعد 72 ساعة من التشغيل المتواصل مع التقاطات منتظمة، لا يزال حوالي 50 ميجابايت. الرسم البياني أعلاه مأخوذ من سجلات فعلية.