Bonnes pratiques de développement pour les applications WebView2

  • Article

Chaque équipe de développement suit des pratiques différentes lors de la création de son application. Lorsque vous créez des applications de production WebView2, nous vous recommandons de suivre ces recommandations et meilleures pratiques.

Nous vous recommandons généralement d’utiliser le runtime Evergreen WebView2. La distribution du runtime de version fixe est recommandée uniquement pour les applications qui ont des exigences de compatibilité strictes. Le runtime Evergreen se met automatiquement à jour sur le client, afin que les dernières fonctionnalités et correctifs de sécurité soient disponibles pour votre application WebView2. Le runtime Evergreen nécessite également moins d’espace de stockage sur le disque que le runtime version fixe.

Si vous utilisez le runtime Evergreen, avant d’exécuter votre application WebView2, testez si le runtime Evergreen WebView2 est installé sur le client. Consultez Déploiement du runtime Evergreen WebView2.

Exécuter régulièrement des tests de compatibilité lors de l’utilisation du runtime Evergreen

Lorsque vous utilisez le runtime Evergreen WebView2, le runtime est automatiquement mis à jour. Vous devez donc exécuter régulièrement des tests de compatibilité. Pour vous assurer que votre application WebView2 continuera de fonctionner comme prévu, testez votre contenu web dans le contrôle WebView2 par rapport aux canaux Microsoft Edge Insider (préversion) (bêta, dev ou canary).

Ces conseils sont similaires à ceux que nous donnons aux développeurs web. Consultez Tester votre application pour la compatibilité avant.

Tester si les API plus récentes sont prises en charge par le runtime WebView2 installé

Pour exécuter une application WebView2 développée avec une version particulière du Kit de développement logiciel (SDK) Webview2, une version compatible du runtime WebView2 doit être installée sur le client. Étant donné que les API sont continuellement ajoutées à WebView2, de nouvelles versions du runtime sont également publiées pour prendre en charge les nouvelles API. Utilisez la détection des fonctionnalités pour vous assurer que les API les plus récentes utilisées par votre application WebView2 sont prises en charge par le runtime WebView2 installé sur le client.

Si vous utilisez le runtime Evergreen WebView2, il existe des scénarios dans lesquels le runtime sur un client n’a pas été automatiquement mis à jour vers la dernière version. Par exemple, si un client n’a pas accès à Internet, le runtime n’est pas automatiquement mis à jour.

En outre, certaines stratégies de groupe interrompent la mise à jour du runtime. Lorsque vous envoyez une mise à jour à votre application WebView2, l’application risque de ne pas fonctionner si elle tente d’appeler des API plus récentes qui ne sont pas disponibles dans le runtime installé du client.

Pour résoudre ce problème, avant que votre code n’appelle une API WebView2 récemment ajoutée, testez si cette API est disponible dans le runtime installé du client. Ce test des fonctionnalités plus récentes est similaire à d’autres bonnes pratiques de développement web qui détectent les fonctionnalités prises en charge avant d’utiliser de nouvelles API web. Pour tester la disponibilité de l’API dans le runtime installé, utilisez :

  • QueryInterface en C/C++.
  • Bloc try/catch dans .NET ou WinUI.

Consultez Détection de fonctionnalités pour tester si le runtime installé prend en charge les API récemment ajoutées.

Mettre à jour le runtime de version fixe

Si vous utilisez le runtime WebView2 version fixe, veillez à mettre à jour régulièrement le runtime WebView2 qui est empaqueté avec votre application, afin de réduire les risques de sécurité. Lorsque vous utilisez du contenu tiers dans des applications Webview2, considérez toujours le contenu comme non approuvé. Consultez Mode de distribution version fixe.

Gérer les nouvelles versions du runtime persistant

Lorsqu’une nouvelle version du runtime Evergreen WebView2 est téléchargée sur le client, toutes les applications WebView2 en cours d’exécution continuent d’utiliser la version précédente du runtime, jusqu’à ce que le processus du navigateur soit libéré. Ce comportement permet aux applications de s’exécuter en continu et empêche la suppression du runtime précédent. Pour utiliser la nouvelle version du runtime, vous devez libérer toutes les références aux objets d’environnement WebView2 précédents ou redémarrer votre application. La prochaine fois que votre application créera un environnement WebView2, l’application utilisera la nouvelle version du runtime.

Lorsqu’une nouvelle version du runtime est disponible, votre application peut prendre automatiquement des mesures, comme avertir l’utilisateur de redémarrer l’application. Pour détecter qu’une nouvelle version du runtime est disponible, vous pouvez utiliser l’événement add_NewBrowserVersionAvailable (Win32) ou CoreWebView2Environment.NewBrowserVersionAvailable (.NET) dans votre code. Si votre code gère le redémarrage de l’application, envisagez d’enregistrer l’état utilisateur avant la fermeture de l’application WebView2.

Gérer la durée de vie du dossier de données utilisateur

Les applications WebView2 créent un dossier de données utilisateur pour stocker des données telles que des cookies, des informations d’identification et des autorisations. Après avoir créé le dossier, votre application est chargée de gérer la durée de vie du dossier de données utilisateur. Par exemple, votre application doit effectuer un nettoyage lorsque l’application est désinstallée. Consultez Gérer les dossiers de données utilisateur.

Gérer les échecs de processus d’exécution

Votre application WebView2 doit écouter et gérer l’événement ProcessFailed , afin que l’application puisse récupérer après des échecs de processus d’exécution qui prennent en charge le processus d’application WebView2.

Les applications WebView2 sont prises en charge par une collection de processus d’exécution qui s’exécutent parallèlement au processus d’application. Ces processus d’exécution de prise en charge peuvent échouer pour diverses raisons, telles que l’épuisement de la mémoire ou l’arrêt par l’utilisateur. Lorsqu’un processus d’exécution de prise en charge échoue, WebView2 avertit l’application en lançant l’événement ProcessFailed.

Gestionnaires d’événements sur l’objet d’environnement

Si l’un des gestionnaires d’événements de votre application sur l’objet d’environnement contient une référence à l’objet d’environnement, et que l’application libère simplement la référence à l’environnement et aux gestionnaires d’événements sans supprimer les gestionnaires d’événements, il peut y avoir une référence circulaire entre l’objet d’environnement et les objets gestionnaire, ce qui entraîne une fuite de mémoire.

Pour éviter une telle fuite de mémoire :

  • Pour tout gestionnaire d’événements ajouté, supprimez le gestionnaire d’événements avant de libérer l’objet d’environnement.

  • Évitez de conserver une référence à l’objet d’environnement dans un gestionnaire d’événements. Au lieu de cela, le gestionnaire d’événements peut accéder à l’objet d’environnement à partir de l’argument sender du rappel « event completed ».

  • Si vous souhaitez que l’application contienne une référence à un objet WebView2, utilisez une référence faible dans la mesure du possible.

Pour toute application WebView2, veillez à suivre nos recommandations dans Développer des applications WebView2 sécurisées.