Maison > interface Web > js tutoriel > Quel est le principe du passif ? Qu'est-ce que ça fait ?

Quel est le principe du passif ? Qu'est-ce que ça fait ?

不言
Libérer: 2018-12-06 16:13:35
avant
3828 Les gens l'ont consulté

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)
Copier après la connexion

useCapture : s'il faut autoriser la capture d'événements, mais true est rarement transmis, puis cela devient facultatif :

addEventListener(type, listener[, useCapture ])
Copier après la connexion

Maintenant, cela ressemble à ceci :

addEventListener(type, listener, {
    capture: false, //捕获
    passive: false, 
    once: false    //只触发一次
})
Copier après la connexion

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

Quel est le principe du passif ? Quest-ce que ça fait ?

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!

Étiquettes associées:
source:segmentfault.com
Déclaration de ce site Web
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
Tutoriels populaires
Plus>
Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal