تتيح لك "أدوات مطوّري Chrome" للوكلاء تحليل تسرّبات الذاكرة من جهة العميل (بما في ذلك JavaScript وWebAssembly) وإصلاحها في تطبيقك من خلال وكيل الترميز. من خلال أتمتة عملية جمع لقطات لعناصر متعدّدة وتحليلها، يمكن للوكيل تحديد العناصر التي لا يتم جمع البيانات المُهمَلة لها بشكلٍ صحيح واقتراح إعادة صياغة الرمز البرمجي المستهدَف.
في سير عمل الوكيل، يأخذ وكيل الترميز لقطات متعدّدة عبر حالات التطبيق المختلفة ويستخدم أدوات تحليل متخصّصة.
تفعيل أدوات تصحيح أخطاء الذاكرة
لا تعرض "أدوات مطوّري Chrome" للوكلاء بشكلٍ تلقائي سوى أداة take_heapsnapshot. لا تتوفّر الأدوات التي تحلّل لقطات لعناصر متعدّدة (مثل compare_heapsnapshots وget_heapsnapshot_summary وget_heapsnapshot_retaining_paths) إلا عند بدء الخادم باستخدام العلامة --memoryDebugging. بدون هذه العلامة، يمكن للوكيل التقاط اللقطات ولكن لا يمكنه تحليلها.
لتفعيل أدوات تصحيح أخطاء الذاكرة، أضِف --memoryDebugging إلى وسيطات الخادم:
"args": ["chrome-devtools-mcp@latest", "--memoryDebugging"]
لمزيد من الخيارات، يُرجى الاطّلاع على الإعدادات.
أنماط تسرّبات الذاكرة الشائعة
يركّز تحليل الذاكرة على العثور على أنماط التسرّبات الشائعة، بما في ذلك:
- متتبِّعات الأحداث التي لم تتم إزالتها: متتبِّعات الأحداث المرفقة بالعناصر العمومية (مثل
windowأوdocument) التي تمنع جمع البيانات المُهمَلة. - عُقد DOM المنفصلة: العُقد التي تمت إزالتها من شجرة المستند ولكن لا يزال يتم الرجوع إليها من خلال متغيّر JavaScript.
- المتغيّرات العمومية غير المقصودة: المتغيّرات التي تم تعريفها بدون تحديد نطاق مناسب والتي تظل في الذاكرة إلى الأبد.
- الإغلاقات: الإغلاقات التي تحتفظ عن غير قصد بمراجع لكائنات كبيرة في نطاقها الخاص.
- بُنى البيانات غير المحدودة: بُنى البيانات المستخدَمة للتخزين المؤقت والتي تنمو بدون حدود.
اعتبارات تحليل الذاكرة
عند استخدام تحليل الذاكرة، ضَع في اعتبارك ما يلي:
عدم قراءة اللقطات الأولية مباشرةً: لا تسمح للوكيل بقراءة ملفات
.heapsnapshotالأولية مباشرةً. فهي كبيرة جدًا وتتجاوز حدود السياق. توجّه مهارة تصحيح أخطاء تسرّب الذاكرة الوكلاء بشكلٍ صريح إلى تجنُّب قراءة هذه الملفات.منهجية اللقطات الثلاث: للعثور على التسرّبات بشكلٍ موثوق، يحتاج الوكيل عادةً إلى التقاط ثلاث لقطات: لقطة أساسية قبل الإجراء، ولقطة مستهدَفة بعد الإجراء، ولقطة نهائية بعد التراجع عن الإجراء. يُرجى العِلم أنّ بعض الإجراءات، مثل تلك التي يتم تشغيلها بواسطة المؤقتات (
setTimeout) أو الرسوم المتحركة (requestAnimationFrame)، تحدث بدون تفاعل المستخدم وقد لا تتطلّب خطوة عكس.يُرجى العِلم أنّ بعض الإجراءات، مثل تلك التي يتم تشغيلها بواسطة المؤقتات (
setTimeout) أو الرسوم المتحركة (requestAnimationFrame)، تحدث بدون تفاعل المستخدم وقد تزيد مع ذلك من استخدام الذاكرة.التأكّد قبل الإصلاح: راجِع دائمًا نتائج الوكيل للتأكّد من أنّ الإجراءات المقترَحة قابلة للتطبيق وصحيحة لمنطق تطبيقك. على سبيل المثال، تأكَّد مما إذا كانت العُقدة المنفصلة جزءًا من ذاكرة تخزين مؤقتة مقصودة قبل توجيه الوكيل إلى إبطال المراجع.
حالات استخدام تحليل تسرّبات الذاكرة
وجِّه الوكيل إلى تحليل الذاكرة أثناء الإجراءات المتكرّرة، بما في ذلك المؤقتات وتفاعلات المستخدم، بدلاً من أخذ اللقطات يدويًا ومقارنتها يدويًا. يمكنك دمج تحليل الذاكرة في عملية تصحيح الأخطاء باستخدام مهام سير العمل هذه.
ملاحظة: خطوات تنفيذ الوكيل هي أمثلة على السلوك المحتمَل. قد يتصرّف الوكيل بشكلٍ مختلف.
رصد متتبِّعات الأحداث التي لم تتم إزالتها أثناء التنقّل
غالبًا ما تتسرّب التطبيقات ذات الصفحة الواحدة (SPA) الذاكرة عندما ينسى المطوّرون إزالة متتبِّعات الأحداث العمومية بعد إلغاء تحميل أحد المكوّنات. يمكنك تكليف الوكيل بالتأكّد من تحرير الذاكرة بشكلٍ صحيح عند التنقّل بين طرق العرض.
مثال على الطلب:
Navigate from the home page to the dashboard and back to the home page. Use the take_heapsnapshot tool to check if we have any uncleared event listeners causing memory leaks.
مثال على تنفيذ الوكيل: يأخذ الوكيل لقطة لعناصر متعدّدة أساسية على الصفحة الرئيسية، وينتقل إلى لوحة البيانات، ثم يعود إلى الصفحة الرئيسية لأخذ لقطة نهائية. بعد ذلك، يستخدم الوكيل أدوات تحليل داخلية لتقييم اللقطات، ويكتشف أنّه لم تتم إزالة أداة معالجة scroll المرفقة بالكائن window، ويقدّم الرمز البرمجي المحدّد لاستدعاء removeEventListener في دالة التنظيف الخاصة بالمكوّن.
تحديد عُقد DOM المنفصلة في مكوّنات واجهة المستخدم
غالبًا ما تترك النوافذ المنبثقة والقوائم المنسدلة ومكوّنات واجهة المستخدم المعقّدة عُقد DOM منفصلة إذا تم الاحتفاظ بمراجع لها في متغيّرات JavaScript بعد إزالتها من DOM.
مثال على الطلب:
Open the user settings modal and close it 5 times. Analyze the heap snapshots and tell me if there are any detached DOM nodes left behind. If there are, ask me if they are intentional before writing a fix.
مثال على تنفيذ الوكيل: يتفاعل الوكيل مع النافذة المنبثقة للإعدادات أثناء جمع اللقطات الأساسية والمستهدَفة والنهائية المطلوبة. يكشف التحليل عن عدة كائنات متزايدة مصنّفة على أنّها Detached HTMLDivElement. يُعلمك الوكيل بالنتيجة ويطلب منك التأكيد قبل تغيير الرمز البرمجي لضبط المتغيّرات التي تحتوي على مراجع DOM على null.
العثور على ذاكرات التخزين المؤقت غير المحدودة في التفاعلات المستمرة
يمكن أن تتسرّب ميزات مثل التمرير لا نهائي أو جلب البيانات المستمر الذاكرة إذا كانت الصفائف أو الخرائط الأساسية تنمو بلا حدود.
مثال على الطلب:
Scroll down the infinite feed list to load more items three times. Check if our LRU cache is unbounded and leaking memory, and suggest a fix.
مثال على تنفيذ الوكيل: يحلّل الوكيل حالة الذاكرة قبل التمرير وبعده. ويحدّد الوكيل إغلاقًا يلتقط عن غير قصد صفيفًا كبيرًا ينمو بلا حدود. يقترح الوكيل تطبيق حدود التخزين المؤقت أو استخدام WeakMap للبيانات المرتبطة بدورات حياة الكائن للسماح بجمع البيانات غير الضرورية بشكلٍ صحيح.
تصحيح أخطاء تسرّبات الذاكرة في العمليات التي تجري في الخلفية
يمكن أن تتسرّب المؤقتات الخاصة بالرسوم المتحركة والخلفية الذاكرة بدون تفاعل صريح من المستخدم. يمكنك توجيه الوكيل إلى مراقبة نمو الذاكرة بمرور الوقت للعثور على تسرّبات الذاكرة لهذه العمليات.
مثال على الطلب:
Explore this canvas application and monitor memory usage. Help me determine areas of improvement around reusing objects and textures.
مثال على تنفيذ الوكيل: يستكشف الوكيل تطبيق اللوحة القماشية ويأخذ تلقائيًا لقطات دورية لمراقبة استخدام الذاكرة بمرور الوقت. يحلّل الوكيل الذاكرة المؤقتة ويحدّد أنّ حلقة العرض تُرسِل شبكات WebGL جديدة إلى صفيف في كل إطار بدون جمع البيانات غير الضرورية من الشبكات السابقة، ما يشير إلى تحسينات لإعادة استخدام الكائنات.