Ich habe ein einfaches WPF-Programm, das nur eine einzige Schaltfläche ohne Ereignisbehandlungslogik hat. Ich verwende dann das UIAutomation-Framework, um diese Schaltfläche mehrmals hintereinander anzuklicken. Abschließend betrachte ich die Speicherkapazität des WPF-Programms und es scheint zu wachsen und zu wachsen.
Wer weiß, warum das so ist und wie ich das verhindern kann?
Hier ist das einfache WPF-Programm (nichts im Code dahinter):
%Vor%Hier ist das UIAutomation-Testprogramm:
%Vor%Hier sind die Ergebnisse aus dem Programm auf meiner Maschine:
%Vor%Wenn Sie es mit dem .NET Memory Profiler betrachten, stammen die neuen Objekte, die in der WPF-Anwendung erscheinen, aus dem System.Threading-Namespace. Wenn ich das WPF-Programm selbst ausführe und auf den Knopf mit der Maus klicke, erscheinen diese Objekte nicht.
UPDATE:
Ich habe versucht, einen ähnlichen Test mit der CodedUI von Visual Studio durchzuführen, und die gleichen 8 Objekte schienen auch in dieser Situation zu lecken. Die Objekte, die zu lecken scheinen, sind:
%Vor%Ich habe auch einen Fehler bei Microsoft eingereicht:
Nachdem wir mit dem Microsoft-Kundensupport gesprochen haben, haben wir die Antwort auf das Problem gefunden. Intern gibt sich WPF drei Minuten Zeit, um auf ein UI Automation-Ereignis zu reagieren. Um dies zu tun, startet es einen Timer. Es sieht so aus, als ob der Timer auch dann nicht abläuft, wenn auf das Ereignis sofort reagiert wird, bis die drei Minuten abgelaufen sind.
Die Problemumgehung besteht also darin, zu warten, bis der Timer abläuft, und dann eine GC.Collect-Operation durchzuführen. Dann wird das Speicherproblem verschwinden. Keine großartige Lösung, aber es funktioniert für unsere Situation.
Tags und Links wpf memory-leaks c# ui-automation