Artikel ini memperkenalkan Pemeriksa Memori yang telah tersedia di Chrome 91. Fungsi ini memungkinkan Anda memeriksa ArrayBuffer, TypedArray, DataView, dan Memori Wasm Anda.
Pengantar
Pernah ingin memahami data dalam ArrayBuffer Anda? Sebelum Memory Inspector, DevTools hanya mengizinkan insight terbatas untuk ArrayBuffer. Pemeriksaan dari tampilan Cakupan selama sesi proses debug terbatas pada melihat daftar nilai tunggal dalam buffer array, yang menyulitkan pemahaman data secara keseluruhan. Sebagai contoh, tampilan Cakupan menampilkan buffer sebagai rentang array yang dapat diperluas dalam contoh di bawah ini:
Menavigasi ke rentang tertentu dalam buffer adalah poin masalah, yang mengharuskan pengguna men-scroll ke bawah untuk akhirnya mendapatkan indeks tersebut. Namun, meskipun menavigasi ke suatu posisi akan mudah, cara untuk inspecting nilai ini sebenarnya tidak praktis: sulit untuk mengetahui arti angka-angka tersebut. Terutama, bagaimana jika mereka seharusnya tidak ditafsirkan sebagai byte tunggal, tetapi misalnya sebagai Bilangan Bulat 32-bit?
Memeriksa nilai menggunakan Memory Inspector
Dengan Chrome 91, kami memperkenalkan Memory Inspector, yaitu alat untuk memeriksa buffer array. Anda mungkin pernah melihat alat inspeksi memori untuk melihat data biner, yang menampilkan konten biner dalam grid bersama alamatnya, dan yang menawarkan cara berbeda dalam menafsirkan nilai yang mendasarinya. Inilah yang dibawakan Pemeriksa Memori kepada Anda. Dengan Memory Inspector, Anda kini dapat melihat konten, menjelajahinya, dan memilih jenis yang akan digunakan untuk menafsirkan nilai yang ada. Kode ini menunjukkan nilai ASCII langsung di sebelah byte, dan memungkinkan pengguna untuk memilih endianness yang berbeda. Lihat cara kerja Pemeriksa Memori di bawah:
Ingin mencobanya? Untuk mempelajari cara membuka Memory Inspector dan melihat buffer array (atau TypedArray, DataView, atau Wasm Memory) serta informasi selengkapnya tentang cara menggunakannya, buka dokumentasi kami tentang Memory Inspector. Cobalah contoh mainan ini (untuk JS, Wasm, dan C++).
Mendesain Pemeriksa Memori
Di bagian ini, kita akan melihat bagaimana Memory Inspector dirancang menggunakan Komponen Web, dan kami akan menunjukkan salah satu tujuan desain yang kami miliki dan bagaimana kami menerapkannya. Jika Anda penasaran dan ingin melihat lebih banyak, lihat dokumen desain untuk Memory Inspector.
Anda mungkin pernah melihat postingan blog kami tentang Bermigrasi ke Komponen Web, di mana Jack telah memublikasikan panduan internal kami tentang cara membangun komponen UI menggunakan Komponen Web. Migrasi ke Komponen Web bertepatan dengan pekerjaan kami di Memory Inspector, dan sebagai hasilnya, kami memutuskan untuk mencoba sistem baru ini. Di bawah ini adalah diagram yang menunjukkan komponen yang telah kita buat untuk membuat Memory Inspector (perhatikan bahwa secara internal kita menyebutnya Linear Memory Inspector):
Komponen LinearMemoryInspector adalah komponen induk yang menggabungkan subkomponen yang mem-build semua elemen di Memory Inspector. Pada dasarnya, metode ini menggunakan Uint8Array dan address, dan pada setiap perubahan, metode ini menyebarkan data ke turunannya sehingga memicu rendering ulang. LinearMemoryInspector sendiri merender tiga subkomponen:
LinearMemoryViewer(menampilkan nilai),LinearMemoryNavigator(mengizinkan navigasi), danLinearMemoryValueInterpreter(menunjukkan interpretasi jenis yang berbeda dari data pokok).
Yang kedua adalah komponen induk itu sendiri, yang merender ValueInterpreterDisplay (menampilkan nilai), dan ValueInterpreterSettings (memilih jenis yang akan dilihat di tampilan).
Setiap komponen dirancang untuk hanya mewakili satu komponen kecil pada UI, sehingga komponen dapat digunakan kembali jika diperlukan. Setiap kali data baru ditetapkan pada komponen, rendering ulang akan dipicu, yang menunjukkan perubahan yang direfleksikan pada data yang ditetapkan pada komponen. Salah satu contoh alur kerja dengan komponen ditampilkan di bawah ini, saat pengguna mengubah alamat di kolom URL, yang memicu pembaruan dengan menyetel data baru, dalam hal ini alamat yang akan dilihat:
LinearMemoryInspector menambahkan dirinya sendiri sebagai pemroses di LinearMemoryNavigator. Fungsi addressChanged akan dipicu pada peristiwa address-changed. Segera setelah pengguna mengedit input alamat, tindakan ini akan mengirimkan peristiwa yang disebutkan di atas, sehingga fungsi addressChanged dipanggil. Fungsi ini kini menyimpan alamat secara internal, dan memperbarui subkomponennya menggunakan penyetel data(address, ..). Subkomponen menyimpan alamat secara internal dan merender ulang tampilannya, yang menunjukkan konten di alamat tertentu tersebut.
Tujuan desain: membuat performa dan konsumsi memori terpisah dari ukuran buffer
Salah satu aspek selama desain Memory Inspector yang kami ingat adalah bahwa performa Memory Inspector harus terpisah dari ukuran buffer.
Seperti yang telah Anda lihat di bagian sebelumnya, komponen LinearMemoryInspector memerlukan UInt8Array untuk merender nilai. Pada saat yang sama, kami ingin memastikan bahwa Memory Inspector tidak perlu menyimpan seluruh data, karena Memory Inspector hanya menampilkan sebagian dari data tersebut (misalnya Wasm Memory dapat sebesar 4GB, dan kami tidak ingin menyimpan 4GB dalam Memory Inspector).
Jadi, untuk memastikan bahwa kecepatan dan konsumsi memori Memory Inspector tidak bergantung pada buffer aktual yang kita tampilkan, kita membiarkan komponen LinearMemoryInspector hanya menyimpan subrange dari buffer asli.
Agar ini berfungsi, LinearMemoryInspector pertama-tama harus menggunakan dua argumen lagi: memoryOffset dan outerMemoryLength. memoryOffset menunjukkan offset, tempat Uint8Array yang diteruskan dimulai, dan diperlukan untuk merender alamat data yang benar. outerMemoryLength adalah panjang buffer asli, dan diperlukan untuk memahami rentang yang dapat ditampilkan:
Dengan informasi ini, kita dapat memastikan bahwa kita masih dapat merender tampilan yang sama seperti sebelumnya (konten di sekitar address), tanpa benar-benar memiliki semua data. Jadi apa yang harus dilakukan jika ada alamat berbeda yang diminta, yang termasuk dalam rentang yang berbeda? Dalam hal ini, LinearMemoryInspector memicu RequestMemoryEvent, yang memperbarui rentang saat ini yang disimpan; contohnya ditampilkan di bawah ini:
Dalam contoh ini, pengguna membuka halaman memori (Memory Inspector menggunakan paging untuk menampilkan potongan data), yang memicu PageNavigationEvent, yang memicu RequestMemoryEvent.
Peristiwa tersebut memulai pengambilan rentang baru, yang kemudian disebarkan ke komponen LinearMemoryInspector melalui setelan data. Hasilnya, kami menampilkan data yang baru diambil.
Oh, dan tahukah kamu? Anda bahkan dapat memeriksa memori dalam kode Wasm dan C/C++
Memory Inspector tidak hanya tersedia untuk ArrayBuffers di JavaScript, tetapi juga dapat digunakan untuk memeriksa Wasm Memory dan memori yang ditunjuk oleh referensi/pointer C/C++ (menggunakan ekstensi DWARF - cobalah jika Anda belum melakukannya. Lihat Men-debug WebAssembly dengan alat modern di sini. Tampilan kecil Memory Inspector saat proses debug native C++ di web:
Kesimpulan
Artikel ini menyajikan Memory Inspector dan menunjukkan sekilas desainnya. Kami harap Memory Inspector akan membantu Anda memahami apa yang terjadi di ArrayBuffer :-). Jika Anda memiliki saran untuk meningkatkannya, beri tahu kami dan laporkan bug!
Mendownload saluran pratinjau
Pertimbangkan untuk menggunakan Chrome Canary, Dev, atau Beta sebagai browser pengembangan default Anda. Saluran pratinjau ini memberi Anda akses ke fitur DevTools terbaru, menguji API platform web tercanggih, dan menemukan masalah di situs Anda sebelum pengguna melakukannya.
Menghubungi tim Chrome DevTools
Gunakan opsi berikut untuk membahas fitur dan perubahan baru di postingan, atau hal lain yang berkaitan dengan DevTools.
- Kirim saran atau masukan kepada kami melalui crbug.com.
- Laporkan masalah DevTools menggunakan Opsi lainnya
> Bantuan > Laporkan masalah DevTools di DevTools. - Tweet di @ChromeDevTools.
- Berikan komentar di video YouTube Apa yang baru di DevTools atau video YouTube Tips DevTools.