Cet article présente l'outil d'inspection de mémoire qui est disponible dans Chrome 91. Il vous permet d'inspecter vos objets ArrayBuffer, TypedArray, DataView et Wasm.
Introduction
Vous avez toujours rêvé de donner un sens aux données de votre ArrayBuffer ? Avant l'outil d'inspection de mémoire, les outils de développement ne permettaient d'obtenir qu'un aperçu limité des ArrayBuffers. L'inspection à partir de la vue Champ d'application lors d'une session de débogage se limitait à l'affichage d'une liste de valeurs uniques dans le tampon du tableau, ce qui rendait difficile l'interprétation des données dans leur ensemble. Par exemple, la vue Scope affiche le tampon sous la forme de plages de tableaux extensibles dans l'exemple ci-dessous:
Accéder à une certaine plage dans le tampon constituait une difficulté, car l'utilisateur devait faire défiler la page vers le bas pour accéder enfin à cet index. Cependant, même s'il est facile d'accéder à une position, cette méthode d'inspecting des valeurs est fastidieuse: il est difficile de déterminer la signification de ces chiffres. Surtout, que se passe-t-il s'ils ne doivent pas être interprétés comme des octets uniques, mais comme des entiers 32 bits ?
Inspecter des valeurs à l'aide de l'outil d'inspection de mémoire
Avec Chrome 91, nous lançons l'outil d'inspection de mémoire, un outil permettant d'inspecter les tampons de tableau. Vous avez peut-être déjà vu des outils d'inspection de la mémoire permettant d'afficher des données binaires, qui affichent le contenu binaire dans une grille avec leurs adresses et offrent différentes façons d'interpréter les valeurs sous-jacentes. Voici les informations fournies par l'outil d'inspection de mémoire. Avec l'outil d'inspection de mémoire, vous pouvez désormais afficher le contenu, le parcourir et sélectionner les types à utiliser pour interpréter les valeurs concernées. Il affiche les valeurs ASCII directement à côté des octets et permet à l'utilisateur de sélectionner un objectif différent. Découvrez l'outil d'inspection de mémoire ci-dessous:
Pour essayer, Pour savoir comment ouvrir l'outil d'inspection de mémoire et afficher le tampon de votre tableau (ou TypedArray, DataView ou Wasm Memory), et pour en savoir plus sur son utilisation, consultez notre documentation sur l'outil d'inspection de mémoire. Essayez-le avec ces exemples de jouets (pour JS, Wasm et C++).
Concevoir l'outil d'inspection de mémoire
Dans cette partie, nous verrons comment l'outil d'inspection de mémoire est conçu à l'aide de composants Web, puis nous vous présenterons l'un de nos objectifs de conception et la façon dont nous l'avons mis en œuvre. Si vous souhaitez en savoir plus, consultez notre document de conception pour l'outil d'inspection de mémoire.
Vous avez peut-être lu notre article de blog sur la migration vers les composants Web, dans lequel Jack a publié notre guide interne sur la création de composants d'interface utilisateur à l'aide de composants Web. La migration vers les composants Web a coïncidé avec notre travail sur l'outil d'inspection de mémoire. Nous avons donc décidé d'essayer le nouveau système. Le schéma ci-dessous présente les composants que nous avons créés pour créer l'outil d'inspection de mémoire (notez que nous l'appelons en interne l'outil d'inspection de mémoire linéaire):
Le composant LinearMemoryInspector est le composant parent qui combine les sous-composants qui constituent tous les éléments de l'outil d'inspection de mémoire. Il utilise essentiellement un Uint8Array et un address, et, à chaque modification, il propage les données à ses enfants, ce qui déclenche un nouveau rendu. Le LinearMemoryInspector lui-même affiche trois sous-composants:
LinearMemoryViewer(affichage des valeurs),LinearMemoryNavigator(permettant la navigation) etLinearMemoryValueInterpreter(affichage de différentes interprétations de type des données sous-jacentes).
Ce dernier est lui-même un composant parent, qui affiche le ValueInterpreterDisplay (affichage des valeurs) et le ValueInterpreterSettings (qui sélectionne les types à afficher).
Chacun des composants est conçu pour ne représenter qu'un seul petit composant de l'interface utilisateur, de sorte qu'il puisse être réutilisé si nécessaire. Chaque fois que de nouvelles données sont définies sur un composant, un nouveau rendu est déclenché, ce qui montre la modification apportée aux données définies dans le composant. Vous trouverez ci-dessous un exemple de workflow avec nos composants. L'utilisateur modifie l'adresse dans la barre d'adresse, ce qui déclenche une mise à jour en définissant les nouvelles données (dans ce cas, l'adresse à afficher) :
Le LinearMemoryInspector s'ajoute en tant qu'écouteur sur le LinearMemoryNavigator. La fonction addressChanged doit être déclenchée lors d'un événement address-changed. Dès que l'utilisateur modifie l'entrée d'adresse, l'événement susmentionné est envoyé, de sorte que la fonction addressChanged est appelée. Cette fonction enregistre maintenant l'adresse en interne et met à jour ses sous-composants à l'aide du setter data(address, ..). Les sous-composants enregistrent l'adresse en interne et affichent à nouveau leurs vues, montrant le contenu à cette adresse particulière.
Objectif de conception: rendre les performances et la consommation de mémoire indépendantes de la taille de la mémoire tampon
Lors de la conception de l'outil d'inspection de mémoire, nous avions pensé que ses performances devaient être indépendantes de la taille de la mémoire tampon.
Comme vous l'avez vu dans la partie précédente, le composant LinearMemoryInspector utilise un élément UInt8Array pour afficher les valeurs. Nous voulions également nous assurer que l'outil d'inspection de mémoire n'aurait pas besoin de conserver l'intégralité des données, car il n'en montre qu'une partie (par exemple, la mémoire Wasm peut atteindre 4 Go, et nous ne voulons pas stocker 4 Go dans l'outil d'inspection de mémoire).
Ainsi, pour nous assurer que la vitesse et la consommation de mémoire de l'outil d'inspection de mémoire sont indépendantes du tampon réel que nous affichons, nous laissons au composant LinearMemoryInspector ne conserver qu'une sous-plage du tampon d'origine.
Pour que cela fonctionne, LinearMemoryInspector doit d'abord accepter deux autres arguments: memoryOffset et outerMemoryLength. memoryOffset indique le décalage à partir duquel l'Uint8Array transmis commence, et est nécessaire pour afficher les adresses de données correctes. outerMemoryLength est la longueur du tampon d'origine. Elle est nécessaire pour comprendre la plage que nous pouvons afficher:
Grâce à ces informations, nous pouvons faire en sorte d'afficher la même vue qu'auparavant (le contenu autour de address), sans avoir toutes les données en place. Que faire si une adresse différente est demandée, mais qu'elle appartient à une plage différente ? Dans ce cas, LinearMemoryInspector déclenche une RequestMemoryEvent, qui met à jour la plage actuelle qui est conservée. Voici un exemple:
Dans cet exemple, l'utilisateur parcourt la page de la mémoire (l'outil d'inspection de mémoire utilise la pagination pour afficher des fragments de données), ce qui déclenche une PageNavigationEvent, qui déclenche elle-même une RequestMemoryEvent.
Cet événement lance la récupération de la nouvelle plage, qui est ensuite propagée au composant LinearMemoryInspector via la définition des données. Par conséquent, nous affichons les données nouvellement récupérées.
Oh, et le saviez-vous ? Vous pouvez même inspecter la mémoire dans les codes Wasm et C/C++
L'outil d'inspection de mémoire n'est pas seulement disponible pour ArrayBuffers en JavaScript, mais il peut également être utilisé pour inspecter la mémoire Wasm et la mémoire vers laquelle les références/pointeurs C/C++ font référence (à l'aide de notre extension DWARF. Si vous ne l'avez pas encore fait, essayez-la). Consultez Déboguer WebAssembly avec des outils modernes. Aperçu de l'outil d'inspection de mémoire pour le débogage natif de C++ sur le Web:
Conclusion
Cet article présentait l'outil d'inspection de mémoire et en donnait un aperçu. Nous espérons que l'outil d'inspection de mémoire vous aidera à comprendre ce qui se passe dans votre ArrayBuffer :-). Si vous avez des suggestions d'amélioration, n'hésitez pas à nous contacter et à signaler un bug.
Télécharger les canaux de prévisualisation
Nous vous conseillons d'utiliser Chrome Canary, Dev ou Beta comme navigateur de développement par défaut. Ces versions preview vous permettent d'accéder aux dernières fonctionnalités des outils de développement, de tester des API de pointe de plates-formes Web et de détecter les problèmes sur votre site avant qu'ils ne le fassent.
Contacter l'équipe des outils pour les développeurs Chrome
Utilisez les options suivantes pour discuter des nouvelles fonctionnalités et des modifications dans l'article, ou de toute autre question concernant les outils de développement.
- Envoyez-nous une suggestion ou des commentaires via crbug.com.
- Signalez un problème dans les outils de développement via Plus d'options
> Aide > Signaler un problème dans les outils de développement dans les Outils de développement. - Envoyez un tweet à @ChromeDevTools.
- Dites-nous en plus sur les nouveautés concernant les vidéos YouTube dans les outils de développement ou sur les vidéos YouTube de nos conseils relatifs aux outils de développement.