WPF में मेमोरी लीक से छुटकारा पाएं

DevExpress पर, हम WPF और सिल्वरलाइट के लिए व्यावसायिक घटकों पर बहुत प्रयास करते हैं । हमारे पास नियंत्रण रेखा है, जिसकी सूची में हाल ही में शामिल DXPivotGrid - Excel से PivotTable टूल का प्रतिस्थापन है। नए घटकों को विकसित करने की प्रक्रिया में, हम मौजूदा कोड का अधिकतम उपयोग करने का प्रयास करते हैं। उदाहरण के लिए, WinForms के लिए PivotGrid संस्करण से आधार कक्षाएं। अक्सर यह उन समस्याओं को जन्म देता है जो .NET 2.0 के तहत विकसित करते समय आपके सामने नहीं आईं। जब मैंने WPF के लिए PivotGrid लिखा, तो मुझे घटनाओं के लिए सदस्यता लेने (अधिक सटीक, "सदस्यता समाप्त") के कारण मेमोरी लीक के साथ समस्याओं को हल करना पड़ा।





Microsoft ने .NET 3.0 में एक कमजोर घटना की अवधारणा पेश की: यह मानक घटनाओं की भिन्नता है जो इवेंट हैंडलर के लिए सीधा लिंक नहीं रखती है। दूसरी ओर, साधारण हैंडलर दो संदर्भ होते हैं: एक वस्तु के लिए, और दूसरा ऑब्जेक्ट के अंदर विधि के लिए। कुछ भी नया नहीं है, लेकिन एक अति सूक्ष्म अंतर है।



इवेंट हैंडलर को कचरा कलेक्टर द्वारा संसाधित नहीं किया जाएगा, जब तक कि वह इवेंट से अनसब्सक्राइब नहीं करता। यह देखते हुए कि WPF IDisposable इंटरफ़ेस का उपयोग नहीं करता है, यह एक बड़ी समस्या में बदल जाता है।



समाधान के रूप में, Microsoft शिथिल युग्मित घटना संचालकों (कमजोर घटनाओं - " Microsoft के कमजोर घटना संचालकों") को प्रस्तुत करता है। कचरा संग्रहकर्ता ऐसे आयोजनों की सदस्यता लेने वाली वस्तुओं को संसाधित कर सकता है, भले ही सदस्यता अभी भी मौजूद हो।



एक कमजोर घटना बनाने के दो तरीके हैं: WeakEventManager या RoutedEvent का उपयोग करें।

WeakEventManager

WeakEventManager वर्ग आपको एक मौजूदा घटना को एक कमजोर घटना में बदलने की अनुमति देता है। मेरी परियोजना में, उत्पाद कोर से घटनाओं की सदस्यता लेना आवश्यक था, जो .NET 2.0 के साथ संगत होना चाहिए।



कमजोर घटनाओं को दो वर्गों का उपयोग करके बनाया जाता है: WeakEventManager (डिस्पैचर) और WeakEventListener (श्रोता)। ईवेंट डिस्पैचर इसकी सदस्यता लेता है और श्रोताओं को कॉल स्थानांतरित करता है, अर्थात। स्रोत और प्राप्तकर्ता के बीच एक परत है, जो कड़ी को तोड़ती है।



यह एक इवेंट डिस्पैचर टेम्पलेट है।

public class MyEventManager : WeakEventManager { static MyEventManager CurrentManager { get { //     Type managerType = typeof(MyEventManager); MyEventManager currentManager = (MyEventManager)WeakEventManager.GetCurrentManager(managerType); if(currentManager == null) { currentManager = new MyEventManager(); WeakEventManager.SetCurrentManager(managerType, currentManager); } return currentManager; } } MyEventManager() { } //  "T"      public static void AddListener(T source, IWeakEventListener listener) { CurrentManager.ProtectedAddListener(source, listener); } //  "T"      public static void RemoveListener(T source, IWeakEventListener listener) { CurrentManager.ProtectedRemoveListener(source, listener); } protected override void StartListening(object source) { //    // , ((T)source).Event += EventHandler; } protected override void StopListening(object source) { //    // , ((T)source).Event -= EventHandler; } //   –    //      void EventHandler(object sender, EventArgs e) { base.DeliverEvent(sender, e); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

और यह विजुअल स्टूडियो के लिए एक टेम्पलेट के साथ एक स्निपेट है: https://gist.github.com/777559 । Wem कमांड पर हैंग हो जाता है।



इस टेम्पलेट का उपयोग किसी भी कमजोर ईवेंट प्रबंधक के लिए किया जा सकता है। आपको स्रोत वर्ग नाम, सदस्यता विधि को बदलना होगा और EventHandler विधि में मापदंडों के प्रकार को समायोजित करना होगा।



प्रत्येक वस्तु जो एक कमजोर घटना की सदस्यता लेना चाहती है, उसे IWeakEventListener इंटरफ़ेस को लागू करना चाहिए। इस इंटरफ़ेस में एक एकल प्राप्तकर्ता विधि है। आपको ईवेंट डिस्पैचर के प्रकार की जांच करनी चाहिए, हैंडलर को कॉल करना चाहिए और सही लौटना चाहिए। यदि आप डिस्पैचर के प्रकार को निर्धारित नहीं कर सकते हैं, तो आपको गलत लौटना होगा। इस स्थिति में, System.ExecutionEngineException को त्रुटि के कारण के कुछ समझ से बाहर पाठ के साथ फेंक दिया जाएगा। इसके अनुसार, यह स्पष्ट हो जाता है कि डिस्पैचर्स या श्रोताओं में कोई त्रुटि है।



यहाँ IWeakEventListener इंटरफ़ेस कार्यान्वयन टेम्पलेट है:

 class MyEventListener : IWeakEventListener { bool IWeakEventListener.ReceiveWeakEvent(Type managerType, object sender, EventArgs e) { if(managerType == typeof(MyEventManager)) { //   return true; // ,     } return false; // -    } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

पेशेवरों और विपक्ष

• इस तरह की कमजोर घटना लगभग तुरंत शुरू हो जाती है।
• आप यह निर्धारित कर सकते हैं कि श्रोता हैं और किसी घटना को ट्रिगर नहीं करते हैं यदि वे नहीं हैं। मेरे लिए, यह उन घटनाओं में उपयोगी था जिन्हें बहुत बार बुलाया जाना चाहिए या भारी तर्कों वाली घटनाओं के लिए।
• गैर-यूआईईएल के लिए इस्तेमाल किया जा सकता है। यदि आप WPF से पुराने कोड का उपयोग करना चाहते हैं तो उपयोगी है।
• बनाने के लिए बहुत बोझिल - प्रत्येक घटना को अपने स्वयं के डिस्पैचर की आवश्यकता होती है।

रूटेड इवेंट्स

अग्रेषित ईवेंट XAML (उदाहरण के लिए, EventTrigger में ) संसाधित होने वाली घटनाओं के लिए एक बुनियादी ढाँचा है या जो दृश्य वृक्ष से गुजरती हैं।

उनके मुख्य लाभ:

• ये कमजोर घटनाएँ हैं।
• वे तार्किक पेड़ के कई स्तरों पर हैंडलर कह सकते हैं।

उनके बारे में MSDN पर एक अच्छा लेख है: नियमित घटनाक्रम अवलोकन और इसलिए मैं उन्हें यहां दोहराना नहीं चाहता। लेकिन मैं उनकी दो मुख्य कमियों का उल्लेख करूंगा।

एक मुश्किल कॉल और ग्राहकों की संख्या पर कोई जानकारी नहीं

यह UIElement.RaiseEventImpl विधि का एक हिस्सा है जो रूट की गई घटना को बढ़ाता है:

 internal static void RaiseEventImpl(DependencyObject sender, RoutedEventArgs args) { EventRoute route = EventRouteFactory.FetchObject(args.RoutedEvent); if (TraceRoutedEvent.IsEnabled) { TraceRoutedEvent.Trace(TraceEventType.Start, TraceRoutedEvent.RaiseEvent, new object[] { args.RoutedEvent, sender, args, args.Handled }); } try { args.Source = sender; BuildRouteHelper(sender, route, args); route.InvokeHandlers(sender, args); args.Source = args.OriginalSource; } finally { if (TraceRoutedEvent.IsEnabled) { TraceRoutedEvent.Trace(TraceEventType.Stop, TraceRoutedEvent.RaiseEvent, new object[] { args.RoutedEvent, sender, args, args.Handled }); } } EventRouteFactory.RecycleObject(route); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

यह तब तक ठीक लगता है जब तक कि आप BuildRouteHelper और InvokeHandlers विधियों के अंदर नहीं देखते हैं, जिनमें से प्रत्येक 100 लाइनों से अधिक लंबा है। और यह सारी जटिलता किसी एक घटना का कारण बनती है। यह जटिलता इस दृष्टिकोण को अक्सर ट्रिगर होने वाली घटनाओं के लिए अनुपयुक्त बनाती है।

उन्हें केवल UIElement वर्ग के वंशजों में जोड़ा जा सकता है।

आप एक साधारण दिनांक ऑब्जेक्ट जो UIElement से विरासत में नहीं मिला है, के लिए एक रूट की गई घटना नहीं बना सकते। यदि आपकी तकनीकी आवश्यकताएं इसकी अनुमति नहीं देती हैं, तो यह आपके लिए एक समस्या होगी।

अंत में

यदि आप पुराने कोड द्वारा सीमित नहीं हैं और ईवेंट कॉल कई नहीं हैं, तो RoutedEvents का उपयोग करें। यदि आपके पास बहुत सारे कॉल हैं, या यदि आपके पास .NET 2.0 के साथ कोड कॉमन है, तो आपको प्रत्येक के लिए WeakEventManager लिखना होगा। बोझिल, लेकिन आवश्यक।



ये दोनों तरीके मीडियमट्रस्ट में काम करेंगे। यदि यह आवश्यकता आपके लिए महत्वपूर्ण नहीं है, तो अगली श्रृंखला में निर्णय संख्या 3 की प्रतीक्षा करें।