Ich habe eine WPF-Datenbank-Viewer-Anwendung: Es ist ein einfaches Hauptfenster, das ein Benutzersteuerelement mit einem Datenraster enthält, das die aus einer SQLite-Datenbank extrahierten Daten anzeigt.
Das Problem ist, dass diese Anwendung 6 Sekunden benötigt, um zu starten, bis sie verwendbar ist.
Ich habe versucht, das Benutzersteuerelement (und das Laden aller Daten) im Konstruktor des Hauptfensters zu erstellen:
Der Begrüßungsbildschirm wird 5s auf diese Weise angezeigt, gefolgt von 1s leerem Hauptfenster, bis die Anwendung zur Verwendung bereit ist.
Benutzer sagten, dass es zu lange dauert, bis etwas (visuell) passiert.
Ich habe dann die Benutzersteuerungs-Erstellung (und das Laden von Daten) in den Loaded-Event-Handler des Hauptfensters verschoben:
Der Startbildschirm wird 3s angezeigt, gefolgt von 3s leerem Hauptfenster, bis die Anwendung fertig ist.
Benutzer sagten, dass es "besser" ist, aber die Tatsache nicht mag, dass ein halbfertiges Hauptfenster so lange im deaktivierten Zustand gezeigt wird.
Gibt es einen allgemeinen Hinweis auf die wahrgenommene Anwendungsladezeit oder gibt es andere Empfehlungen, wie diese Situation verbessert werden kann?
Ich glaube, idealerweise würde das Hauptfenster so schnell wie möglich zusammen mit einer Sanduhr oder einem Spinner angezeigt werden, bis die Daten geladen sind. Aber dann kann ich die Benutzersteuerungs-Erstellung nicht einfach in einen Hintergrund-Worker verschieben, da dies im falschen Thread geschehen würde.
Hat jemand irgendwelche Vorschläge zu diesem Problem?
Bearbeiten:
Beachten Sie, dass ich gerade eine LINQ-to-EF-Abfrage als Rasterdatenquelle zugewiesen habe.
Eine mögliche Verbesserung könnte sein, diese Daten in eine Datentabelle im Hintergrund zu laden und sie erst einmal zu laden ...
Bearbeiten2: Ich verwende .net 4 mit System.Data.SQLite und EF4, um die Daten zu laden. Es gibt mehr oder weniger 4000 Zeilen und 30 Spalten.
Laden Sie Ihre Daten asynchron. Präsentieren Sie dem Benutzer beim Laden etwas Nettes auf der GUI. Der folgende Code kann Ihnen dabei helfen:
%Vor% Die App ist nicht schneller, aber sie scheint viel schneller zu sein, weil die GUI sofort sichtbar und ansprechbar ist. Vielleicht können Sie dem Benutzer auch einen Teil der geladenen Daten zeigen, während er den Rest lädt. Verwenden Sie hierzu das ProgressChanged -Event.
Aktualisieren
Ich bin mir nicht sicher, ob ich dein Problem richtig verstehe. Wenn Ihr Problem nicht die Zeit ist, die Daten geladen werden müssen, dann ist etwas in Ihrer Anwendung seltsam. WPF ist IMO sehr schnell. Die Erstellung von Steuerelementen benötigt nicht viel Zeit. Ich visualisiere viel größere Listen, wie Sie in einigen Millisekunden erwähnen.
Versuchen Sie, nachzusehen, ob in Ihrer Benutzeroberfläche etwas vorhanden ist, das das DataGrid daran hindert, die Elemente zu virtualisieren. Vielleicht hast du dort ein Problem. Um WPF-Apps zu analysieren, kann ich Ihnen die WPF-Profiling-Tools empfehlen.
Das Offensichtlichste, was Sie tun können, ist, Ihre Anwendung zu profilieren und die Engpässe in der Startzeit zu finden. Es klingt wie der wahrscheinlichste Täter wird das Laden von Daten aus Ihrer Datenbank sein.
Eine Lektion, die ich gelernt habe, ist, dass wenn Sie ein ORM verwenden, beim Laden großer Datasets, wenn Sie POCO (Plain Old CLR / C # -Objekte) gegenüber ORM-generierten Datenbankelementen bevorzugen (siehe Beispiel unten), die Ladezeit wird viel schneller und RAM-Auslastung wird auch deutlich verringert werden. Der Grund hierfür ist, dass EF versucht, die gesamte Entität (d. H. Alle Felder) und möglicherweise eine ganze Menge von Daten zu Ihren Entitäten zu laden, von denen Sie die meisten nicht einmal benötigen. Die einzige Zeit, die Sie wirklich direkt mit Entitäten arbeiten müssen, ist, wenn Sie Vorgänge einfügen / aktualisieren / löschen. Beim Lesen von Daten sollten Sie nur Felder abrufen, die Ihre Anwendung anzeigen und / oder validieren muss.
Wenn Sie dem MVVM-Muster folgen, ist die obige Architektur nicht schwer zu implementieren.
Beispiel zum Laden von Daten in POCOs mit EF:
%Vor%POCOs sind sehr einfache Klassen mit autoproperties für jedes Feld.
Wir haben in der Regel Repositorys für jede Entität in unseren Anwendungen, und jedes Repository ist für das Abrufen / Aktualisieren von Daten verantwortlich, die sich auf diese Entität beziehen. Die Ansichtsmodelle haben Verweise auf die Repositories, die sie benötigen, damit sie EF nicht direkt verwenden. Wenn Benutzer Änderungen vornehmen, die persistent sein müssen, verwenden wir andere Methoden im Repository, die dann nur eine Teilmenge von Entitäten laden (dh diejenigen, die der Benutzer geändert hat) und die notwendigen Aktualisierungen anwendet - mit einer vom Viewmodel durchgeführten Validierung und möglicherweise einer anderen Validierung in der DB über Constraints / Trigger, etc.
Dafür gibt es viele Gründe.
1) Deployment-Rechner könnte eine relativ niedrige Konfiguration haben.
2) In-Proper oder Problem mit der Datenbindung.
Mögliche Lösungen wären:
1) Lazy laden die Daten
2) Optimieren Sie die Leistung. Ссылка
Ich hatte gesehen, dass Anwendungen 5M-Datensätze weniger als eine Sekunde in wpf renderten.
PS: Eine weitere mögliche Ursache können 30 Spalten sein, aufgrund des Zugriffs auf die Spaltenreihenfolge.
Tags und Links wpf .net c# performance app-startup