Speicherlecks, die noch in WPF 4 vorhanden sind

Question

Speicherlecks, die noch in WPF 4 vorhanden sind

8

Ich wollte ein WPF-MVVM-Geschäftsanwendungs-Framework erstellen und stieß auf viele Artikel, wenn ich über Speicherlecks in der WPF-Plattform recherchierte.

Wenn Sie die Datenbindung in Windows Presentation Foundation verwenden, kann ein Speicherverlust auftreten
Vermeiden eines WPF-Speicherlecks mit DataBinding ( Black Magic)
Ernste Speicherlecks Plague WPF
Top 5 Speicherverluste in WPF und Silverlight
WPF Binding Bug führt zu möglichen Speicherproblemen

Aber die meisten von ihnen stammen aus den Jahren 2007 und 2008, also habe ich mich gefragt, welche von ihnen gelöst wurde und welche nicht.

Mit anderen Worten: Was sind die möglichen Ursachen für Speicherlecks (die möglicherweise auftreten), die beim Erstellen meines Frameworks berücksichtigt werden müssen oder auf die allgemein geachtet werden muss (WPF 4.0, .NET 4.0)?

Bearbeiten: Ich werde versuchen, genauer zu sein. Kann ich die WeakEventManager und ihre Unterklassen zum Anhören nutzen? für Veranstaltungen ohne eigene Lösung zu entwickeln?

Bearbeiten 2: Noch spezifischer. Kann ich WeakEventManager verwenden, um das Problem des Speicherlecks zu lösen, das durch Ereignisse in .NET im Allgemeinen und nicht nur durch WPF verursacht wird? Wenn ja, warum gehört es zu einem WPF-Namespace und nicht zu einem allgemeinen .NET-Namespace?

wpf .net c#

Ibrahim Najjar 15.07.2013, 14:21

quelle

1 Antwort

Tags und Links wpf .net c#

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Welche Python-SOAP-Bibliotheken werden noch gepflegt?

score 8 · Accepted Answer

Das kommt mir zuerst in den Sinn:

System.Windows.Interactivity.Behavior von System.Windows.Interactivity.dll: Ein Verhalten wird möglicherweise nicht getrennt, wenn Sie es erwarten, und umgekehrt, verlassen hinzugefügt Ereignishandler auf dem Steuerelement zu überleben gc
Nur durch Ihre Beschreibung bin ich mir ziemlich sicher, dass Sie in Zukunft Drittanbieter-Komponenten verwenden werden. Wir fanden, dass dies ein erstklassiger Kandidat für undichte Stellen ist

Die Tatsache, dass Sie darüber nachdenken, bevor Sie beginnen, ist ein Plus, investieren Sie in einen guten MemoryProfiler und profilieren Sie Ihre App von Anfang an regelmäßig und Sie werden in Ordnung sein.

Bearbeiten: Um Ihre Änderungen zu kommentieren: Überprüfen Sie über Ihre Links Ich denke, Sie können drei Hauptthemen isolieren:

Die Implementierung von INotifyPropertyChanged ist ein Muss. Ihr erster Entwickler, der Ihnen sagt "es ist nur eine statische Ansicht, Daten werden sich nicht auf meinem Modell ändern, ich habe nur INPC übersprungen" muss in der Öffentlichkeit gezeichnet und geviertelt werden. Noch besser, Ihr Framework sollte die Implementierung dieser Schnittstelle erzwingen oder es zumindest für Entwickler so einfach wie möglich machen, sie zu benutzen.
Nicht an PropertyDescriptors binden, was nicht an erster Stelle offensichtlich ist, aber Ihr Framework könnte einen Pfad für Entwickler setzen, der es nur verwendet, um an benutzerdefinierte Viewmodel-Eigenschaften zu binden.
Heben Sie immer die Registrierung Ihres Eventhandlers auf, was meiner Meinung nach eher eine Frage der Code-Hygiene ist

Was Ihre Bearbeitung in Bezug auf schwache Ereignisse angeht, könnte dies funktionieren. Persönlich würde ich diese gute Praxis nicht in Erwägung ziehen, da dies zu Situationen führen könnte, in denen Ihr Modell, das die Ereignisse anzeigt, bei denen Sie sich registrieren, früher aufgeräumt wird, als Sie es erwarten. Ich würde vorschlagen, die Extra-Meile zu gehen und bewusst Ihre Handler abmelden.