In diesem Artikel wird der Memory Inspector vorgestellt, der in Chrome 91 eingeführt wurde. Damit können Sie ArrayBuffer, TypedArray, DataView und Wasm Memory überprüfen.
Einleitung
Wollten Sie schon einmal die Daten in Ihrem ArrayBuffer verstehen? Vor dem Memory Inspector ermöglichten die Entwicklertools nur begrenzte Einblicke in ArrayBuffers. Bei der Prüfung in der Ansicht Umfang während einer Fehlerbehebungssitzung konnte nur eine Liste einzelner Werte im Arrayzwischenspeicher aufgerufen werden, was es schwierig machte, den Gesamteindruck der Daten zu verstehen. Im folgenden Beispiel ist in der Ansicht Scope (Bereich) der Zwischenspeicher als maximierbare Bereiche von Arrays zu sehen:
Das Navigieren zu einem bestimmten Bereich innerhalb des Puffers war ein Problem, da die Nutzenden nach unten scrollen mussten, um zu diesem Index zu gelangen. Aber selbst wenn das Navigieren zu einer Position einfach wäre, ist diese Art der inspecting der Werte umständlich: Es ist schwierig zu erkennen, was diese Zahlen bedeuten. Was, wenn sie nicht als einzelne Byte, sondern z.B. als 32-Bit-Ganzzahlen interpretiert werden sollen?
Werte mit dem Memory Inspector prüfen
In Chrome 91 führen wir den Memory Inspector ein, ein Tool zur Überprüfung von Array-Zwischenspeichern. Vielleicht haben Sie schon Speicherinspektionstools gesehen, mit denen Binärdaten angezeigt werden. Diese zeigen den binären Inhalt zusammen mit ihren Adressen in einem Raster an und bieten verschiedene Möglichkeiten zur Interpretation der zugrunde liegenden Werte. Das bietet Ihnen der Memory Inspector. Mit dem Memory Inspector können Sie jetzt den Inhalt anzeigen, darin navigieren und Typen auswählen, die zur Interpretation der vorhandenen Werte verwendet werden sollen. Sie zeigt die ASCII-Werte direkt neben den Byte an und ermöglicht es dem Nutzer, verschiedene Endianness auszuwählen. Unten sehen Sie den Memory Inspector in Aktion:
Möchten Sie es einmal ausprobieren? Informationen zum Öffnen des Memory Inspectors und zum Anzeigen des Array-Zwischenspeichers (oder TypedArray, DataView oder Wasm Memory) sowie zu dessen Verwendung finden Sie in unserer Dokumentation zum Memory Inspector. Probieren Sie diese Spielzeugbeispiele aus (für JS, Wasm und C++).
Memory Inspector entwerfen
In diesem Teil sehen wir uns an, wie der Memory Inspector mithilfe von Webkomponenten entwickelt wird. Außerdem zeigen wir eines unserer Designziele und wie wir ihn implementiert haben. Weitere Informationen finden Sie in unserem Designdokument zum Memory Inspector.
Vielleicht haben Sie unseren Blogpost zur Migration zu Webkomponenten gelesen, in dem Jack unseren internen Leitfaden zum Erstellen von UI-Komponenten mit Webkomponenten veröffentlicht hat. Die Migration zu den Webkomponenten fiel mit unserer Arbeit am Memory Inspector ein, sodass wir beschlossen haben, das neue System zu testen. Das folgende Diagramm zeigt die Komponenten, die wir zum Erstellen des Memory Inspector erstellt haben (beachten Sie, dass wir ihn intern Linear Memory Inspector nennen):
Die LinearMemoryInspector-Komponente ist die übergeordnete Komponente, die die Unterkomponenten kombiniert, aus denen alle Elemente im Memory Inspector bestehen. Grundsätzlich werden ein Uint8Array und ein address verwendet. Bei jeder Änderung werden die Daten an die untergeordneten Elemente weitergegeben, wodurch ein erneutes Rendering ausgelöst wird. LinearMemoryInspector selbst rendert drei Unterkomponenten:
LinearMemoryViewer(zeigt die Werte) an,LinearMemoryNavigator(für die Navigation) undLinearMemoryValueInterpreter(zeigt verschiedene Typinterpretationen der zugrunde liegenden Daten an).
Letztere ist selbst eine übergeordnete Komponente, die das ValueInterpreterDisplay (zeigt die Werte) und das ValueInterpreterSettings (zur Auswahl der Typen, die auf der Anzeige angezeigt werden) rendert.
Jede der Komponenten ist nur so konzipiert, dass sie nur eine kleine Komponente der Benutzeroberfläche darstellt, sodass Komponenten bei Bedarf wiederverwendet werden können. Wenn für eine Komponente neue Daten festgelegt werden, wird ein erneutes Rendering ausgelöst, bei dem die für die Komponente festgelegte Änderung berücksichtigt wird. Im Folgenden sehen Sie ein Beispiel für einen Workflow mit unseren Komponenten, bei dem der Nutzer die Adresse in der Adressleiste ändert. Dadurch wird eine Aktualisierung ausgelöst, indem die neuen Daten festgelegt werden, in diesem Fall die anzuzeigende Adresse:
LinearMemoryInspector fügt sich selbst als Listener zu LinearMemoryNavigator hinzu. Die Funktion addressChanged soll durch ein address-changed-Ereignis ausgelöst werden. Sobald der Nutzer die Adresseingabe bearbeitet, wird das oben genannte Ereignis gesendet, sodass die Funktion addressChanged aufgerufen wird. Diese Funktion speichert jetzt die Adresse intern und aktualisiert ihre Unterkomponenten mithilfe eines data(address, ..)-Setters. Die Unterkomponenten speichern die Adresse intern und stellen ihre Ansichten erneut dar, um die Inhalte unter dieser bestimmten Adresse anzuzeigen.
Designziel: Leistung und Arbeitsspeicherverbrauch unabhängig von der Puffergröße gestalten
Beim Design des Memory Inspector haben wir unter anderem daran gedacht, dass die Leistung des Memory Inspector unabhängig von der Puffergröße sein sollte.
Wie Sie im vorherigen Teil gesehen haben, benötigt die LinearMemoryInspector-Komponente eine UInt8Array, um die Werte zu rendern. Gleichzeitig wollten wir sicherstellen, dass der Memory Inspector nicht die gesamten Daten bereithalten muss, da er nur einen Teil davon anzeigt. Wasm-Arbeitsspeicher kann beispielsweise 4 GB groß sein und wir möchten im Memory Inspector keine 4 GB speichern.
Um sicherzustellen, dass Geschwindigkeit und Speicherverbrauch des Memory Inspector unabhängig vom tatsächlich gezeigten Puffer sind, lässt die LinearMemoryInspector-Komponente nur einen Teilbereich des ursprünglichen Zwischenspeichers beibehalten.
Damit dies funktioniert, muss das erste LinearMemoryInspector-Objekt zwei weitere Argumente annehmen: memoryOffset und outerMemoryLength. Der memoryOffset gibt den Offset an, bei dem das übergebene Uint8Array beginnt, und ist erforderlich, um die richtigen Datenadressen zu rendern. outerMemoryLength ist die Länge des ursprünglichen Zwischenspeichers und ist erforderlich, um zu verstehen, welchen Bereich angezeigt werden kann:
Mit diesen Informationen können wir sicherstellen, dass wir weiterhin dieselbe Ansicht wie zuvor (die Inhalte um address herum) rendern können, ohne dass tatsächlich alle Daten vorhanden sind. Was ist also zu tun, wenn eine andere Adresse angefordert wird, die in einen anderen Bereich fällt? In diesem Fall löst LinearMemoryInspector ein RequestMemoryEvent aus, das den aktuell beibehaltenen Bereich aktualisiert. Hier ein Beispiel:
In diesem Beispiel navigiert der Nutzer auf der Speicherseite (der Memory Inspector verwendet Paging zum Anzeigen von Datenblöcken), wodurch ein PageNavigationEvent ausgelöst wird, das selbst ein RequestMemoryEvent auslöst.
Mit diesem Ereignis wird der neue Bereich abgerufen, der dann durch Festlegen der Daten an die Komponente LinearMemoryInspector weitergegeben wird. Daraufhin werden die neu abgerufenen Daten angezeigt.
Ah, und wussten Sie das? Sie können sogar den Arbeitsspeicher in Wasm- und C-/C++-Code prüfen.
Der Memory Inspector ist nicht nur für ArrayBuffers in JavaScript verfügbar, sondern kann auch zum Untersuchen des Wasm-Arbeitsspeichers und des Arbeitsspeichers verwendet werden, auf den C/C++-Referenzen/Zeiger verweisen (mit unserer DWARF-Erweiterung – probier ihn aus, falls du das noch nicht getan hast! Weitere Informationen finden Sie unter Debugging von WebAssembly mit modernen Tools. Ein kleiner Ausblick auf den Memory Inspector in Aktion für das native Debugging von C++ im Web:
Fazit
In diesem Artikel wurde der Memory Inspector vorgestellt und es gab einen Einblick in sein Design. Wir hoffen, dass der Memory Inspector Ihnen hilft, die Vorgänge in ArrayBuffer zu verstehen. Wenn Sie Verbesserungsvorschläge haben, lassen Sie es uns wissen und melden Sie den Fehler.
Vorschaukanäle herunterladen
Sie können Chrome Canary, Dev oder Beta als Standardbrowser für die Entwicklung verwenden. Über diese Vorschaukanäle erhältst du Zugriff auf die neuesten Entwicklertools-Funktionen, kannst neue Webplattform-APIs testen und Probleme auf deiner Website erkennen, bevor deine Nutzer es tun.
Chrome-Entwicklertools-Team kontaktieren
Verwende die folgenden Optionen, um die neuen Funktionen und Änderungen im Beitrag oder andere Themen im Zusammenhang mit den Entwicklertools zu besprechen.
- Sende uns über crbug.com Vorschläge oder Feedback.
- Wenn du ein Problem mit den Entwicklertools melden möchtest, klicke in den Entwicklertools auf Weitere Optionen
> Hilfe > Probleme mit den Entwicklertools melden. - Senden Sie einen Tweet an @ChromeDevTools.
- Hinterlasse Kommentare zu den Neuheiten in den Entwicklertools YouTube-Videos oder YouTube-Videos in den Entwicklertools-Tipps.