Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Die Datenbindung von Windows Presentation Foundation (WPF) bietet eine einfache und konsistente Möglichkeit für Anwendungen zum Präsentieren und Interagieren mit Daten. Elemente können in Form von CLR Objekten und XML an Daten aus einer Vielzahl von Datenquellen gebunden werden.
Dieses Thema enthält Empfehlungen zur Datenbindungsleistung.
So werden Datenbindungsverweise aufgelöst
Bevor Sie Probleme mit der Datenbindung behandeln, lohnt es sich, zu untersuchen, wie das Windows Presentation Foundation (WPF)-Datenbindungsmodul Objektverweise für die Bindung löst.
Die Quelle einer Windows Presentation Foundation (WPF)-Datenbindung kann ein beliebiges CLR-Objekt sein. Sie können an Eigenschaften, Untereigenschaften oder Indexer eines CLR Objekts binden. Die Bindungsverweise werden mithilfe einer Microsoft .NET Framework-Reflexion oder ICustomTypeDescriptor aufgelöst. Dies sind drei Methoden zu Auflösung von Objektverweisen für die Bindung.
Die erste Methode umfasst die Verwendung von Spiegelung. In diesem Fall wird das PropertyInfo-Objekt verwendet, um die Attribute der Eigenschaft zu ermitteln und Zugriff auf Eigenschaftsmetadaten zu bieten. Bei Verwendung der ICustomTypeDescriptor-Schnittstelle verwendet das Datenbindungsmodul diese Schnittstelle, um auf die Eigenschaftswerte zuzugreifen. Die ICustomTypeDescriptor Schnittstelle ist besonders nützlich in Fällen, in denen das Objekt keinen statischen Satz von Eigenschaften aufweist.
Eigenschaftenänderungsbenachrichtigungen können entweder durch Implementieren der INotifyPropertyChanged-Schnittstelle oder mithilfe der Änderungsbenachrichtigungen bereitgestellt werden, die dem TypeDescriptorzugeordnet sind. Die bevorzugte Strategie für die Implementierung von Eigenschaftsänderungsbenachrichtigungen besteht jedoch darin, INotifyPropertyChangedzu verwenden.
Wenn es sich bei dem Quellobjekt um ein CLR-Objekt handelt und die Quelleigenschaft eine CLR-Eigenschaft ist, muss das Datenbindungsmodul von Windows Presentation Foundation (WPF) zuerst die Spiegelung des Quellobjekts verwenden, um die TypeDescriptorabzurufen, und dann eine PropertyDescriptorabfragen. Diese Abfolge von Spiegelungsvorgängen ist aus Leistungsperspektive potenziell sehr zeitaufwändig.
Die zweite Methode zum Auflösen von Objektverweisen umfasst ein CLR Quellobjekt, das die INotifyPropertyChanged Schnittstelle implementiert, und eine Quelleigenschaft, die eine CLR-Eigenschaft ist. In diesem Fall verwendet das Datenbindungsmodul Spiegelung direkt auf den Quelltyp und ruft die erforderliche Eigenschaft ab. Dies stellt immer noch nicht die optimale Methode dar, aber sie hat weniger Arbeitssatzanforderungen als die erste Methode.
Die dritte Methode zum Auflösen von Objektverweisen umfasst ein Quellobjekt, das eine DependencyObject und eine Quelleigenschaft ist, die ein DependencyPropertyist. In diesem Fall muss das Datenbindungsmodul keine Spiegelung verwenden. Stattdessen lösen das Eigenschaftenmodul und das Datenbindungsmodul den Eigenschaftsverweis unabhängig voneinander auf. Dies ist die optimale Methode zum Auflösen von Objektverweisen, die für die Datenbindung verwendet werden.
In der folgenden Tabelle wird die Geschwindigkeit der Datenbindung der Text-Eigenschaft von 1000 TextBlock-Elementen mit diesen drei Methoden verglichen.
Bindung einer Texteigenschaft an einen TextBlock | Bindungszeit (ms) | Renderzeit – beinhaltet Bindung (ms) |
---|---|---|
Zu einer Eigenschaft eines CLR-Objekts | 115 | 314 |
Zu einer Eigenschaft eines CLR-Objekts, die INotifyPropertyChanged implementiert | 115 | 305 |
An eine DependencyProperty eines DependencyObject. | 90 | 263 |
Bindung an große CLR-Objekte
Beim Datenbinden an ein einzelnes CLR-Objekt mit Tausenden von Eigenschaften gibt es eine erhebliche Leistungsbelastung. Sie können diese Auswirkung minimieren, indem Sie das einzelne Objekt in mehrere CLR Objekte mit weniger Eigenschaften aufteilen. Die Tabelle zeigt die Bindungs- und Renderingzeiten für die Datenbindung an ein einzelnes großes CLR-Objekt im Vergleich zu mehreren kleineren Objekten.
Datenbindung an 1000 TextBlock-Objekte | Bindungszeit (ms) | Renderzeit – beinhaltet Bindung (ms) |
---|---|---|
Zu einem CLR-Objekt mit 1000 Eigenschaften | 950 | 1.200 |
An 1000 CLR-Objekte mit einer Eigenschaft | 115 | 314 |
Bindung an eine ItemsSource
Betrachten Sie ein Szenario, in dem Sie über ein CLRList<T>-Objekt verfügen, das eine Liste der Mitarbeiter enthält, die Sie in einem ListBoxanzeigen möchten. Um eine Korrespondenz zwischen diesen beiden Objekten zu erstellen, binden Sie die Mitarbeiterliste an die ItemsSource Eigenschaft der ListBox. Angenommen, Sie haben einen neuen Mitarbeiter, der Ihrer Gruppe beitritt. Jetzt könnten Sie denken, dass Sie diese Person einfach Ihrer Mitarbeiterliste hinzufügen müssen, um sie in die gebundenen ListBox-Werte einzubeziehen, und davon ausgehen, dass diese Änderung automatisch von der Datenbindungs-Engine erkannt wird. Diese Annahme wäre falsch; in der Realität wird die Änderung nicht automatisch in der ListBox widergespiegelt. Dies liegt daran, dass das CLRList<T>-Objekt kein Ereignis zum Ändern einer Auflistung automatisch auslöst. Um die ListBox dazu zu bringen, die Änderungen zu übernehmen, müssen Sie Ihre Liste der Mitarbeiter neu erstellen und sie der ItemsSource-Eigenschaft der ListBoxerneut anfügen. Während diese Lösung funktioniert, führt sie zu einer enormen Leistungsbeeinträchtigung. Jedes Mal, wenn Sie die ItemsSource von ListBox einem neuen Objekt neu zuweisen, löst die ListBox zuerst die vorherigen Elemente aus und generiert die gesamte Liste erneut. Die Leistungsbeeinträchtigung wird noch verstärkt, wenn Ihr ListBox-Element einem komplexen DataTemplate-Element zugeordnet ist.
Eine sehr effiziente Lösung für dieses Problem besteht darin, Ihre Mitarbeiterliste zu einer ObservableCollection<T>zu machen. Ein ObservableCollection<T>-Objekt löst eine Änderungsbenachrichtigung aus, die das Datenbindungsmodul empfangen kann. Das Ereignis fügt ein Element aus einer ItemsControl hinzu oder entfernt es, ohne dass die gesamte Liste neu erstellt werden muss.
Die folgende Tabelle zeigt die Zeit, die zum Aktualisieren der ListBox (mit deaktivierter UI-Virtualisierung) benötigt wird, wenn ein Element hinzugefügt wird. Die Zahl in der ersten Zeile stellt die verstrichene Zeit dar, wenn das CLRList<T>-Objekt an das ListBox-Element ItemsSourcegebunden ist. Die Zahl in der zweiten Zeile stellt die verstrichene Zeit dar, wenn ein ObservableCollection<T> an die ListBoxdes ItemsSource Elements gebunden ist. Beachten Sie die erhebliche Zeitersparnis mit der ObservableCollection<T> Datenbindungsstrategie.
Datenbindung der ItemsSource | Aktualisierungszeit für 1 Element (ms) |
---|---|
An ein CLRList<T>-Objekt | 1656 |
An ein ObservableCollection<T> | 20 |
Binden Sie IList an ItemsControl statt IEnumerable
Wenn Sie eine Auswahl zwischen der Bindung eines IList<T> oder einer IEnumerable an ein ItemsControl-Objekt haben, wählen Sie das IList<T>-Objekt aus. Das Binden von IEnumerable an ItemsControl zwingt WPF dazu, ein Wrapper-Objekt IList<T> zu erstellen, was bedeutet, dass Ihre Leistung durch die zusätzliche Belastung eines zweiten Objekts beeinträchtigt wird.
Konvertieren Sie nicht CLR Objekte nur für die Datenbindung in XML.
Mit WPF können Sie Daten an XML-Inhalte binden; Die Datenbindung an XML-Inhalte ist jedoch langsamer als die Datenbindung an CLR Objekte. Konvertieren Sie CLR Objektdaten nicht in XML, wenn der einzige Zweck für die Datenbindung ist.
Siehe auch
- Optimieren der WPF-Anwendungsleistung
- Planung der Anwendungsleistung
- Die Vorteile der Hardware nutzen
- Layout und Entwurf
- 2D-Grafik und Bildverarbeitung
- Objektverhalten
- Anwendungsressourcen
- Text
- Andere Leistungsempfehlungen
- Übersicht zur Datenbindung
- Exemplarische Vorgehensweise: Zwischenspeichern von Anwendungsdaten in einer WPF-Anwendung
.NET Desktop feedback