Was ist das Passivprinzip? Was macht es?

Der Inhalt dieses Artikels dreht sich um das Prinzip des Passivs? Was macht es? Es hat einen gewissen Referenzwert. Freunde in Not können sich darauf beziehen. Ich hoffe, es wird Ihnen hilfreich sein.

Was nützt Passiv?

Passiv wird hauptsächlich verwendet, um die Leistung des Browser-Seitenscrollens zu optimieren und das Scrollen von Seiten flüssiger zu machen~~

Die durch Passiv generierte historische Zeitleiste

addEventListener(): Wie jeder weiß, fügen Sie dem Dom ein Triggerereignis hinzu, und die Geschichte beginnt hier.
In den frühen Tagen sah addEventListener so aus:

addEventListener(type, listener, useCapture)

useCapture: Gibt an, ob die Ereigniserfassung zugelassen werden soll, aber „true“ wurde selten übergeben, und dann wurde es optional:

addEventListener(type, listener[, useCapture ])

Das hat sich geändert Jetzt sieht es so aus:

addEventListener(type, listener, {
    capture: false, //捕获
    passive: false, 
    once: false    //只触发一次
})

Unser Protagonist passiv erscheint

Warum kann passiv die Scroll-Performance der Seite optimieren?

Eine kurze Beschreibung des Threaded-Rendering-Frameworks von Chrome

Die beiden Threads des Threaded-Rendering-Frameworks von Chrome:

• Kernel-Thread (Main /Render Thread): Verantwortlich für die DOM-Baumkonstruktion, das Elementlayout, den Layer-Drawing-Datensatzteil (Haupt-Thread-Seite), die JavaScript-Ausführung

• Compositor-Thread: Layer-Drawing-Implementierungsteil (Impl-Seite), Ebenenbildsynthese

Teil 1 Wie aus der Abbildung ersichtlich ist, danach Seite Frame#1 schließt js Ausführung, Layout und Zeichnung im Kernel-Thread ab und durchläuft einen Zyklus von Synthese-Threads, um die Synthese des Seitenbildes von Frame#1 durchzuführen.

Klassifizierung von Benutzereingabeereignissen:

• Vom Kernel-Thread verarbeitete Ereignisse

• Direkt vom Kompositions-Thread verarbeitete Ereignisse

Was ist also der Unterschied?

Im Kernel-Thread verarbeitete Ereignisse: Eingabeereignisse, die vom Kernel-Thread verarbeitet werden müssen, müssen Logik im Kernel-Thread ausführen. Wenn der Kernel-Thread ausgelastet ist, kann er nicht sofort reagieren. Beispielsweise beziehen sich die meisten Eingabeereignisse des Benutzers auf Seitenelemente. Sobald das Seitenelement einen Listener für das entsprechende Ereignis registriert, muss der Logikcode (JavaScript) des Listeners im Kernel-Thread ausgeführt werden (die V8-Engine läuft im). Kernel-Thread), daher erhalten solche Eingabeereignisse oft keine sofortige Antwort.
Direkt vom Kompositionsthread verarbeitete Ereignisse: Eingabeereignisse, die schnell verarbeitet werden können, ohne den Kernel-Thread zu durchlaufen, sind Gesteneingabeereignisse (Wischen, Kneifen).

Kernpunkt: Hier kommt das Ärgerlichste. Obwohl Gestenereignisse ohne den Kernel-Thread verarbeitet werden können, ist die Generierung von Gestenereignissen immer noch untrennbar mit dem Kernel-Thread verbunden.

Der Grund, warum die Seite hängen bleibt

Gestenereignisse haben Attribute abbrechbar, seine Funktion besteht darin, dem Browser mitzuteilen, ob das Ereignis es dem Listener ermöglicht, präventDefault() zu übergeben Methodenblockierung, der Standardwert ist „true“. Wenn „preventDefault()“ innerhalb des Touch-Ereignisses aufgerufen wird, wird das Standardverhalten des Ereignisses aufgehoben und die Seite wird stationär. Der Browser weiß jedoch nicht, ob im Touch-Ereignis intern PreventDefault () aufgerufen wird. Der Browser kann nur wissen, ob die PreventDefault-Funktion intern aufgerufen wird, um das Standardverhalten des Ereignisses zu verhindern, bis der Kernel-Thread den entsprechenden JavaScript-Code ausführt Daher kann das Durchsuchen des Servers selbst dieses Szenario nicht optimieren. Gesteneingabeereignisse bestehen aus kontinuierlichen gewöhnlichen Eingabeereignissen. In diesem Szenario können sie nicht schnell generiert werden, was dazu führt, dass die Seite die Gleitlogik nicht schnell ausführen kann und der Benutzer das Gefühl hat, dass die Seite feststeckt.

Das Chrome-Team hat anhand statistischer Daten analysiert, dass 80 % der Seiten, auf denen Mausrad-/Berührungs-bezogene Ereignis-Listener registriert sind, die Funktion „preventDefault“ nicht intern aufrufen, um das Standardverhalten des Ereignisses zu verhindern. Bei diesen 80 % der Seiten erhöhen 10 % der Seiten die Verzögerung um mindestens 100 ms in Bezug auf die Glätte und 1 ms, selbst wenn im Listener nichts getan wird, im Vergleich zu Seiten, die keine Mausrad-/Touch-Ereignis-Listener registriert haben % der Seiten verursachen sogar eine Verzögerung von mehr als 500 ms. Das Chrome-Team geht davon aus, dass es für 80 % der Seiten in der Statistik keine Erhöhung der Gleitverzögerung aufgrund der Registrierung von Mausrad-/Touch-bezogenen Ereignis-Listenern möchte.

Die Geburt des Passiven

Der passive Zuhörer wurde also geboren, was „gehorsam“ bedeutet, was bedeutet, dass er nicht Nein zum Standardverhalten des Zuhörers sagen wird Sobald der Browser weiß, dass ein Listener passiv ist, kann er den JavaScript-Code im Listener und das Standardverhalten des Browsers gleichzeitig in zwei Threads ausführen.

Nach der obigen Analyse haben wir gelernt, dass Passiv Ereignis Die Listener-Funktion dient eigentlich dazu, das Problem der Glätte der Browserseite zu lösen. Sie ermöglicht es Webentwicklern, dem Browser mitzuteilen, ob der Listener das Standardverhalten des Ereignisses blockiert, indem sie das Ereignisattribut passiv erweitern, sodass der Browser intelligentere Entscheidungen treffen kann . Und Optimierung, die das Multithread-Rendering-Framework von Chrome, die Verarbeitung von Eingabeereignissen und andere Kenntnisse umfasst.

Das obige ist der detaillierte Inhalt vonWas ist das Passivprinzip? Was macht es?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!