Spekulatives Laden in WebView

Die Navigationslatenz ist ein wichtiger Messwert für die Nutzerfreundlichkeit. Um Entwicklern zu helfen, diese Latenz zu verringern, bietet WebView APIs für das spekulative Laden und die Verbindungsoptimierung. So kann Ihre App Inhalte abrufen oder rendern, bevor der Nutzer explizit darauf zugreift.

WebView unterstützt drei primäre Arten des spekulativen Ladens: Preconnect, Prefetch und Prerender. Außerdem werden QUIC-Hinweise zur Optimierung der Protokollvereinbarung unterstützt.

Wenn Sie eine spekulative Ladestrategie implementieren, können Sie Folgendes erreichen:

• Latenz beim Laden von Webinhalten deutlich reduzieren:Verlegen Sie den Netzwerkstartzeitpunkt in den frühen App-Lebenszyklus und bevorzugen Sie schnellere Protokolle wie HTTP/3.
• Höhere Erfolgsraten bei der Navigation:Durch das Vorwärmen des Netzwerks und des Cache ist es weniger wahrscheinlich, dass Navigationen aufgrund vorübergehender Netzwerkprobleme fehlschlagen.
• Bessere wahrgenommene Reaktionsfähigkeit:Insbesondere durch das Pre-Rendering werden sofortige Übergänge ermöglicht, wodurch sich die App deutlich schneller anfühlt.

Strategie für spekulatives Laden auswählen

Der Hauptunterschied zwischen diesen Strategien liegt in ihrem Umfang: Die APIs für Preconnect- und QUIC-Hinweise sind ursprungsbasiert, d. h., sie erfordern nur die Zieldomain. Prefetch- und Prerender-APIs sind URL-basiert. Das bedeutet, dass sie den genauen Pfad der Webseite erfordern.

Da Preconnect- und QUIC-Hinweise auf der Ursprungsebene funktionieren, können Sie sie aufrufen, bevor Sie wissen, zu welchen Inhalten oder Seiten der Nutzer navigieren wird.

In der folgenden Tabelle werden diese drei Strategien verglichen, damit Sie die richtige für Ihren Anwendungsfall auswählen können:

Vorverbindungen zu Ursprüngen herstellen

Durch das Vorverbinden werden zukünftige Ladevorgänge beschleunigt, da DNS-Lookups und TCP/TLS- oder QUIC-Handshakes für einen bestimmten Ursprung präventiv ausgeführt werden.

Im Gegensatz zu Prefetch und Prerender, für die eine genaue Ziel-URL erforderlich ist, basiert Preconnect ausschließlich auf dem Ursprung. So können Sie Preconnect aufrufen, bevor Sie die genaue URL kennen. Hinweise dazu, wann Sie die Funktion aufrufen sollten, finden Sie im Tipp unter Implementierung.

Diese ressourcenarme Strategie auf Profilebene reduziert die anfängliche Latenz für alle WebView-Freigaben dieses Profils, sofern die Herkunft noch nicht besucht wurde. Die Verbindung bleibt etwa 30 Sekunden lang offen. Das ist von Vorteil für alle nachfolgenden HTTP-Anfragen, Navigationsvorgänge oder untergeordneten Ressourcen, da der Handshake-Overhead entfällt. Das DNS-Lookup-Ergebnis wird länger als die Verbindung im Cache gespeichert. Daher kann bei späteren Anfragen an den Ursprung der Lookup auch nach dem Schließen der Verbindung übersprungen werden.

Implementierung

Rufen Sie preconnect(String url) für eine Profile-Instanz auf, um eine Vorabverbindung herzustellen. Diese API muss im UI-Thread aufgerufen werden und erfordert die Unterstützung von WebViewFeature.PRECONNECT.

Die API arbeitet mit dem Ursprung, aber zur Vereinfachung kann eine vollständige URL angegeben werden (z. B. https://www.example.com/index.html). Diese wird automatisch als Aufruf des Ursprungs behandelt (z. B. https://www.example.com). Es können mehrere Ursprünge verbunden werden, indem diese API mehrmals aufgerufen wird.

// Must be called on the @UiThread
if (WebViewFeature.isFeatureSupported(WebViewFeature.PRECONNECT)) {
    profile.preconnect("https://www.example.com/index.html")
    // This initiates a connection to the origin https://www.example.com
}

// Must be called on the @UiThread
if (WebViewFeature.isFeatureSupported(WebViewFeature.PRECONNECT)) {
    profile.preconnect("https://www.example.com/index.html");
    // This initiates a connection to the origin https://www.example.com
  }

QUIC-Protokollunterstützung mit QUIC-Hinweisen angeben

HTTP/3 (das über das QUIC-Transportprotokoll ausgeführt wird) bietet im Vergleich zu HTTP/2 erhebliche Verbesserungen bei der Latenz, darunter 0-RTT-Handshakes, eine verbesserte Verbindungsstabilität und die Beseitigung von Head-of-Line-Blockierungen bei Paketverlust.

Standardmäßig versucht WebView nur dann eine QUIC-Verbindung, wenn es einen Hinweis darauf gibt, dass der Ursprung QUIC unterstützt, z. B. durch einen Alt-Svc-Header oder einen DNS-HTTPS-Eintrag aus einer früheren Interaktion. Ohne dieses Vorwissen verwendet WebView für die erste Verbindung HTTP/2 oder HTTP/1.1.

Beim Aufrufen von addQuicHints werden diese Informationen zur Protokollunterstützung vorab ausgefüllt. So kann WebView bei der ersten Verbindung zu den angegebenen Ursprüngen sofort QUIC verwenden.

Vorabverbindung mit QUIC-Hinweisen

Sowohl Preconnect- als auch QUIC-Hinweise sind Optimierungen auf Ursprungsebene für eine Profile. Sie haben jedoch unterschiedliche, sich ergänzende Funktionen:

• preconnect:Öffnet und unterhält aktiv eine Netzwerkverbindung (DNS-Lookup und TCP/TLS- oder QUIC-Handshake) für etwa 30 Sekunden. Da aktive Netzwerkverbindungen offen gehalten werden, werden Geräte- und Netzwerkressourcen verbraucht. Daher sollte diese Option nur für Zielursprünge mit hoher Wahrscheinlichkeit verwendet werden.
• addQuicHints:Es entsteht kein unmittelbarer Netzwerkverkehr. Es aktualisiert die In-Memory-Serverattribute des Profile-Netzwerkstacks, um die Unterstützung des Aufzeichnungsprotokolls zu erfassen. Da der Overhead vernachlässigbar ist, können Sie QUIC-Hinweise beim Start der App für alle bekannten HTTP/3-fähigen Ursprünge konfigurieren.

Für eine optimale Leistung rufen Sie addQuicHints vor preconnect, prefetchUrlAsync oder loadUrl auf. So wird sichergestellt, dass bei allen nachfolgenden Preconnects oder Seitenanfragen von Anfang an HTTP/3 ausgehandelt wird.

Implementierung

Rufen Sie addQuicHints(Set<String> urls) für eine Profile-Instanz auf, um QUIC-Hinweise zu konfigurieren. Sie müssen diese API im UI-Thread aufrufen und prüfen, ob WebView die WebViewFeature.ADD_QUIC_HINTS_V1-Funktion unterstützt.

Wie preconnect wird addQuicHints für Ursprünge ausgeführt. Es können jedoch vollständige URLs angegeben werden (z. B. https://www.example.com/index.html), die automatisch auf ihren Ursprung (https://www.example.com) normalisiert werden.

Die Methode ist additiv: Wenn sie mehrmals aufgerufen wird, werden die angegebenen Ursprünge über die Profile hinweg zusammengeführt.

// Must be called on the @UiThread
@OptIn(Profile.ExperimentalAddQuicHints::class)
if (WebViewFeature.isFeatureSupported(WebViewFeature.ADD_QUIC_HINTS_V1)) {
    val quicOrigins = setOf(
        "https://www.example.com",
        "https://api.example.com"
    )
    profile.addQuicHints(quicOrigins)
    // WebView now prioritizes HTTP/3 over QUIC for connections to these origins
}

// Must be called on the @UiThread
// Requires @Profile.ExperimentalAddQuicHints annotation or suppression
if (WebViewFeature.isFeatureSupported(WebViewFeature.ADD_QUIC_HINTS_V1)) {
    Set<String> quicOrigins = new HashSet<>(Arrays.asList(
        "https://www.example.com",
        "https://api.example.com"
    ));
    profile.addQuicHints(quicOrigins);
    // WebView now prioritizes HTTP/3 over QUIC for connections to these origins
}

Gängige Konfiguration: PrefetchParameters und PrerenderParameters

Sowohl bei Prefetch als auch bei Prerender wird PrefetchParameters oder PrerenderParameters verwendet, um die Anfrage anzupassen. Mit diesen Klassen können Sie zusätzliche Header und Hinweise für den URL-Abgleich bereitstellen, z. B. No-Vary-Search-Konfigurationen.

// Isolated configuration specifically for Cache-Level Prefetching
val prefetchParams = PrefetchParameters.Builder()
    .addAdditionalHeader("X-Custom-Client", "Android-App-V2")
    .setExpectedNoVarySearchHeader(
        NoVarySearchHeader.varyExcept(true, listOf("session_id", "click_ref"))
    )
    .build()

PrefetchParameters prefetchParams = new PrefetchParameters.Builder()
    .addAdditionalHeader("X-Custom-Header", "value")
    /**
     * Hint to ignore specific query parameters during cache matching.
     * This allows the cache to match even if the tracking_id differs.
     */
    .setExpectedNoVarySearchHeader(
        NoVarySearchHeader.varyExcept(true, Arrays.asList("tracking_id"))
    )
    /**
     * Determines if Client Hints are sent.
     * NOTE: This is ignored for Prerendering API requests, which default to
     * the WebView's WebSettings.getJavaScriptEnabled() value.
     */
    .setJavaScriptEnabled(true)
    .build();

Inhalte vorab abrufen

Beim Prefetching wird die primäre HTML-Ressource einer URL heruntergeladen und im Netzwerkcache des Profils gespeichert. In WebView fungiert ein Profile als Container für Browserdaten, einschließlich Cookies, HTTP-Cache und Service Workern. Da Prefetch ein Vorgang auf Profilebene ist, kann jede WebView, die mit diesem Profil verknüpft ist, die im Cache gespeicherte Antwort nutzen.

Implementierung

Rufen Sie prefetchUrlAsync() für eine Profile-Instanz auf, um einen Prefetch zu starten. Dieser Vorgang unterstützt nur das HTTPS-Schema.

profile.prefetchUrlAsync(
    url,
    prefetchParams,
    cancellationSignal,
    executor,
    object : WebViewOutcomeReceiver<PrefetchResult, PrefetchException> {
        override fun onResult(result: PrefetchResult) {
            if (result.wasDuplicate()) {
                // URL and No-Vary-Search permutations already exist in the cache layer
            } else {
                // The HTML payload has been successfully secured in the HTTP cache
            }
        }

        override fun onError(error: PrefetchException) {
            when (error) {
                is PrefetchNetworkException -> {
                    // Isolates network layer or server-side HTTP anomalies
                    val code = error.httpStatusCode
                    // Facilitates rapid diagnosis of 4xx or 5xx server responses
                }
                else -> {
                    // Catches generalized execution failures and system constraints
                }
            }
        }
    }
)

profile.prefetchUrlAsync(
    url,
    prefetchParams,
    cancellationSignal,
    executor,
    new WebViewOutcomeReceiver<PrefetchResult, PrefetchException>() {
        @Override
        public void onResult(PrefetchResult result) {
            if (result.wasDuplicate()) {
                // URL and No-Vary-Search permutations already exist in the cache layer
            } else {
                // The HTML payload has been successfully secured in the HTTP cache
            }
        }

        @Override
        public void onError(PrefetchException error) {
            if (error instanceof PrefetchNetworkException) {
                // Isolates network layer or server-side HTTP anomalies
                int code = ((PrefetchNetworkException) error).httpStatusCode;
                // Facilitates rapid diagnosis of 4xx or 5xx server responses
            } else {
                // Catches generalized execution failures and system constraints
            }
        }
    }
);

Lebenszyklus von Abfangvorgängen

Die WebView-Prefetch-Anfrage ändert, wann und wie der shouldInterceptRequest()-Callback ausgelöst wird. Da dies sich direkt darauf auswirkt, ob Ihre vorab abgerufenen Inhalte erfolgreich verwendet werden, ist es wichtig, den zweistufigen Lebenszyklus zu verstehen:

1. Die spekulative Phase (Prefetch-Anfrage)

Wenn prefetchUrlAsync() aufgerufen wird, lädt WebView die primäre HTML-Ressource im Hintergrund herunter. shouldInterceptRequest() wird für diese Hintergrundanfrage vollständig übersprungen. Benutzerdefinierte Logik, Autorisierungstokens oder Header-Injections, die normalerweise in Ihrem Interceptor verarbeitet werden, werden nicht auf die vorgeholte HTML-Ressource angewendet.

2. Die Navigationsphase (Nutzeraktivierung)

Wenn die App explizit zur URL navigiert (z. B. mit WebViewCompat.navigate oder loadUrl) oder der Nutzer auf einen entsprechenden Link klickt, ermittelt WebView, ob der vorab abgerufene Cache verwendet werden kann:

• Haupt-HTML-Auswertung:WebView löst shouldInterceptRequest() für das Haupt-HTML aus. Damit die Seite erfolgreich aus dem Prefetch-Cache bereitgestellt werden kann, muss Ihr Interceptor null zurückgeben. Wenn Sie ein benutzerdefiniertes WebResourceResponse zurückgeben, berücksichtigt WebView Ihren Interceptor und umgeht den Prefetch-Cache vollständig.

• Auswertung von untergeordneten Ressourcen:Nachdem das vorgeholte HTML für die Verwendung freigegeben wurde, wird shouldInterceptRequest() normalerweise für alle nachfolgenden untergeordneten Ressourcen (z. B. Bilder, Skripts und CSS) ausgelöst, die zum Rendern der Seite erforderlich sind.

Wichtige Verhaltensweisen

Die folgenden Betriebsmerkmale und Eignungsprüfungen regeln, wie WebView Prefetch-Anfragen initiiert und verwaltet:

• Threadsicherheit:Anfragen können von jedem Thread aus initiiert werden.
• Voraussetzungen:Bevor ein Abruf gestartet wird, prüft WebView, ob die Anfrage sicher und kontextuell angemessen ist. Dazu werden die folgenden Punkte geprüft:
  • Vorhandene Cookies:Zum Schutz der Privatsphäre von Nutzern und zur Vermeidung von CSRF-ähnlichen Nebeneffekten kann WebView das Prefetching überspringen, wenn für die Anfrage bestimmte authentifizierte Cookies erforderlich sind, die eine Zustandsänderung auf dem Server auslösen könnten.
  • Vorhandensein von Service Workern:Wenn ein Service Worker bereits den Bereich der URL steuert, kann WebView den Fetch-Handler des Service Workers verwenden, anstatt ein standardmäßiges Netzwerk-Prefetch zu starten.
  • Proxyverfügbarkeit:WebView prüft, ob der aktuelle Netzwerkpfad (einschließlich aller konfigurierten Proxys) stabil ist, um zu vermeiden, dass spekulative Anfragen bei komplexen Netzwerkkonfigurationen fehlschlagen.
• Wenn ein Prefetch nicht gestartet wird (auch bei gültigen Parametern), liegt das häufig daran, dass WebView festgestellt hat, dass eine Hintergrundanfrage die aktuelle Sitzung oder den Sicherheitsstatus des Nutzers beeinträchtigen könnte.
• Abbrechen:Verwenden Sie CancellationSignal, um eine laufende Anfrage zu beenden und zu verhindern, dass sie im Cache gespeichert wird.

Seiten vorab rendern

Beim Prerendering werden verborgene „Webinhalte“ erstellt, um eine Seite vollständig im Hintergrund zu rendern, einschließlich der Ausführung von Skripten und des Abrufs von untergeordneten Ressourcen. Das Vorrendern basiert auf derselben zugrunde liegenden Infrastruktur wie das Prefetching. Wenn eine App einen Prerender-Vorgang initiiert, führt WebView zuerst einen Prefetch der Antwort durch, um die Prerender-Navigation zu ermöglichen. So wird unnötige Netzwerkaktivität vermieden.

Implementierung

Das Vorrendern ist ein Vorgang auf WebView-Instanzebene. Rufen Sie prerenderUrlAsync() mit WebViewCompat über den UI-Thread auf.

WebViewCompat.prerenderUrlAsync(
    webView,
    url,
    cancellationSignal,
    executor,
    params,
    object : PrerenderOperationCallback {
        override fun onPrerenderActivated() {
            // Called when the user navigates to the URL and the hidden page is swapped in
        }

        override fun onError(exception: Throwable) {
            // exception is an instance of PrerenderException
            // Handle prerender failure (for example, memory pressure or disallowed JavaScript APIs)
        }
    }
)

WebViewCompat.prerenderUrlAsync(webView, url, cancellationSignal, executor, params, new PrerenderOperationCallback() {
    @Override
    public void onPrerenderActivated() {
        // Called when the user navigates to the URL and the hidden page is swapped in.
    }

    @Override
    public void onError(@NonNull Throwable exception) {
        // Handle prerender failure (for example, resource constraints or disallowed APIs).
    }
});

Sowohl Prefetch als auch Prerender sind vollständig asynchron. prefetchUrlAsync() kann von jedem Thread aus aufgerufen werden, während prerenderUrlAsync() vom UI-Thread aus initiiert werden muss.

Technische Einschränkungen

Um die sofortige Navigation mit der Systemleistung in Einklang zu bringen, erzwingt WebView die folgenden Laufzeitbeschränkungen:

• Arbeitsspeicherbelastung:WebView bricht das Vorrendern von URLs ab, wenn auf dem Gerät wenig Arbeitsspeicher verfügbar ist.
• Nicht zulässige APIs:Wenn JavaScript versucht, im Hintergrund auf bestimmte APIs zuzugreifen (z. B. für die Audiowiedergabe oder Benachrichtigungen), wird das Prerendering sofort beendet.
• Instanzlimit:Die Anzahl der aktiven vorgerenderten URLs pro WebView ist begrenzt.

URL-Abgleich und No-Vary-Search (NVS)

WebView erfordert einen zuverlässigen Abgleichsalgorithmus, damit eine vorab geladene Ressource nur für die beabsichtigte Navigation bereitgestellt wird.

Genaue Übereinstimmung im Vergleich zu NVS-Abgleich

Standardmäßig ist für das Vorabrufen und Vorabrendern eine genaue URL-Übereinstimmung erforderlich. Wenn die aufgerufene URL mit der vorab geladenen URL identisch ist, wird sie sofort aus dem Cache bereitgestellt. Wenn sich die Abfrageparameter unterscheiden, verwendet WebView die folgenden No-Vary-Search-Regeln (NVS):

• Der Hinweis:Entwickler geben bei der Initiierung einen setExpectedNoVarySearchHeader()-Hinweis an. Wenn die aufgerufene URL mit der Anfrage-URL abzüglich der angegebenen Parameter übereinstimmt, wird WebView kurz blockiert, um auf die tatsächlichen Header des Servers zu warten.
• Serverheader:Der NVS-Antwortheader vom Server ist die maßgebliche Quelle. Wenn der Server bestätigt, dass Abfrageunterschiede ignoriert werden sollen, wird der Abgleich aus dem Cache bereitgestellt. Andernfalls wird ein Kaltstart des Netzwerks in WebView durchgeführt.

No-Vary-Search (NVS) ist für die erweiterte Nutzung vorgesehen und die meisten Entwickler benötigen es möglicherweise nicht, da sie sowohl für Prefetch als auch für die Navigation dieselbe URL übergeben (WebViewCompat.navigate oder loadUrl). Diese Anleitung ist nur erforderlich, wenn es Unterschiede bei den Suchparametern zwischen der Prefetch-URL und der aufgerufenen URL gibt.

Globale Konfiguration

Sie können das Verhalten beim spekulativen Laden auf Profilebene anpassen, indem Sie PrefetchCache-Limits und die maximale Anzahl von Vorrenderings konfigurieren. Sie können benutzerdefinierte Prefetch-Limits auch auf die Systemstandardwerte zurücksetzen:

// Configure prefetch cache limits
profile.prefetchCache.setMaxPrefetches(10)
profile.prefetchCache.setPrefetchTtlSeconds(60)

// Reset to system defaults when needed
profile.prefetchCache.clearMaxPrefetches()

// Configure maximum active prerenders
profile.setMaxPrerenders(2)

// Configure prefetch cache limits
PrefetchCache prefetchCache = profile.getPrefetchCache();
prefetchCache.setMaxPrefetches(10);
prefetchCache.setPrefetchTtlSeconds(60);

// Reset to system defaults when needed
prefetchCache.clearMaxPrefetches();

// Configure maximum active prerenders
profile.setMaxPrerenders(2);

Fehlerbehandlung und Ausnahmen

Bei spekulativen Vorgängen werden Ergebnisse mit OutcomeReceiverCompat oder PrerenderOperationCallback gemeldet.

Primäre Ausnahmen

Wenn ein spekulativer Ladevorgang fehlschlägt, meldet Ihr Fehler-Handler einen der folgenden primären Ausnahmetypen, um Ihnen bei der Diagnose bestimmter Fehlerszenarien zu helfen:

• PrefetchException:Die Basisklasse für alle asynchronen Prefetch-Fehler.
• PrefetchNetworkException:Weist auf einen Fehler auf Netzwerk- oder Serverebene hin. Sie kann ein httpStatusCode-Feld (z. B. 404 oder 503) enthalten, um serverseitige Probleme zu diagnostizieren.
• PrerenderException:Die Basisklasse für alle Vorrender-bezogenen Fehler, z. B. Fehler aufgrund von Speichermangel oder der Verwendung nicht zulässiger APIs (z. B. Audiowiedergabe) im Hintergrund.

Optimierungsstrategien

Mit den folgenden Empfehlungen können Sie die Vorteile des spekulativen Ladens maximieren und gleichzeitig Systemressourcen schonen:

• Frühzeitig initiieren:Beginnen Sie mit dem Prefetching beim App-Start oder sobald ein Navigationsziel wahrscheinlich ist.
• QUIC-Hinweise mit dem Vorwärmen von Verbindungen kombinieren:Rufen Sie addQuicHints() auf, bevor Sie preconnect(), prefetchUrlAsync() oder Standardnavigationsvorgänge starten, damit WebView versucht, Verbindungen über HTTP/3 herzustellen.
• Integrierte Strategie:Wenn Sie eine URL, die sich bereits im Prefetch-Cache befindet, vorrendern, wird die Vorrender-Navigation aus diesem Cache bereitgestellt. So werden redundante Netzwerkanfragen vermieden.
• Kontingente im Blick behalten:Das Prerendering ist ressourcenintensiv. Verwenden Sie Prefetching für mehrere wahrscheinliche Kandidaten und reservieren Sie Prerendering für die wahrscheinlichste Navigation.
• Unterstützung von Schemas:Alle URLs müssen das obligatorische HTTPS-Schema verwenden. Ungültige Schemas oder Nulleingaben lösen ein synchrones IllegalArgumentException aus.

Zusätzliche Ressourcen

Weitere Informationen zum Debuggen von Web-Apps, zum Optimieren der WebView-Startleistung und zum Behandeln des Beendens von Renderer-Prozessen finden Sie in den folgenden Ressourcen:

• Verbesserte Seitennavigation mit der Methode WebViewCompat.navigate
• Web-Apps debuggen
• WebView-Start optimieren
• Beenden des WebView-Rendererprozesses verarbeiten