In diesem Artikel wird der Speicher-Inspector vorgestellt, der in Chrome 91 eingeführt wurde. Sie können damit ArrayBuffer, TypedArray, DataView und Wasm-Speicher prüfen.
Einführung
Wollten Sie schon immer einmal die Daten in Ihrem ArrayBuffer auswerten? Vor dem Speicher-Inspector boten die DevTools nur begrenzte Informationen zu ArrayBuffers. Die Prüfung in der Ansicht Scope während einer Debug-Sitzung war auf die Anzeige einer Liste einzelner Werte im Array-Buffer beschränkt, was es schwierig machte, die Daten insgesamt zu verstehen. Im folgenden Beispiel wird in der Ansicht Scope (Umfang) der Puffer als erweiterbare Bereiche von Arrays dargestellt:
Das Aufrufen eines bestimmten Bereichs im Puffer war ein Problem, da die Nutzer nach unten scrollen mussten, um diesen Index zu erreichen. Aber selbst wenn das Aufrufen einer Position einfach wäre, ist diese Art der Prüfung von Werten umständlich: Es ist schwierig zu sagen, was diese Zahlen bedeuten. Was ist insbesondere, wenn sie nicht als einzelne Bytes, sondern z.B. als 32‑Bit-Ganzzahlen interpretiert werden sollen?
Werte mit dem Arbeitsspeicher-Prüftool prüfen
Mit Chrome 91 führen wir den Speicher-Inspektor ein, ein Tool zum Prüfen von Array-Buffers. Möglicherweise haben Sie schon einmal Speicherprüfungstools zur Anzeige von Binärdaten gesehen, die den Binärinhalt in einem Raster zusammen mit den Adressen anzeigen und verschiedene Möglichkeiten zur Interpretation der zugrunde liegenden Werte bieten. Genau das bietet der Memory Inspector. Mit dem Speicher-Inspector können Sie sich die Inhalte ansehen, darin navigieren und Typen auswählen, die zur Interpretation der vorliegenden Werte verwendet werden sollen. Die ASCII-Werte werden direkt neben den Bytes angezeigt und der Nutzer kann eine andere Endianness auswählen. Hier sehen Sie das Arbeitsspeicher-Prüftool in Aktion:
Möchten Sie es einmal ausprobieren? Weitere Informationen dazu, wie Sie den Speicherprüfer öffnen und Ihren Array-Buffer (oder TypedArray, DataView oder Wasm-Speicher) aufrufen, sowie Informationen zur Verwendung finden Sie in der Dokumentation zum Speicherprüfer. Probieren Sie es mit diesen Beispielen (für JS, Wasm und C++) aus.
Memory Inspector entwerfen
In diesem Teil sehen wir uns an, wie der Memory Inspector mithilfe von Webkomponenten gestaltet wurde. Außerdem zeigen wir eines unserer Designziele und wie wir es umgesetzt haben. Wenn Sie mehr darüber erfahren möchten, sehen Sie sich unser Designdokument für den Arbeitsspeicher-Inspector an.
Vielleicht haben Sie unseren Blogpost zur Migration zu Webkomponenten gesehen, in dem Jack unseren internen Leitfaden zum Erstellen von UI-Komponenten mit Webkomponenten veröffentlicht hat. Die Migration zu Web-Komponenten fiel mit unserer Arbeit am Speicher-Inspector zusammen. Daher haben wir beschlossen, das neue System auszuprobieren. Im folgenden Diagramm sind die Komponenten zu sehen, die wir für den Memory Inspector erstellt haben. Intern nennen wir ihn Linear Memory Inspector:
Die LinearMemoryInspector-Komponente ist die übergeordnete Komponente, die die Unterkomponenten kombiniert, aus denen alle Elemente im Arbeitsspeicher-Inspector bestehen. Es nimmt im Grunde eine Uint8Array und eine address und überträgt bei jeder Änderung der Daten an die untergeordneten Elemente, was ein erneutes Rendern auslöst. Die LinearMemoryInspector selbst rendert drei Unterkomponenten:
LinearMemoryViewer(mit den Werten),LinearMemoryNavigator(Navigation zulassen) undLinearMemoryValueInterpreter(mit verschiedenen Interpretationen der zugrunde liegenden Daten).
Letztere ist selbst eine übergeordnete Komponente, die die ValueInterpreterDisplay (mit den Werten) und die ValueInterpreterSettings (mit der Auswahl der Typen, die in der Anzeige angezeigt werden sollen) rendert.
Jede Komponente soll nur eine kleine Komponente der Benutzeroberfläche darstellen, damit sie bei Bedarf wiederverwendet werden kann. Jedes Mal, wenn für eine Komponente neue Daten festgelegt werden, wird ein erneutes Rendern ausgelöst, bei dem die Änderung an den für die Komponente festgelegten Daten berücksichtigt wird. Unten sehen Sie ein Beispiel für einen Workflow mit unseren Komponenten. Der Nutzer ändert die Adresse in der Adressleiste, wodurch eine Aktualisierung ausgelöst wird, indem die neuen Daten festgelegt werden, in diesem Fall die anzuzeigende Adresse:
Die LinearMemoryInspector fügt sich selbst als Listener auf der LinearMemoryNavigator hinzu. Die addressChanged-Funktion soll bei einem address-changed-Ereignis ausgelöst werden. Sobald der Nutzer die Adresseingabe bearbeitet, wird das oben genannte Ereignis gesendet, wodurch die Funktion addressChanged aufgerufen wird. Diese Funktion speichert die Adresse jetzt intern und aktualisiert ihre Unterkomponenten mithilfe eines data(address, ..)-Setters. Die untergeordneten Komponenten speichern die Adresse intern und rendern ihre Ansichten neu, um die Inhalte an dieser bestimmten Adresse anzuzeigen.
Designziel: Leistung und Arbeitsspeicherverbrauch unabhängig von der Puffergröße machen
Bei der Entwicklung des Arbeitsspeicher-Prüftools haben wir darauf geachtet, dass die Leistung unabhängig von der Puffergröße ist.
Wie Sie im vorherigen Teil gesehen haben, nimmt die LinearMemoryInspector-Komponente einen UInt8Array an, um die Werte zu rendern. Gleichzeitig wollten wir dafür sorgen, dass der Memory Inspector nicht alle Daten speichern muss, da er nur einen Teil davon anzeigt. Der Wasm-Speicher kann beispielsweise bis zu 4 GB groß sein und wir möchten nicht 4 GB im Memory Inspector speichern.
Damit die Geschwindigkeit und die Speichernutzung des Speicher-Inspektors unabhängig vom tatsächlich angezeigten Puffer ist, behält die LinearMemoryInspector-Komponente nur einen Teilbereich des ursprünglichen Puffers bei.
Damit dies funktioniert, muss LinearMemoryInspector zuerst zwei weitere Argumente annehmen: eine memoryOffset und eine outerMemoryLength. memoryOffset gibt den Offset an, bei dem das übergebene Uint8Array beginnt. Er ist erforderlich, um die richtigen Datenadressen zu rendern. outerMemoryLength ist die Länge des ursprünglichen Buffers und gibt an, welchen Bereich wir anzeigen können:
Mit diesen Informationen können wir dafür sorgen, dass wir weiterhin dieselbe Ansicht wie zuvor (den Inhalt um die address herum) rendern können, auch wenn nicht alle Daten vorhanden sind. Was ist zu tun, wenn eine andere Adresse angefordert wird, die in einen anderen Bereich fällt? In diesem Fall löst LinearMemoryInspector einen RequestMemoryEvent aus, wodurch der aktuelle Bereich aktualisiert wird. Unten finden Sie ein Beispiel:
In diesem Beispiel wechselt der Nutzer zur Speicherseite (der Speicher-Inspector verwendet Auslagerung, um Datenblöcke anzuzeigen). Dies löst eine PageNavigationEvent aus, die wiederum eine RequestMemoryEvent auslöst.
Dieses Ereignis startet das Abrufen des neuen Bereichs, der dann durch Festlegen der Daten an die LinearMemoryInspector-Komponente weitergegeben wird. Daher werden die neu abgerufenen Daten angezeigt.
Und wussten Sie schon, Sie können sogar den Arbeitsspeicher in Wasm- und C/C++-Code prüfen.
Der Speicher-Inspektor ist nicht nur für ArrayBuffers in JavaScript verfügbar, sondern kann auch zum Prüfen von Wasm-Speicher und Speicher verwendet werden, auf den C/C++-Referenzen/-Pointer verweisen (mit unserer DWARF-Erweiterung – probieren Sie es aus, falls Sie es noch nicht getan haben). Weitere Informationen finden Sie unter WebAssembly mit modernen Tools debuggen. Hier ein kleiner Ausblick auf den Memory Inspector in Aktion für das native Debuggen von C++ im Web:
Fazit
In diesem Artikel wurde der Arbeitsspeicher-Inspector vorgestellt und ein Einblick in sein Design gegeben. Wir hoffen, dass der Memory Inspector Ihnen dabei hilft, zu verstehen, was in Ihrem ArrayBuffer passiert. :-) Wenn Sie Verbesserungsvorschläge haben, teilen Sie uns diese mit und melden Sie einen Fehler.
Vorschaukanäle herunterladen
Verwenden Sie als Standard-Entwicklungsbrowser Chrome Canary, Chrome Dev oder Chrome Beta. Diese Vorabversionen bieten Zugriff auf die neuesten DevTools-Funktionen, ermöglichen den Test moderner Webplattform-APIs und helfen Ihnen, Probleme auf Ihrer Website zu finden, bevor Ihre Nutzer sie bemerken.
Chrome-Entwicklertools-Team kontaktieren
Mit den folgenden Optionen können Sie über neue Funktionen, Updates oder andere Themen im Zusammenhang mit den DevTools sprechen.
- Senden Sie uns Feedback und Funktionsanfragen unter crbug.com.
- Melden Sie ein DevTools-Problem über das Dreipunkt-Menü Weitere Optionen > Hilfe > DevTools-Problem melden.
- Tweeten Sie an @ChromeDevTools.
- Hinterlassen Sie Kommentare unter den YouTube-Videos zu den Neuigkeiten in den DevTools oder den YouTube-Videos mit Tipps zu den DevTools.