Ich habe versucht, einen Disc-basierten Cache für WebView zu implementieren, aber mit nur teilweise Erfolg versuche ich besonders, die .js javascript externen Dateien zwischenzuspeichern, die das Laden von JavaScript-Webseiten sehr verlangsamen.
In der Oracle-Dokumentation heißt es: "Wenn Sie mit der WebView-Komponente arbeiten, sollten Sie daran denken, dass sie den standardmäßigen In-Memory-Cache besitzt. Dies bedeutet, dass alle zwischengespeicherten Inhalte verloren gehen, sobald die Anwendung, die die WebView-Komponente enthält, geschlossen wird. Entwickler können jedoch Cache auf Anwendungsebene mithilfe der java.net.ResponseCache-Klasse implementieren. "
Aber das ist nicht der Fall. Ich implementierte einen In-Memory-Cache mit der java.net.ResponseCache-Klasse, aber es wird sehr selten von WebView verwendet - von Zeit zu Zeit speichert und ruft favicon.png aus dem Cache - keine Leistungssteigerung.
Ich habe bestätigt, indem ich den Netto-Datenverkehr analysiert habe, den WebView nicht zwischenspeichert, und bestätige damit, was in JDK-8014501 angegeben ist: "Beim Navigieren mit der JavaFX WebView Komponente javafx.scene.web.WebView wurde festgestellt, dass jede Anforderung jedes Mal alle Ressourcen vom Server abruft, auch wenn frühere Aktivitäten gerade die Ressourcen abgerufen haben. Dieses Verhalten wurde durch Erfassen und Analysieren des Netzwerkverkehrs verifiziert. Der Leistungseinfluss ist beträchtlich. "
Nichts scheint aus JDK-8014501 herausgekommen zu sein, also habe ich dann einen Cache-Handler geschrieben, der "URL.setURLStreamHandlerFactory" verwendet, um alle URLC-Verbindungen zum Standard-Sun-Handler abzufangen. Ich hatte Erfolg damit und war in der Lage, .js Javascript-Dateien zu cachen und die Leistung signifikant zu erhöhen, aber es gab Bugs, die einige Websites, insbesondere die E-Mails von Outlook, behandelten.
Bei der Untersuchung meines Codes wurde zum Beispiel festgestellt, dass der URLLoader-Code setUsesCaches (false) mit den folgenden Kommentaren im Code gesetzt hat (in Zeile 279 von URLLoader.java im aktuellen 1.8.0_66-Code):
// Da WebKit über einen eigenen Cache verfügt, verwenden Sie kein
// irgendwelche URLConnection-Caches, selbst wenn jemand sie installiert.
// Als Nebeneffekt behebt dies das Problem von WebPane nicht
// funktioniert gut mit dem Plug-in-Cache, der einer von
war
// die Ursachen für RT-11880.
Kann jemand da draußen bitte einen Blick darauf werfen, was wirklich los ist?
Vielen Dank im Voraus für eine Rückmeldung,
Ich habe mit dem nicht-cachenden WebView gearbeitet, indem ich meine eigenen Klassen implementiert habe, die von HttpUrlConnection und HttpsUrlConnection abgeleitet wurden und meine eigene Implementierung von URLStreamHandlerFactory verwenden.
Grundsätzlich abfangen ich alle ausgehenden http und https Anfragen, überprüfen, ob ich die Daten in meinem Cache habe. Wenn nicht, lade ich die Daten von der ursprünglichen Ressource und speichere sie in einem Cache-Verzeichnis. Wenn ich die Daten bereits habe, liefere ich sie aus meinem Cache.
Ich habe Cache-Header usw. nicht implementiert, weil dies für meinen Anwendungsfall nicht notwendig war.
Es gibt zu viel Code, um hier zu posten, aber wenn Sie interessiert sind, können Sie sich den Code unter mapjfx ansehen Überprüfen Sie insbesondere die Klassen im Paket com.sothawo.mapjfx.offline .
Diese Lösung lässt das WebView die Caching-Implementierung überhaupt nicht bewusst.