Freigeben über

Hosten von WebView2 im Vergleich zu visuellen Fenstern

  • Artikel

Es gibt drei Optionen zum Hosten des Microsoft Edge WebView2-Steuerelements in Ihrer App:

  • Der Hostingmodus mit Fenstern.
  • Der Hostmodus "Fenster zu Visual".
  • Der visuelle Hostingmodus.

Sie müssen diesen Artikel nicht lesen, wenn Sie in den meisten Szenarien Windows-Hosting verwenden. Hosting im Fenster ist ein guter Ausgangspunkt für die meisten Apps. Lesen Sie diesen Artikel:

  • Wenn Sie Windows-Hosting in ungewöhnlichen Szenarien verwenden und dauerhafte Probleme mit DPI und Skalierung auftreten. Ziehen Sie in diesem Fall das Hosten von Fenster zu Visual in Betracht.
  • Wenn Sie eine benutzerdefiniertere Benutzeroberfläche (User Experience, UX) bereitstellen möchten. In diesem Fall sollten Sie visuelles Hosting in Betracht ziehen.

Die verschiedenen Ansätze zum Hosten des WebView2-Steuerelements in Ihrer App sind ähnlich hinsichtlich der Funktionalität, erfüllen aber je nach App-Anforderungen unterschiedliche Anforderungen, wie folgt:

Ansatz Beschreibung Optimiert für
Hosting mit Fenstern Das WebView2-Steuerelement nimmt Eingaben vom Betriebssystem (Os) entgegen. Das Betriebssystem sendet die Eingabe an WebView2. Schnelles und einfaches Anzeigen von Webinhalten, ohne Features für Eingaben, Ausgaben und Barrierefreiheit einschließen zu müssen.
Hosten von Fenster zu Visual Eine Kombination aus Hosten mit Fenstern und visuellen Elementen. Ähnlich wie beim Hosten von Fenstern, mit der Ausnahme, dass WebView2-Inhalt an ein Visual ausgegeben wird, das in einem Fenster gehostet wird, anstatt die Inhaltsausgabe direkt im Fenster zu haben. Eine Entwicklerumgebung, die fast identisch mit dem Windows-Hosting ist, aber mit verbesserter DPI/Skalierungsbehandlung und dem Vorbehalt, dass die Windows Shell-Handschrift nicht unterstützt wird.
Visuelles Hosting Ihre Host-App übernimmt räumliche Eingaben (z. B. Maus- oder Toucheingaben) vom Benutzer. Ihre App sendet diese Eingabe an das WebView2-Steuerelement. Präzisere Kontrolle über die Steuerelementkomposition. Die App muss eine bestimmte Behandlung von Fensterverwaltungs- und Rendering-APIs durchführen.

Diese Ansätze weisen unterschiedliche Anforderungen, Einschränkungen und Vorteile auf.

  • Fensterhosting ist einfacher zu implementieren als das visuelle Hosting.
  • Für das hosten von Visuals sind alle API-Aufrufe erforderlich, die das Windowed-Hosting erfordert, und es gelten zusätzliche Anforderungen für das ordnungsgemäße Rendern.

Die unterstützten API-Listen sind in den folgenden Abschnitten mit verknüpft:

Hosting mit Fenstern: Zum schnellen und einfachen Anzeigen von Inhalten

Hosting im Fenster bedeutet, dass WebView2-Inhalte in Ihrer App direkt in einem Fenster gehostet werden. d. h. ein HWND. Der WebView2-HWND erbt viele Standardeigenschaften vom Betriebssystem .The WebView2 HWND erbt viele Standardeigenschaften vom Betriebssystem (OS). Das WebView2-Steuerelement nimmt Eingaben vom Betriebssystem an, und das Betriebssystem sendet die Eingabe an das WebView2-Steuerelement. Sie können mehrere HWNDs in Ihrer App enthalten, die jeweils als WebView2-Komponente für den Zugriff auf Webinhalte verwendet werden.

Dies hat den Vorteil, dass einige der Eingabe-/Ausgabebefehle für Sie vom Betriebssystem oder vom Framework verarbeitet werden. Sie müssen jedoch weiterhin einige Aspekte der Fensterverwaltung behandeln.

Allgemeine Informationen zur Fensterverwaltung und HWND -funktionalität finden Sie unter Informationen zu Windows.

Vorteile

  • Hosting im Fenster ermöglicht eine Lösung, die Webinhalte schnell anzeigt, ohne Funktionen für Eingaben, Ausgaben und Barrierefreiheit implementieren zu müssen.

  • Eigene und untergeordnete Fenster (z. B. Menüs und Kontextmenüs) werden automatisch entsprechend der übergeordneten HWND Skalierung der App skaliert.

  • Das Hosten von Fenstern behandelt, wie das WebView2-Steuerelement den Fokus verwaltet und die Tabulatortaste ein- oder aus sich heraus klickt, wenn die TAB-TASTE das letzte Element erreicht.

  • Sie müssen die verschiedenen kompositionsbasierten Renderingsteuerelemente (z. B. Eingaben, Ausgaben und Barrierefreiheitssteuerelemente) nicht verwalten, wenn Sie dies nicht möchten.

Nachteile

Der Hostingmodus mit Fenstern kann in einigen Szenarien zu DPI-Problemen führen, z. B. beim Freigeben eines Benutzerdatenordners (und damit beim Freigeben eines Browserprozesses) für verschiedene Anwendungen mit unterschiedlichem DPI-Bewusstsein.

APIs für Windowed-Hosting

Eine Liste der APIs, die beim Konfigurieren von WebView2 für das Hosten von Fenstern (oder für das Hosten von Windows zu Visual) verwendet werden können, finden Sie unter Rendern von WebView2 in Nicht-Framework-Apps in Übersicht über WebView2-Features und -APIs.

Hosting von Fenstern zu Visuellen Elementen: Für eine ähnliche Erfahrung wie das Hosting mit Fenstern, mit zusätzlichen Vorteilen und Kompromissen

Window-to-Visual-Hosting bedeutet, dass der WebView2-Inhalt an ein Visual ausgegeben wird, das in einem HWND gehostet wird, anstatt Inhalte direkt in einem Fenster oder direkt in ein Visual auszugeben. Durch das Hosten von Inhalten in einem HWND ist das Hosten von Windows zu Visual auf die gleiche Weise wie das Hosten von Fenstern einfach zu verwenden. Durch das Anzeigen von Inhalten mithilfe eines Visuals vermeidet das Hosten von Fenster zu Visual jedoch einige DPI- und Eingabeprobleme, die bei der Verwendung von Windowed-Hosting auftreten können.

Für das Hosten von Fenster zu Visual ist es nicht erforderlich, die WebView2 Visual-Hosting-APIs zu verwenden.

Um das Hosten von Windows zu Visual zu aktivieren, muss die Umgebungsvariable COREWEBVIEW2_FORCED_HOSTING_MODE auf den Wert COREWEBVIEW2_HOSTING_MODE_WINDOW_TO_VISUAL festgelegt werden, bevor WebView2 initialisiert wird.

Beim Hosten von Windows-zu-Visual und beim Hosten von Visuals ist ein Visual eine einfache grafische Einheit, die zum Erstellen grafischer Umgebungen unter Windows verwendet werden kann. Die Windows-Grafik-APIs, die diese Funktionalität verfügbar machen und für WebView2 relevant sind, sind DirectComposition und Windows.UI.Composition. Das "Visual" in "Visuelles Hosting" kann eine beliebige von IDCompositionVisual, IDCompositionTargetoder Windows.UI.Composition.Visualsein. Dabei handelt es sich um Visuals, die über die DirectComposition APIs und Windows.UI.Composition verfügbar gemacht werden. (Das Windows-zu-Visual-Hosting verwendet IDCompositionVisual speziell.) Siehe:

Vorteile

  • Verschiedene Apps, die einen WebView2-Benutzerdatenordner gemeinsam nutzen, können unterschiedliche DPI-Werte aufweisen.

  • Verschiedene Apps, die einen WebView2-Benutzerdatenordner gemeinsam nutzen, können unterschiedliche Integritätsebenen aufweisen.

  • Verschiedene Apps, die einen WebView2-Benutzerdatenordner gemeinsam nutzen, verursachen nicht dazu, dass sie aufgrund angefügter Fenstereingabewarteschlangen einander hängen bleiben.

  • Beim Hosten einer WebView2 in einem VSTO-Add-In führt eine Änderung der Monitorskala nicht dazu, dass die App hängen bleibt. Weitere Informationen finden Sie unter VSTO-Add-Ins in der Übersicht über die Entwicklung von Office-Lösungen (VSTO).

Nachteile

Durch das Aktivieren des Hostingmodus von Windows in Visual wird die Unterstützung für die Windows Shell-Handschrift in WebView2 entfernt.

Siehe auch:

APIs für das Hosten von Windows zu Visual

Eine Liste der APIs, die beim Konfigurieren von WebView2 Window to Visual Hosting (oder für Windows-Hosting) verwendet werden können, finden Sie unter Rendern von WebView2 in Nicht-Framework-Apps in Übersicht über WebView2-Features und -APIs.

Visuelles Hosting: Für eine präzisere Steuerung des Layouts

Wenn Sie das visuelle Hosting verwenden, empfängt Ihre Host-App räumliche Eingaben (z. B. Maus- oder Toucheingaben) vom Benutzer und leitet diese Eingabe an das WebView2-Steuerelement weiter. Das hosten von Visuals erfordert, dass die App die gleiche Fensterverwaltung wie das Windowed-Hosting durchführen muss, hat jedoch zusätzliche Anforderungen an die Fensterverwaltung in Bezug auf:

  • Skalieren des Inhalts.
  • Weiterleiten räumlicher Eingaben (z. B. Maus, Toucheingabe oder Stift).

Anforderungen für die Skalierung des Inhalts

Pro kompositionsbasiertem Rendering ist ein WebView2-Steuerelement Teil einer visuellen Struktur. Daher wird es standardmäßig auf einer Skala gerendert, die auf den Skalen aller seiner Vorgängervisuals basiert. Wenn beispielsweise das Vorgängervisual eines WebView2-Objekts 2x skaliert (vergrößert) wird, wird der Inhalt von WebView2 ebenfalls im 2-fachen Maßstab gerendert. Wenn das übergeordnete Visual von WebView2 2x skaliert wird und das übergeordnete Element dieses Visuals ebenfalls 2x skaliert wird, wird webView2 4x skaliert. Da webView2 jedoch keine eigenen Inhalte skaliert, sind sie unscharf.

Um dies zu beheben, kann die App die standardmäßige visuelle Skalierung von WebView2 rückgängig machen und stattdessen die APIs für die Rasterungsskalierung verwenden, um die beabsichtigte visuelle Skalierung anzuwenden. Dies führt dazu, dass der Inhalt von WebView2 im richtigen Maßstab gerendert wird. Weitere Informationen finden Sie unter Rasterungsskalierung in Übersicht über WebView2-Features und -APIs.

Anforderungen für das Routing räumlicher Eingaben (Maus, Toucheingabe oder Stift)

Wenn Ihre WebView2-App visuelles Hosting verwendet, werden keine räumlichen Eingaben (z. B. Maus, Toucheingabe oder Stift) an das WebView2-Steuerelement gesendet, es sei denn, die App verwaltet diese Eingaben. Die Eingabe wird an die der App HWNDgesendet, und die App ist für die Weiterleitung dieser räumlichen Eingabe an WebView2 verantwortlich, wenn sich die Position der Eingabe über WebView2 befindet.

Die App ist auch für alle erforderlichen Transformationen von Eingabepositionen in den Koordinatenraum von WebView2 verantwortlich.

Siehe auch:

Vor- und Nachteile

Visuelles Hosting ermöglicht (und erfordert) eine präzisere Steuerung des Layouts. Bei diesem Ansatz benötigt die App eine spezifische Behandlung von Fensterverwaltungs- und Rendering-APIs.

Wenn beispielsweise eine Benutzeraktion bewirkt, dass die Visuelle Struktur von WebView2 skaliert wird, muss die App die WebView2-Skalierung anpassen, damit sie relativ zu den übergeordneten Visuals korrekt gerendert wird.

APIs für visuelles Hosting

Eine Liste der APIs, die beim Konfigurieren von WebView2 in einer visuellen Hostingumgebung verwendet werden können, finden Sie unter Rendern von WebView2 mithilfe von Composition in Übersicht über WebView2-Features und -APIs.

Kompatibilität und Einschränkungen

Zu den wichtigsten Kompatibilitätseinschränkungen gehören das Betriebssystem und das Rendering in Framework- und Nicht-Framework-Apps.

Betriebssysteme

Alle Hostingmodi werden überall dort unterstützt, wo WebView2 unterstützt wird. d. h. Windows 10 und höher sowie bestimmte Windows Server-Versionen. Windows 7, 8 und 8.1 werden nicht mehr unterstützt. Windows 7 und Windows 8 nur Windows-Hosting unterstützen, nicht das visuelle Hosting.

Siehe auch:

Frameworkeinschränkungen

CreateCoreWebView2CompositionControllerunterstützt keine WinAppSDK-Visuals; d. h. visuelle Objekte im Namespace, die unter Verbessern der Benutzeroberfläche mit der visuellen Ebene (Windows App SDK/WinUI 3) beschrieben werden.Microsoft.UI.Composition

Siehe auch

Äußerlich: