Le contenu de cet article concerne le principe du passif ? Qu'est-ce que ça fait ? 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.
A quoi sert le passif ?
passif est principalement utilisé pour optimiser les performances de défilement des pages du navigateur et rendre le défilement des pages plus fluide~~
La chronologie historique générée par passif
addEventListener() : comme tout le monde le sait, ajoutez un événement déclencheur au dom et l'histoire commence ici.
Au début, addEventListener ressemblait à ceci :
addEventListener(type, listener, useCapture)
useCapture : s'il faut autoriser la capture d'événements, mais true est rarement transmis, puis cela devient facultatif :
addEventListener(type, listener[, useCapture ])
Maintenant, cela ressemble à ceci :
addEventListener(type, listener, { capture: false, //捕获 passive: false, once: false //只触发一次 })
Notre protagoniste passif apparaît
Pourquoi le passif peut-il optimiser les performances de défilement de la page ?
Une brève description du framework de rendu threadé de Chrome
Les deux threads du framework de rendu threadé de Chrome :
Thread du noyau (Main /Render Thread) : Responsable de la construction de l'arborescence DOM, de la disposition des éléments, de la partie d'enregistrement du dessin de couche (côté thread principal), de l'exécution de JavaScript
Thème du compositeur : partie d'implémentation du dessin de couche (côté impl), synthèse d'image de couche
Partie 1 Comme on peut le voir sur la figure, après la page Frame#1 termine l'exécution, la mise en page et le dessin de js dans le thread du noyau, elle passe par un cycle de threads de synthèse pour effectuer la synthèse de l'image de la page Frame#1.
Classification des événements d'entrée utilisateur :
Événements traités par le thread du noyau
Événements traités directement par le thread de composition
Alors quelle est la différence ?
Événements traités dans le thread du noyau : les événements d'entrée qui doivent être traités par le thread du noyau doivent exécuter la logique dans le thread du noyau. Si le thread du noyau est occupé, il ne peut pas répondre immédiatement. Par exemple, la plupart des événements d'entrée de l'utilisateur sont liés aux éléments de page. Une fois que l'élément de page enregistre un écouteur pour l'événement correspondant, le code logique (JavaScript) de l'écouteur doit être exécuté dans le thread du noyau (le moteur V8 s'exécute dans le thread du noyau). thread du noyau), donc ces événements d'entrée ne reçoivent souvent pas de réponse immédiate.
Événements traités directement par le thread de composition : Les événements d'entrée qui peuvent être traités rapidement sans passer par le thread du noyau sont des événements de saisie gestuelle (balayage, pincement).
Point clé : voici la chose la plus ennuyeuse. Bien que les événements gestuels puissent être traités sans le thread du noyau, la génération des événements gestuels est toujours indissociable du thread du noyau.
La raison pour laquelle la page est bloquée
Les événements gestuels ont des attributs annulable, sa fonction est d'indiquer au navigateur si l'événement permet à l'écouteur de passer PreventDefault() Blocage de la méthode, la valeur par défaut est true. Si PreventDefault() est appelé à l'intérieur de l'événement touch, le comportement par défaut de l'événement est annulé et la page devient stationnaire. Cependant, le navigateur ne sait pas si PreventDefault() est appelé en interne dans l'événement touch. Le navigateur peut seulement savoir si la fonction PreventDefault sera appelée en interne pour empêcher le comportement par défaut de l'événement jusqu'à ce que le thread du noyau exécute le code JavaScript correspondant à. l'écouteur d'événements. Par conséquent, la navigation sur le serveur lui-même ne peut pas optimiser ce scénario. Les événements de saisie gestuelle sont composés d'événements de saisie ordinaires continus. Dans ce scénario, ils ne peuvent pas être générés rapidement, ce qui empêchera la page d'exécuter rapidement la logique coulissante, ce qui donnera à l'utilisateur le sentiment que la page est bloquée.
L'équipe Chrome a analysé à partir de données statistiques que 80 % des pages qui ont enregistré des écouteurs d'événements liés à la molette de la souris/au toucher n'appellent pas la fonction PreventDefault en interne pour empêcher le comportement par défaut de l'événement. Pour ces 80% de pages, même si rien n'est fait à l'intérieur de l'écouteur, par rapport aux pages qui n'ont pas enregistré d'écouteurs d'événements molette de souris/toucher, 10% des pages augmenteront le délai d'au moins 100 ms en termes de fluidité de glissement, et 1 % des pages ajouteront même un délai de plus de 500 ms. L'équipe Chrome estime que pour 80 % des pages des statistiques, elle ne souhaite pas augmenter le délai de glissement en raison de l'enregistrement des écouteurs d'événements liés à la molette de la souris/au toucher.
La naissance du passif
Ainsi, l'auditeur passif est né Passif signifie « obéissant », ce qui signifie qu'il ne dira pas non au comportement par défaut du. Une fois que le navigateur sait qu'un écouteur est passif, il peut exécuter le code JavaScript dans l'écouteur et le comportement par défaut du navigateur dans deux threads en même temps.
Après l'analyse ci-dessus, nous avons appris que le passif Événement La fonctionnalité Listeners est en fait conçue pour résoudre le problème de la fluidité du glissement des pages du navigateur. Elle permet aux développeurs Web d'indiquer au navigateur si l'écouteur bloquera le comportement par défaut de l'événement en étendant l'attribut d'événement passif, afin que le navigateur puisse prendre des décisions plus intelligentes. . Et l'optimisation, qui implique le cadre de rendu multithread de Chrome, le traitement des événements d'entrée et d'autres connaissances.
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!