Cet article présente l'outil d'inspection de la mémoire disponible dans Chrome 91. Il vous permet d'inspecter votre ArrayBuffer, TypedArray, DataView et mémoire Wasm.
Introduction
Avez-vous déjà voulu donner du sens aux données de votre ArrayBuffer ? Avant l'outil d'inspection de la mémoire, DevTools ne permettait qu'une visibilité limitée sur les ArrayBuffers. L'inspection de la vue Champ d'application lors d'une session de débogage était limitée à l'affichage d'une liste de valeurs uniques dans le tampon de tableau, ce qui rendait difficile l'interprétation des données dans leur ensemble. Par exemple, dans l'exemple ci-dessous, la vue Champ d'application affiche la mémoire tampon sous forme de plages de tableaux extensibles:
Il était difficile de naviguer vers une certaine plage dans le tampon, car l'utilisateur devait faire défiler l'écran vers le bas pour accéder à cet indice. Mais même si accéder à une position est facile, cette façon d'inspecter les valeurs est fastidieuse: il est difficile de savoir ce que ces chiffres signifient. En particulier, que se passe-t-il s'ils ne doivent pas être interprétés comme des octets uniques, mais par exemple comme des entiers 32 bits ?
Inspecter les valeurs à l'aide de l'outil d'inspection de la mémoire
Avec Chrome 91, nous lançons l'outil Memory Inspector, qui permet d'inspecter les tampons de tableaux. Vous avez peut-être déjà vu des outils d'inspection de la mémoire pour afficher des données binaires. Ils affichent le contenu binaire dans une grille avec leurs adresses et proposent différentes façons d'interpréter les valeurs sous-jacentes. C'est ce que l'outil d'inspection de la mémoire vous propose. L'outil d'inspection de la mémoire vous permet désormais d'afficher le contenu, de le parcourir et de sélectionner les types à utiliser pour interpréter les valeurs disponibles. Il affiche les valeurs ASCII directement à côté des octets et permet à l'utilisateur de sélectionner un ordre de bytes différent. Découvrez l'outil d'inspection de la mémoire en action ci-dessous:
Pour essayer, Pour savoir comment ouvrir l'outil d'inspection de la mémoire et afficher votre tampon de tableau (ou TypedArray, DataView ou mémoire Wasm), et pour en savoir plus sur son utilisation, consultez notre documentation sur l'outil d'inspection de la mémoire. Essayez ces exemples (pour JS, Wasm et C++).
Concevoir l'outil d'inspection de la mémoire
Dans cette partie, nous allons voir comment l'outil d'inspection de la mémoire est conçu à l'aide de composants Web. Nous présenterons également l'un des objectifs de conception que nous avions et la façon dont nous l'avons implémenté. Si vous souhaitez en savoir plus, consultez notre document de conception pour l'outil d'inspection de la 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'inspecteur de mémoire. Nous avons donc décidé d'essayer le nouveau système. Vous trouverez ci-dessous un schéma illustrant les composants que nous avons créés pour créer l'outil d'inspection de la mémoire (notez qu'en interne, nous l'appelons Linear Memory Inspector):
Le composant LinearMemoryInspector est le composant parent qui combine les sous-composants qui constituent tous les éléments de l'outil d'inspection de la mémoire. Il prend essentiellement un Uint8Array et un address, et à chaque modification de l'un d'eux, il propage les données à ses enfants, ce qui déclenche un nouveau rendu. LinearMemoryInspector génère lui-même trois sous-composants:
LinearMemoryViewer(affiche les valeurs) ;LinearMemoryNavigator(permettant la navigation) ;LinearMemoryValueInterpreter(affichant différentes interprétations de type des données sous-jacentes).
Ce dernier est lui-même un composant parent, qui génère le ValueInterpreterDisplay (qui affiche les valeurs) et le ValueInterpreterSettings (qui sélectionne les types à afficher).
Chacun des composants est conçu pour ne représenter qu'un petit élément de l'UI, de sorte que les composants puissent être réutilisés si nécessaire. Chaque fois que de nouvelles données sont définies sur un composant, un nouveau rendu est déclenché, ce qui reflète le changement sur les données définies sur le composant. Un exemple de workflow avec nos composants est présenté ci-dessous. 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) :
LinearMemoryInspector s'ajoute en tant qu'écouteur sur LinearMemoryNavigator. La fonction addressChanged doit être déclenchée sur un événement address-changed. Dès que l'utilisateur modifie la saisie d'adresse, l'événement mentionné ci-dessus est envoyé, de sorte que la fonction addressChanged soit appelée. Cette fonction enregistre désormais l'adresse en interne et met à jour ses sous-composants à l'aide d'un setter data(address, ..). Les sous-composants enregistrent l'adresse en interne et réaffichent leurs vues, affichant le contenu à cette adresse spécifique.
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 la mémoire, nous avons tenu compte du fait 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 UInt8Array pour afficher les valeurs. Nous voulions également nous assurer que l'outil d'inspection de la mémoire n'avait pas besoin de conserver l'intégralité des données, car il n'en affiche qu'une partie (par exemple, la mémoire Wasm peut atteindre 4 Go, et nous ne souhaitons pas stocker 4 Go dans l'outil d'inspection de la mémoire).
Pour nous assurer que la vitesse et la consommation de mémoire de l'outil d'inspection de la mémoire sont indépendantes du tampon réel que nous affichons, nous laissons le composant LinearMemoryInspector conserver uniquement une sous-plage du tampon d'origine.
Pour que cela fonctionne, LinearMemoryInspector doit d'abord prendre deux autres arguments: un memoryOffset et un 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 correspond à la longueur du tampon d'origine et est nécessaire pour déterminer la plage que nous pouvons afficher:
Grâce à ces informations, nous pouvons nous assurer de pouvoir toujours afficher la même vue qu'auparavant (le contenu autour de address), sans avoir toutes les données en place. Que faire si une autre adresse, appartenant à une autre plage, est demandée ? Dans ce cas, LinearMemoryInspector déclenche un RequestMemoryEvent, qui met à jour la plage actuelle conservée. Un exemple est présenté ci-dessous:
Dans cet exemple, l'utilisateur navigue sur la page de mémoire (l'outil d'inspection de la mémoire utilise la pagination pour afficher des blocs de données), ce qui déclenche un PageNavigationEvent, qui déclenche à son tour un RequestMemoryEvent.
Cet événement lance la récupération de la nouvelle plage, qui est ensuite propagée au composant LinearMemoryInspector en définissant les données. Nous affichons donc les données nouvellement extraites.
Saviez-vous que ? Vous pouvez même inspecter la mémoire dans le code Wasm et C/C++.
L'outil d'inspection de la mémoire n'est pas seulement disponible pour ArrayBuffers en JavaScript, mais peut également être utilisé pour inspecter la mémoire Wasm et la mémoire pointée par des références/pointeurs C/C++ (à l'aide de notre extension DWARF. Essayez-la si vous ne l'avez pas encore fait !) Pour en savoir plus, consultez Déboguer WebAssembly avec des outils modernes. Voici un aperçu de l'outil d'inspection de la mémoire en action pour le débogage natif du C++ sur le Web:
Conclusion
Cet article a présenté l'outil d'inspection de la mémoire et donné un aperçu de sa conception. Nous espérons que l'outil d'inspection de la mémoire vous aidera à comprendre ce qui se passe dans votre ArrayBuffer. :-) Si vous avez des suggestions pour l'améliorer, n'hésitez pas à nous en faire part et à signaler un bug.
Télécharger les canaux de prévisualisation
Envisagez d'utiliser Chrome Canary, Dev ou Bêta comme navigateur de développement par défaut. Ces canaux de prévisualisation vous donnent accès aux dernières fonctionnalités de DevTools, vous permettent de tester les API de plate-forme Web de pointe et vous aident à détecter les problèmes sur votre site avant vos utilisateurs.
Contacter l'équipe des outils pour les développeurs Chrome
Utilisez les options suivantes pour discuter des nouvelles fonctionnalités, des mises à jour ou de tout autre élément lié aux outils pour les développeurs.
- Envoyez-nous vos commentaires et vos demandes de fonctionnalités sur crbug.com.
- Signalez un problème dans les outils de développement à l'aide de l'icône Plus d'options > Aide > Signaler un problème dans les outils de développement dans les outils de développement.
- Envoyez un tweet à @ChromeDevTools.
- Laissez des commentaires sur les vidéos YouTube sur les nouveautés des outils pour les développeurs ou sur les vidéos YouTube sur les conseils concernant les outils pour les développeurs.