Introduction aux méthodes d'optimisation du chargement de WebView

Cet article vous apporte une introduction à la méthode d'optimisation du chargement de WebView. Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer. J'espère qu'il vous sera utile.

Optimisation du chargement de WebView

Lorsque la fréquence d'utilisation de WebView devient fréquente, l'optimisation de tous ses aspects devient de plus en plus importante. Ce que vous pouvez savoir, c'est qu'à chaque fois que nous chargerons une page H5, il y aura beaucoup de demandes. En plus de la requête de l'URL principale HTML elle-même, les fichiers JS, CSS, de polices et les images référencés en externe par le HTML sont tous des requêtes HTTP indépendantes, bien que les requêtes soient simultanées, lorsque le nombre total de pages Web atteint un certain niveau. , plus Le temps d'analyse et de rendu du navigateur, ainsi que le temps de chargement global du Web, deviennent très longs. Plus il y a de fichiers demandés en même temps, plus le trafic sera consommé. Ensuite, l'optimisation du chargement devient très importante. Je n'ai aucune autre expérience dans ce domaine. Il y a en gros trois aspects :
L'un est la question de la localisation des ressources
Tout d'abord, il est clair qu'avec le Due to actuel. Dans des conditions de réseau, la vitesse d'obtention des ressources du serveur via le réseau est bien plus lente que leur lecture locale. Parler de diverses stratégies d'optimisation ignore en fait le fait que « nécessiter un chargement » est la plus grande pierre d'achoppement à l'amélioration de la vitesse. Notre première idée est donc de localiser certaines ressources plus lourdes telles que js, css, images et même HTML lui-même. Chaque fois que ces ressources sont chargées, elles sont lues et chargées localement. Elles peuvent être simplement mémorisées comme "save · Get ​​· Update". ".
1. "Enregistrer" - ​​regroupez les ressources lourdes ci-dessus dans un fichier apk et récupérez-le depuis le local à chaque fois que le fichier correspondant est chargé. Vous ne pouvez pas non plus le conditionner, le télécharger et le stocker dynamiquement lors du premier chargement et à des intervalles ultérieurs, et stocker tous les fichiers de ressources dans le répertoire des ressources Android
2 "Get" - Réécrire la réponse WebResource de WebViewClient The ShouldInterceptRequest(WebView ; view, WebResourceRequest request) intercepte la requête correspondante via une certaine méthode d'identification (telle qu'une expression régulière), lit la ressource correspondante à partir du local et la renvoie
3. les mises à jour des ressources locales régulièrement ou sous forme de notifications API pour garantir que les ressources locales sont à jour et disponibles.
La seconde est la question de la mise en cache
Si vous n'adoptez pas ou n'adoptez pas entièrement la première idée de localisation des ressources, alors votre cache WebView doit être activé (bien que cette idée soit différente de la première idée) Il y a chevauchements).

WebSettings settings = webView.getSettings(); 
settings.setAppCacheEnabled(true); 
settings.setDatabaseEnabled(true); 
settings.setDomStorageEnabled(true);//开启DOM缓存 
settings.setCacheMode(WebSettings.LOAD_DEFAULT);

Lorsque le réseau est normal, la stratégie de mise en cache par défaut est adoptée et le cache est chargé lorsque le cache peut être obtenu et n'a pas expiré. Sinon, les ressources sont obtenues via le réseau pour réduire. le nombre de requêtes réseau pour la page.
Il convient de mentionner ici que lorsque nous utilisons souvent WebView pour afficher des pages dans des applications, nous ne voulons pas que l'utilisateur ait l'impression qu'il visite une page Web. Parce que s’il y a trop de pages Web dans notre application et que nous donnons aux utilisateurs le sentiment qu’ils visitent des pages Web, notre application perdra son sens. (Je veux dire, pourquoi les utilisateurs n’utilisent-ils pas directement le navigateur ?)
Donc, à l’heure actuelle, la question de la mise en cache hors ligne mérite notre attention. Nous devons permettre aux utilisateurs de continuer à utiliser notre application même s'il n'y a pas d'Internet, au lieu d'être confrontés à une page qui correspond à l'erreur réseau dans le navigateur, même si les opérations qu'ils peuvent effectuer sont très limitées.
Mon idée ici est que, sous réserve d'activer la mise en cache, WebView détecte les changements de réseau lors du chargement de la page. Si le réseau de l'utilisateur est soudainement déconnecté lors du chargement de la page, nous devrions modifier la stratégie de mise en cache de WebView.

ConnectivityManager connectivityManager = (ConnectivityManager)getSystemService(Context.CONNECTIVITY_SERVICE); 
NetworkInfo networkInfo = connectivityManager.getActiveNetworkInfo(); 
if(networkInfo.isAvailable()) { 
settings.setCacheMode(WebSettings.LOAD_DEFAULT);//网络正常时使用默认缓存策略 
} else { 
settings.setCacheMode(WebSettings.LOAD_CACHE_ONLY);//网络不可用时只使用缓存 
}

Puisqu'il y a un cache, il doit y avoir un contrôle du cache. De la même manière, nous devons également établir un mécanisme de contrôle du cache pour vider ou mettre à jour le cache régulièrement ou en acceptant les notifications du serveur.
La troisième consiste à retarder le chargement et l'exécution de js
Dans WebView, le rappel de onPageFinished() signifie l'achèvement du chargement de la page. Cependant, cette méthode ne sera déclenchée qu'après l'exécution du script JavScript. Si la page que nous souhaitons charger utilise JQuery, elle ne sera rendue que lorsque l'objet DOM aura été traité et $(document).ready(function() {}. ) a été exécuté et affiche la page. C'est inacceptable, nous devons donc charger paresseux Js. Bien sûr, cette partie est le travail du front-end Web.

Cet article est terminé ici. Pour un contenu plus passionnant, vous pouvez faire attention à la colonne Vidéo du didacticiel Java du site Web PHP chinois !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!