जानबूझकर एक जीवनचक्र दोहराएँ
लोड करने के बाद बेसलाइन कैप्चर करें, वही लघु स्तर खेलें, मेनू पर वापस लौटें, और उस सटीक मार्ग को कई बार दोहराएं। जब टूलींग इसकी अनुमति देती है तो सफाई और कचरा संग्रहण के बाद उसी बिंदु पर लिए गए स्नैपशॉट की तुलना करने के लिए ब्राउज़र मेमोरी टूल का उपयोग करें। केवल कुल मेमोरी पर प्रतिक्रिया करने के बजाय, किसी विशिष्ट ऑब्जेक्ट प्रकार, जैसे दृश्य नोड्स, की बढ़ती संख्या पर ध्यान दें।
डेवलपर टूल को एक बार बंद करके परीक्षण चलाएं और यदि माप स्वयं व्यवहार बदलता प्रतीत हो तो एक बार खोलें। उपयोगी संकेत यह है कि क्या समान वर्ग और बनाए गए पथ चक्रों में जमा होते हैं, न कि क्या एक स्नैपशॉट में दूसरी मशीन की तुलना में बड़ी संख्या होती है।
हर दृश्य के लिए स्पष्ट सफ़ाई प्रक्रिया रखें
दृश्य समाप्त होने पर लंबित एनीमेशन फ़्रेम रद्द करें, टाइमर रोकें, लंबे समय तक जीवित रहने वाले लक्ष्यों पर जोड़े गए श्रोताओं को हटाएँ और दृश्य की इकाइयाँ रखने वाले संग्रह खाली करें। कॉलबैक के संदर्भ सुरक्षित रखें ताकि उन्हें हटाया जा सके, या संबंधित श्रोताओं को AbortController के अंतर्गत समूहित करके दृश्य समाप्त करते समय समूह रद्द करें।
सीमा जाँचें: दृश्य में जाएँ और उससे बाहर निकलें, पुरानी इनपुट कार्रवाई करें और पुष्टि करें कि पिछला दृश्य अब प्रतिक्रिया नहीं देता। यह भी जाँचें कि कैश किए गए एसेट जानबूझकर साझा किए गए हैं या छोड़े गए हैं। बिना भेदभाव की सफ़ाई से अनावश्यक री-लोड हो सकते हैं, जबकि गलती से बचा संदर्भ बड़े दृश्य को मेमोरी में बनाए रख सकता है।
ब्राउज़र गेम मेमोरी लीक से जुड़े सवाल
क्या मेमोरी का ऊपर जाना लीक साबित होता है?
नहीं। ब्राउज़र मेमोरी आरक्षित करते हैं और अपने समय पर ऑब्जेक्ट हटाते हैं। यदि समान जीवनचक्र दोहराने पर कोड में अब भी मौजूद संदर्भ के कारण धीरे-धीरे अधिक इंस्टेंस बने रहते हैं, तो लीक की आशंका बढ़ती है।
क्या किसी ईवेंट श्रोता को हटाने से सफ़ाई में मदद मिल सकती है?
हाँ, जब लंबी अवधि तक रहने वाला लक्ष्य ऐसा कॉलबैक रखता है जो दृश्य के डेटा का संदर्भ देता है। MDN removeEventListener() का वर्णन करता है और AbortSignal देकर श्रोताओं के समूह को एक साथ हटाने का तरीका भी बताता है।
आगे पढ़ें
कोई पुरानी जानकारी दिखी? सुधार की जानकारी दें