In meiner WPF-Anwendung lade ich Inhalt mit Dispatcher.BeginInvoke im Konstruktor. Meine Frage ist, wird es den UI-Thread blockieren?
Oder ist es besser, Task.Factory.StartNew zu verwenden und dann die Dinge auf der Benutzeroberfläche zurückzuschicken, so dass die Anwendung unabhängig von der Ladeprozesszeit zuerst geladen wird?
Was ist besser Ansatz und warum?
Sie machen zwei sehr unterschiedliche Dinge:
Task.Factory.StartNew plant einen Delegaten zur Ausführung auf a
Threadpool-Thread. Der aktuelle Thread wird weiterhin ausgeführt, ohne auf ein Ergebnis dieser Task zu warten (asynchron). Normalerweise würden Sie eine länger laufende Hintergrundaufgabe erzeugen, so dass die Benutzeroberfläche nicht zu lange blockiert wird (nicht "eingefroren").
Dispatcher.BeginInvoke plant einen Delegaten zur Ausführung auf dem
Dispatcher (UI) -Thread. Normalerweise wird dies getan, um einige UI zu aktualisieren
steuert mit den Ergebnissen einer Operation, die auf einem ausgeführt wurde
Hintergrundfaden. Im Wesentlichen aktualisieren Sie die Benutzeroberfläche hier.
Um Ihre Fragen direkt zu beantworten:
Sie sollten keine langwierigen Vorgänge im Dispatcher-Thread planen, in der Regel möchten Sie hier nur die UI-Steuerelemente aktualisieren. Der Code im Delegaten wird im UI-Thread ausgeführt, der für die Ausführung gesperrt ist. Setzen Sie einfach einen Thread.Sleep(10000) in Ihren aktuellen Code (den Sie vom Konstruktor aus planen) und Sie werden sehen, dass die Benutzeroberfläche einfriert. Verwenden Sie dazu eine Hintergrundaufgabe - entweder mit einem Task oder einem Hintergrund-Worker (beide verwenden einen Thread-Pool-Thread).
Oder ist es besser, Task.Factory.StartNew zu verwenden und dann zu versenden Dinge zurück auf der Benutzeroberfläche, so dass die Anwendung zuerst unabhängig von geladen wird die Ladezeit des Inhalts.
Ja!
Tags und Links wpf c# task-parallel-library