Dieses Mal zeige ich Ihnen, wie Sie React Virtual DOM verwenden und welche Vorsichtsmaßnahmen bei der Verwendung von React Virtual DOM gelten. Hier sind praktische Fälle, werfen wir einen Blick darauf.
In der Webentwicklung müssen Datenänderungen in Echtzeit berücksichtigt werden. Zu diesem Zeitpunkt sind jedoch komplexe oder häufige DOM-Vorgänge die Ursache für Leistungsengpässe Aus diesem Grund wird React Der Mechanismus des virtuellen DOM (Virtual DOM) wird eingeführt.
1. Was ist virtuelles DOM?
In React ist das Ergebnis der Renderausführung kein echter DOM-Knoten, sondern ein leichtes JavaScript-Objekt, das wir virtuelles DOM nennen.
Virtuelles DOM ist ein Highlight von React, mit Batchverarbeitung und effizientem Diff-Algorithmus. Dadurch können wir die gesamte Seite jederzeit „aktualisieren“, ohne uns Gedanken über Leistungsprobleme machen zu müssen, und das virtuelle DOM stellt sicher, dass nur die tatsächlichen DOM-Operationen an den tatsächlich geänderten Teilen der Schnittstelle ausgeführt werden. In der tatsächlichen Entwicklung müssen Sie sich im Grunde nicht darum kümmern, wie das virtuelle DOM funktioniert, aber wenn Sie seinen Betriebsmechanismus verstehen, können Sie nicht nur den Lebenszyklus von React-Komponenten besser verstehen, sondern sind auch von großem Nutzen Hilfe bei der weiteren Optimierung von React-Programmen.
2. Virtueller DOM vs. direkter Betrieb des nativen DOM?
Wenn kein virtuelles DOM vorhanden ist, setzen Sie innerHTML einfach direkt zurück. Dieser Vorgang ist sinnvoll, wenn sich alle Daten in einer großen Liste geändert haben. Wenn sich jedoch nur eine Datenzeile ändert, muss auch das gesamte innerHTML zurückgesetzt werden, was offensichtlich viel Verschwendung verursacht.
Vergleichen Sie den Neuzeichnungsprozess von innerHTML und Virtual DOM wie folgt:
innerHTML: HTML-String rendern + alle DOM-Elemente neu erstellen
Virtual DOM: Virtual DOM rendern + Diff + erforderlich DOM-Update
Im Vergleich zum DOM-Betrieb ist die js-Berechnung sehr günstig. Virtual DOM Render + Diff ist offensichtlich langsamer als das Rendern von HTML-Strings, aber es handelt sich immer noch um eine reine Berechnung auf JS-Ebene, die immer noch viel billiger ist als die nachfolgenden DOM-Operationen. Natürlich hat jemand eine Überprüfung durchgeführt und gesagt, dass die Leistung von React nicht so gut ist wie die direkte Bedienung des echten DOM. Der Code lautet wie folgt:
function Raw() { var data = _buildData(), html = ""; ... for(var i=0; i<data.length; i++) { var render = template; render = render.replace("{{className}}", ""); render = render.replace("{{label}}", data[i].label); html += render; } ... container.innerHTML = html; ... }
Obwohl in diesem Testfall ein String mit 1000 Tags vorhanden ist erstellt und zum DOM-Baum hinzugefügt, es wurde jedoch nur eine DOM-Operation ausgeführt. Im tatsächlichen Entwicklungsprozess können diese 1.000 Elementaktualisierungen jedoch auf 20 logische Blöcke verteilt werden. Jeder logische Block enthält 50 Elemente. Wenn die Seite aktualisiert werden muss, wird der obige Code aktualisiert werden Es wird zum folgenden Format:
function Raw() { var data = _buildData(), html = ""; ... for(var i=0; i<data.length; i++) { var render = template; render = render.replace("{{className}}", ""); render = render.replace("{{label}}", data[i].label); html += render; if(!(i % 50)) { container.innerHTML = html; } } ... }
So gesehen ist die Leistung von React weitaus besser als native DOM-Operationen.
Außerdem gehört DOM überhaupt nicht zu Javascript (und existiert auch nicht in Javascript-Engines). Javascript ist eigentlich eine sehr unabhängige Engine. DOM ist eigentlich eine Reihe von APIs, die vom Browser eingeführt werden und es Javascript ermöglichen, HTML-Dokumente zu betreiben. Im Zeitalter der Just-in-Time-Kompilierung ist der Aufwand für den Aufruf von DOM sehr hoch. Die Ausführung von Virtual DOM erfolgt vollständig in der Javascript-Engine und es entsteht überhaupt kein solcher Overhead.
React.js bietet große Leistungsvorteile gegenüber der direkten Manipulation von nativem DOM, hauptsächlich aufgrund der Stapelverarbeitung und Diff von virtuellem DOM. Beim Batching werden alle DOM-Vorgänge erfasst und auf einmal an das echte DOM übermittelt. Die zeitliche Komplexität des Diff-Algorithmus wurde ebenfalls von O(n^3) des Standard-Diff-Algorithmus auf O(n) reduziert. Ich überlasse dies dem nächsten Blogbeitrag.
3. Virtuelles DOM vs. MVVM?
Im Vergleich zu React verwenden andere MVVM-Frameworks wie Angular, Knockout, Vue und Avalon alle Datenbindung: Beobachten Sie die Datenänderungen über Direktiven-/Bindungsobjekte und behält den Verweis auf das tatsächliche DOM-Element bei und führt entsprechende Vorgänge aus, wenn sich die Daten ändern. Die Änderungsprüfung von MVVM erfolgt auf Datenebene, während die Prüfung von React auf der DOM-Strukturebene erfolgt. Die Leistung von MVVM unterscheidet sich auch aufgrund des Implementierungsprinzips der Änderungserkennung: Die Dirty-Prüfung von Angular sorgt dafür, dass jede Änderung einen festen Kostenfaktor von O hat (Anzahl der Beobachter); Ja O(Änderung):
Dirty Check: Scope Digest + notwendige DOM-Aktualisierung
Abhängigkeitssammlung: Abhängigkeiten erneut sammeln + notwendige DOM-Aktualisierung
Wie Sie sehen, ist das Ineffizienteste an Angular, dass jede kleine Änderung Leistungseinbußen in Abhängigkeit von der Anzahl der Beobachter verursacht. Aber! Wenn sich alle Daten ändern, leidet Angular tatsächlich nicht. Die Abhängigkeitserfassung erfordert die erneute Erfassung von Abhängigkeiten während der Initialisierung und bei Datenänderungen. Dieser Aufwand kann bei kleinen Aktualisierungsmengen nahezu vernachlässigt werden, führt jedoch auch zu einem gewissen Verbrauch, wenn die Datenmenge groß ist.
Wenn MVVM eine Liste rendert, verfügt jede Zeile normalerweise über eine entsprechende ViewModel-Instanz oder einen etwas leichteren „Bereich, der Prototypenvererbung verwendet“, da jede Zeile ihren eigenen Datenbereich hat. Objekt, aber es gibt einen Preis. Daher ist die Initialisierung des MVVM-Listen-Renderings fast garantiert langsamer als die von React, da die Erstellung von ViewModel-/Scope-Instanzen viel teurer ist als die von Virtual DOM. Ein gemeinsames Problem bei allen MVVM-Implementierungen besteht hier darin, wie bereits erstellte ViewModel-Instanzen und DOM-Elemente effektiv wiederverwendet werden können, wenn sich die Datenquelle für die Listenwiedergabe ändert, insbesondere wenn es sich bei den Daten um ein völlig neues Objekt handelt. Ohne Wiederverwendungsoptimierung muss MVVM tatsächlich alle vorherigen Instanzen zerstören, alle Instanzen neu erstellen und schließlich erneut rendern, da die Daten „neu“ sind! Aus diesem Grund sind die im Titel verlinkten Angular-/Knockout-Implementierungen relativ langsam. Da sich die Änderungsprüfung von React dagegen auf der Ebene der DOM-Struktur befindet, besteht auch bei brandneuen Daten keine Notwendigkeit, nutzlose Arbeit zu leisten, solange sich das endgültige Rendering-Ergebnis nicht geändert hat.
Sowohl Angular als auch Vue bieten Optimierungsmechanismen für das Neuzeichnen von Listen, die „Hinweise“ für das Framework sind, wie Instanzen und DOM-Elemente effektiv wiederverwendet werden können. Beispielsweise wird dasselbe Objekt in der Datenbank in zwei Front-End-API-Aufrufen zu unterschiedlichen Objekten, sie haben jedoch immer noch dieselbe UID. Zu diesem Zeitpunkt können Sie die UID-Nachverfolgung auffordern, um Angular darüber zu informieren, dass es sich bei den beiden Objekten tatsächlich um dieselben Daten handelt. Dann können die den Originaldaten entsprechenden Instanzen und DOM-Elemente wiederverwendet werden und nur die geänderten Teile müssen aktualisiert werden. Alternativ können Sie auch direkt über $index nachverfolgen, um eine „In-Place-Wiederverwendung“ durchzuführen: Wiederverwendung direkt basierend auf der Position im Array. Wenn in dem in der Frage angegebenen Beispiel die Angular-Implementierung die Spur um $index hinzufügt, ist das anschließende Neuzeichnen nicht viel langsamer als bei React. Selbst im dbmonster-Test sind Angular und Vue nach Verwendung von track by $index: dbmon schneller als React (beachten Sie, dass die Standardversion von Angular nicht optimiert ist, die optimierte Version finden Sie unten)
Beim Leistungsvergleich ist es Es ist notwendig, die verschiedenen Anlässe des anfänglichen Renderns, der Aktualisierung kleiner Daten und der Aktualisierung großer Daten zu unterteilen. Virtuelles DOM, Dirty-Checking-MVVM und Datenerfassungs-MVVM weisen bei verschiedenen Gelegenheiten unterschiedliche Leistungen und unterschiedliche Optimierungsanforderungen auf. Um die Leistung kleiner Datenaktualisierungen zu verbessern, muss Virtual DOM auch gezielt optimiert werden, z. B. ShouldComponentUpdate oder unveränderliche Daten.
Erstes Rendering: Virtual DOM > Dirty Check >= Dependency Collection
Kleine Datenaktualisierung: Virtual DOM + Optimierung > Dirty Check (kann nicht optimiert werden) > Keine Optimierung erforderlich)>> >4. Missverständnis des virtuellen React-DOM?
React hat nie gesagt: „React ist schneller als native DOM-Manipulation“. React garantiert uns, dass es uns ohne manuelle Optimierung immer noch eine ordentliche Leistung liefern kann.
Ich glaube, dass Sie die Methode beherrschen, nachdem Sie den Fall in diesem Artikel gelesen haben. Weitere spannende Informationen finden Sie in anderen verwandten Artikeln auf der chinesischen PHP-Website!
Bilder mit Back-End-Code im WeChat-Miniprogramm hochladen
Praktische Übung zum Hochladen von Bildern in Fallanalyse des WeChat-Miniprogramms
Das obige ist der detaillierte Inhalt vonSo verwenden Sie das virtuelle React-DOM. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!