ถนนจนถึงตอนนี้
เมื่อ 1 ปีที่แล้ว Chrome ได้ประกาศการรองรับเบื้องต้น สำหรับการแก้ไขข้อบกพร่อง WebAssembly แบบเนทีฟใน Chrome DevTools
เราได้สาธิตการสนับสนุนขั้นพื้นฐานและพูดเกี่ยวกับโอกาสในการใช้ข้อมูล DWARF แทนการเปิดแผนที่แหล่งที่มาในอนาคต
- การค้นหาชื่อตัวแปร
- รูปแบบการพิมพ์
- การประเมินนิพจน์ในภาษาต้นฉบับ
- ...และอีกมากมาย
วันนี้เรายินดีที่จะได้นำเสนอฟีเจอร์ตามที่สัญญาใช้จริง และความคืบหน้าที่ทีม Emscripten และ Chrome DevTools ดำเนินการในปีนี้ โดยเฉพาะสำหรับแอป C และ C++
ก่อนเริ่มต้น โปรดทราบว่าประสบการณ์ใหม่นี้ยังเป็นเวอร์ชันเบต้าอยู่ คุณต้องยอมรับความเสี่ยงจากการใช้เครื่องมือเวอร์ชันล่าสุดทั้งหมดเอง และหากพบปัญหาใดๆ โปรดรายงานไปที่ https://bugs.chromium.org/p/chromium/issues/entry?template=DevTools+issue
เรามาเริ่มด้วยตัวอย่าง C ง่ายๆ เหมือนครั้งที่แล้ว:
#include <stdlib.h>
void assert_less(int x, int y) {
if (x >= y) {
abort();
}
}
int main() {
assert_less(10, 20);
assert_less(30, 20);
}
ในการรวบรวม เราจะใช้ Last Emscripten และส่งผ่านแฟล็ก -g
เช่นเดียวกับโพสต์ต้นฉบับเพื่อรวมข้อมูลการแก้ไขข้อบกพร่อง ดังนี้
emcc -g temp.c -o temp.html
ตอนนี้เราแสดงหน้าที่สร้างขึ้นจากเซิร์ฟเวอร์ HTTP localhost ได้แล้ว (เช่น แสดงด้วย serve) และเปิดหน้าดังกล่าวใน Chrome Canary เวอร์ชันล่าสุด
และครั้งนี้เราต้องการส่วนขยายผู้ช่วยที่ผสานรวมกับ Chrome DevTools และช่วยให้เข้าใจข้อมูลการแก้ไขข้อบกพร่องทั้งหมดที่เข้ารหัสในไฟล์ WebAssembly โปรดติดตั้งโดยไปที่ ลิงก์ goo.gle/wasm-debugging-extension
คุณจะต้องเปิดใช้การแก้ไขข้อบกพร่องของ WebAssembly ในการทดสอบเครื่องมือสำหรับนักพัฒนาเว็บด้วย เปิดเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome คลิกไอคอนรูปเฟือง (⚙) ที่มุมขวาบนของแผงเครื่องมือสำหรับนักพัฒนาเว็บ ไปที่แผงการทดสอบ แล้วเลือกการแก้ไขข้อบกพร่องของ WebAssembly: เปิดใช้การรองรับ DWARF
เมื่อปิดการตั้งค่า เครื่องมือสำหรับนักพัฒนาเว็บจะแนะนำให้โหลดตัวเองซ้ำเพื่อใช้การตั้งค่า ดังนั้นมาทำกันเลย และนั่นคือการตั้งค่าแบบครั้งเดียว
ตอนนี้เราสามารถกลับไปที่แผงแหล่งที่มา เปิดใช้หยุดชั่วคราวเมื่อข้อยกเว้น (ไอคอน ⏸) จากนั้นเลือกหยุดชั่วคราวเมื่อข้อยกเว้นที่พบ แล้วโหลดหน้าเว็บซ้ำ คุณควรเห็นเครื่องมือสำหรับนักพัฒนาเว็บหยุดชั่วคราวจากข้อยกเว้นต่อไปนี้
โดยค่าเริ่มต้น โค้ดจะหยุดบนโค้ดกาวที่สร้างโดย Emscripten แต่ทางด้านขวา คุณจะเห็นมุมมอง Call Stack ที่แสดงถึงสแต็กเทรซข้อผิดพลาด และไปยังบรรทัด C เดิมที่เรียกใช้ abort
ตอนนี้ หากดูในมุมมองขอบเขต คุณจะเห็นชื่อเดิมและค่าของตัวแปรในโค้ด C/C++ และไม่จำเป็นต้องทราบว่าชื่อที่เปลี่ยนแปลงอย่างไร เช่น $localN
มีความหมายว่าอย่างไร และดูว่าชื่อเหล่านั้นเกี่ยวข้องกับซอร์สโค้ดที่คุณเขียนอย่างไร
วิธีนี้ไม่ได้ใช้กับค่าพื้นฐาน เช่น จำนวนเต็มเท่านั้น แต่ยังมีผลกับประเภทสารประกอบ เช่น โครงสร้าง คลาส อาร์เรย์ ฯลฯ ด้วย
การรองรับ Rich type
มาดูตัวอย่างที่ซับซ้อนมากขึ้นกัน คราวนี้เราจะวาดเศษส่วน Mandelbrot ด้วยโค้ด C++ ต่อไปนี้
#include <SDL2/SDL.h>
#include <complex>
int main() {
// Init SDL.
int width = 600, height = 600;
SDL_Init(SDL_INIT_VIDEO);
SDL_Window* window;
SDL_Renderer* renderer;
SDL_CreateWindowAndRenderer(width, height, SDL_WINDOW_OPENGL, &window,
&renderer);
// Generate a palette with random colors.
enum { MAX_ITER_COUNT = 256 };
SDL_Color palette[MAX_ITER_COUNT];
srand(time(0));
for (int i = 0; i < MAX_ITER_COUNT; ++i) {
palette[i] = {
.r = (uint8_t)rand(),
.g = (uint8_t)rand(),
.b = (uint8_t)rand(),
.a = 255,
};
}
// Calculate and draw the Mandelbrot set.
std::complex<double> center(0.5, 0.5);
double scale = 4.0;
for (int y = 0; y < height; y++) {
for (int x = 0; x < width; x++) {
std::complex<double> point((double)x / width, (double)y / height);
std::complex<double> c = (point - center) * scale;
std::complex<double> z(0, 0);
int i = 0;
for (; i < MAX_ITER_COUNT - 1; i++) {
z = z * z + c;
if (abs(z) > 2.0)
break;
}
SDL_Color color = palette[i];
SDL_SetRenderDrawColor(renderer, color.r, color.g, color.b, color.a);
SDL_RenderDrawPoint(renderer, x, y);
}
}
// Render everything we've drawn to the canvas.
SDL_RenderPresent(renderer);
// SDL_Quit();
}
คุณจะเห็นว่าแอปพลิเคชันนี้ยังมีขนาดเล็กอยู่เพราะเป็นไฟล์เดียวที่มีโค้ด 50 บรรทัด แต่คราวนี้ผมใช้ API ภายนอกบางส่วน เช่น ไลบรารี SDL สำหรับกราฟิก รวมถึงจำนวนที่ซับซ้อนจากไลบรารีมาตรฐาน C++ ด้วย
ฉันจะคอมไพล์ด้วยแฟล็ก -g
เดียวกันกับด้านบนเพื่อรวมข้อมูลการแก้ไขข้อบกพร่อง และจะขอให้ Emscripten จัดหาไลบรารี SDL2 และอนุญาตให้ใช้หน่วยความจำตามขนาดที่ต้องการด้วย
emcc -g mandelbrot.cc -o mandelbrot.html \ -s USE_SDL=2 \ -s ALLOW_MEMORY_GROWTH=1
เมื่อผมเข้าชมหน้าเว็บที่สร้างขึ้นในเบราว์เซอร์ ผมจะเห็นรูปทรงแฟร็กทัลที่สวยงาม พร้อมสีแบบสุ่ม ดังนี้
เมื่อเปิดเครื่องมือสำหรับนักพัฒนาเว็บ ฉันเห็นไฟล์ C++ ต้นฉบับอีกครั้ง อย่างไรก็ตาม ในครั้งนี้เราไม่มีข้อผิดพลาดในโค้ด (ว้าว!) เราลองมาตั้งค่าเบรกพอยท์ที่ตอนต้นของโค้ดแทน
เมื่อเราโหลดหน้านี้ซ้ำ โปรแกรมแก้ไขข้อบกพร่องจะหยุดชั่วคราวในที่มา C++ ของเรา
เราเห็นตัวแปรทั้งหมดทางด้านขวาอยู่แล้ว แต่ขณะนี้มีเพียง width
และ height
ที่เริ่มต้นเท่านั้น จึงไม่มีอะไรให้ตรวจสอบมากนัก
มาตั้งค่าเบรกพอยท์อีกจุดหนึ่งภายในลูป Mandelbrot หลักของเรา แล้วดำเนินการต่อไปเพื่อข้ามไปข้างหน้า
เมื่อถึงจุดนี้ palette
ของเราเต็มไปด้วยสีแบบสุ่ม และเราสามารถขยายทั้งอาร์เรย์ รวมถึงโครงสร้าง SDL_Color
แต่ละรายการ และตรวจสอบคอมโพเนนต์ของพวกเขาว่าทุกอย่างดูดีแล้ว (ตัวอย่างเช่น ช่อง "อัลฟา" จะตั้งค่าเป็นความทึบแสงเต็มเสมอ) ในทำนองเดียวกัน เราสามารถขยายและตรวจสอบส่วนจริงและส่วนจินตภาพของจำนวนเชิงซ้อนที่จัดเก็บในตัวแปร center
ได้
หากต้องการเข้าถึงพร็อพเพอร์ตี้ที่ฝังอยู่ลึกซึ่งนำทางผ่านมุมมองขอบเขตได้ยาก คุณก็ใช้การประเมินคอนโซลได้เช่นกัน แต่โปรดทราบว่าระบบยังไม่รองรับนิพจน์ C++ ที่ซับซ้อนมากขึ้น
มาดำเนินการกันต่ออีกสัก 2-3 ครั้ง เราจะดูว่า x
ภายในเปลี่ยนแปลงไปอย่างไรบ้างด้วยการดูในมุมมองขอบเขตอีกครั้ง การเพิ่มชื่อตัวแปรลงในรายการเฝ้าดู ประเมินค่าในคอนโซล หรือโดยการวางเมาส์เหนือตัวแปรในซอร์สโค้ด ดังนี้
จากตรงนี้ เราสามารถย้อนดูคำสั่ง C++ อย่างละเอียด และสังเกตการเปลี่ยนแปลงของตัวแปรอื่นๆ ด้วย ดังนี้
โอเค ทุกอย่างจะทำงานได้ดีเมื่อมีข้อมูลการแก้ไขข้อบกพร่อง แต่ถ้าเราต้องการแก้ไขข้อบกพร่องในโค้ดที่ไม่ได้สร้างขึ้นด้วยตัวเลือกการแก้ไขข้อบกพร่อง
การแก้ไขข้อบกพร่อง Raw WebAssembly
เช่น เราขอให้ Emscripten จัดเตรียมไลบรารี SDL ที่สร้างไว้ล่วงหน้าให้เรา แทนที่จะคอมไพล์ด้วยตนเองจากแหล่งที่มา ดังนั้นอย่างน้อยตอนนี้ โปรแกรมแก้ไขข้อบกพร่องก็ไม่สามารถค้นหาแหล่งที่มาที่เชื่อมโยงได้
มาเข้าสู่ SDL_RenderDrawColor
อีกครั้งกัน
เรากลับมาสัมผัสประสบการณ์การแก้ไขข้อบกพร่องด้วย WebAssembly แบบข้อมูลดิบ
ตอนนี้ ก็ดูค่อนข้างน่ากลัวไม่ใช่สิ่งที่นักพัฒนาเว็บส่วนใหญ่จะต้องจัดการ แต่บางครั้งคุณอาจต้องการแก้ไขข้อบกพร่องของไลบรารีที่สร้างขึ้นโดยไม่มีข้อมูลการแก้ไขข้อบกพร่อง ไม่ว่าจะเป็นเพราะไลบรารีดังกล่าวเป็นไลบรารีของบุคคลที่ 3 ซึ่งคุณไม่สามารถควบคุมได้ หรือคุณเจอข้อบกพร่องอย่างใดอย่างหนึ่งที่เกิดขึ้นเฉพาะในเวอร์ชันที่ใช้งานจริงเท่านั้น
เพื่อช่วยในกรณีเหล่านั้น เราได้ทำการปรับปรุงบางอย่างในประสบการณ์การแก้ไขข้อบกพร่องพื้นฐานด้วย
อย่างแรกเลย หากก่อนหน้านี้คุณใช้การแก้ไขข้อบกพร่อง WebAssembly แบบข้อมูลดิบ คุณอาจสังเกตเห็นว่าตอนนี้การถอดแยกชิ้นส่วนทั้งหมดแสดงขึ้นในไฟล์เดียว ไม่ต้องเดาว่าฟังก์ชันใดของรายการแหล่งที่มา wasm-53834e3e/
wasm-53834e3e-7
จะสอดคล้องกับฟังก์ชันใด
สคีมการสร้างชื่อใหม่
นอกจากนี้เรายังได้ปรับปรุงชื่อในมุมมองการแยกชิ้นส่วนด้วย ก่อนหน้านี้คุณจะเห็นเพียงดัชนีตัวเลข หรือในกรณีที่ไม่เห็นชื่อฟังก์ชัน
ตอนนี้เรากำลังสร้างชื่อที่คล้ายคลึงกับเครื่องมือแยกชิ้นส่วนอื่นๆ โดยใช้คำแนะนำจากส่วนชื่อ WebAssembly, เส้นทางการนำเข้า/ส่งออก และสุดท้าย หากอื่นๆ ทั้งหมดล้มเหลว ให้สร้างชื่อตามประเภทและดัชนีของรายการ เช่น $func123
ซึ่งในภาพหน้าจอด้านบน วิธีนี้ช่วยทำให้สแต็กเทรซและการถอดแยกชิ้นส่วนที่อ่านง่ายขึ้นได้เล็กน้อย
เมื่อไม่มีข้อมูลประเภท การตรวจสอบค่าใดๆ นอกเหนือจากแบบพื้นฐานอาจทำได้ยาก เช่น ตัวชี้จะแสดงเป็นจำนวนเต็มปกติ โดยไม่สามารถรู้ได้ว่ามีสิ่งใดบ้างจัดเก็บไว้ในหน่วยความจำ
การตรวจสอบหน่วยความจำ
ก่อนหน้านี้คุณจะขยายได้เฉพาะออบเจ็กต์หน่วยความจำ WebAssembly ที่แสดงด้วย env.memory
ในมุมมองขอบเขตเพื่อค้นหาไบต์แต่ละรายการ วิธีนี้ได้ผลในบางสถานการณ์ที่ไม่สำคัญ แต่ไม่สะดวกนักในการขยาย และไม่อนุญาตให้ตีความข้อมูลซ้ำในรูปแบบอื่นนอกเหนือจากค่าไบต์ เราได้เพิ่มคุณลักษณะใหม่เพื่อช่วยในเรื่องนี้ด้วย ซึ่งก็คือเครื่องมือตรวจสอบหน่วยความจำเชิงเส้น
หากคลิกขวาที่ env.memory
คุณควรจะเห็นตัวเลือกใหม่ที่ชื่อว่า ตรวจสอบหน่วยความจำ ดังนี้
เมื่อคลิกแล้ว ระบบจะแสดงเครื่องมือตรวจสอบหน่วยความจำ ซึ่งคุณจะตรวจสอบหน่วยความจำ WebAssembly ในมุมมองเลขฐานสิบหกและ ASCII เพื่อไปยังที่อยู่ที่เจาะจง รวมถึงตีความข้อมูลในรูปแบบต่างๆ ได้ ดังนี้
สถานการณ์ขั้นสูงและคำเตือน
การทำโปรไฟล์โค้ด WebAssembly
เมื่อคุณเปิดเครื่องมือสำหรับนักพัฒนาเว็บ โค้ด WebAssembly จะ "ลดขั้น" เป็นเวอร์ชันที่ไม่ได้เพิ่มประสิทธิภาพเพื่อเปิดใช้การแก้ไขข้อบกพร่อง เวอร์ชันนี้ช้ากว่ามาก ซึ่งหมายความว่าคุณจะไม่สามารถอาศัย console.time
, performance.now
และวิธีการอื่นๆ ในการวัดความเร็วของโค้ดขณะที่เปิดเครื่องมือสำหรับนักพัฒนาเว็บอยู่ เนื่องจากตัวเลขที่คุณได้รับจะไม่ได้แสดงถึงประสิทธิภาพในชีวิตจริงเลย
แต่คุณควรใช้แผงประสิทธิภาพสำหรับเครื่องมือสำหรับนักพัฒนาเว็บ ซึ่งจะเรียกใช้โค้ดด้วยความเร็วสูงสุด และแสดงรายละเอียดเวลาในการทำงานในฟังก์ชันต่างๆ ดังนี้
หรืออีกวิธีคือ คุณสามารถเรียกใช้แอปพลิเคชันโดยปิดเครื่องมือสำหรับนักพัฒนาเว็บไป แล้วเปิดแอปพลิเคชันเมื่อเสร็จสิ้นเพื่อตรวจสอบคอนโซล
เราจะปรับปรุงสถานการณ์การสร้างโปรไฟล์ในอนาคต แต่สำหรับตอนนี้ โปรดระมัดระวัง หากต้องการดูข้อมูลเพิ่มเติมเกี่ยวกับสถานการณ์การจัดลำดับของ WebAssembly โปรดดูเอกสารของเราที่ไปป์ไลน์การคอมไพล์ WebAssembly
การสร้างและการแก้ไขข้อบกพร่องในเครื่องอื่น (รวมถึง Docker / โฮสต์)
เมื่อสร้างใน Docker, เครื่องเสมือน หรือในเซิร์ฟเวอร์บิลด์ระยะไกล คุณอาจพบสถานการณ์ที่เส้นทางไปยังไฟล์ต้นฉบับที่ใช้ระหว่างการสร้างไม่ตรงกับเส้นทางในระบบไฟล์ของคุณเองที่เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ทำงานอยู่ ในกรณีนี้ ไฟล์จะแสดงในแผงแหล่งที่มาแต่โหลดไม่สำเร็จ
เพื่อแก้ไขปัญหานี้ เราได้นำฟังก์ชันการแมปเส้นทางมาใช้ในตัวเลือกส่วนขยาย C/C++ ซึ่งนำมาใช้เพื่อแมปเส้นทางที่กำหนดเองอีกครั้งและช่วยเครื่องมือสำหรับนักพัฒนาเว็บค้นหาแหล่งที่มาได้
ตัวอย่างเช่น หากโปรเจ็กต์ในเครื่องโฮสต์อยู่ภายใต้เส้นทาง C:\src\my_project
แต่สร้างไว้ในคอนเทนเนอร์ Docker ซึ่งเส้นทางนั้นแสดงเป็น /mnt/c/src/my_project
คุณสามารถแมปกลับใหม่ในระหว่างการแก้ไขข้อบกพร่องได้โดยระบุเส้นทางเหล่านั้นเป็นคำนำหน้า ดังนี้
คำนำหน้าที่ตรงกันรายการแรกคือ "wins" หากคุณคุ้นเคยกับโปรแกรมแก้ไขข้อบกพร่อง C++ อื่นๆ ตัวเลือกนี้จะคล้ายกับคำสั่ง set substitute-path
ใน GDB หรือการตั้งค่า target.source-map
ใน LLDB
การแก้ไขข้อบกพร่องของบิลด์ที่เพิ่มประสิทธิภาพ
เช่นเดียวกับภาษาอื่นๆ การแก้ไขข้อบกพร่องจะทำงานได้ดีที่สุดหากปิดใช้การเพิ่มประสิทธิภาพ การเพิ่มประสิทธิภาพอาจทำงานในหน้าต่างๆ กัน เรียงลำดับโค้ดใหม่ หรือนำส่วนต่างๆ ของโค้ดออกทั้งหมด ซึ่งทั้งหมดนี้จะมีโอกาสสร้างความสับสนให้กับโปรแกรมแก้ไขข้อบกพร่องและทำให้คุณในฐานะผู้ใช้ได้
หากคุณไม่มีปัญหากับการแก้ไขข้อบกพร่องที่จำกัดมากขึ้น และยังคงต้องการแก้ไขข้อบกพร่องของเวอร์ชันที่เพิ่มประสิทธิภาพ การเพิ่มประสิทธิภาพส่วนใหญ่ก็จะทำงานได้ตามที่คาดหวังไว้ ยกเว้นในหน้าฟังก์ชัน เราวางแผนที่จะจัดการกับปัญหาที่เหลือในอนาคต แต่ในตอนนี้ โปรดใช้ -fno-inline
เพื่อปิดใช้เมื่อรวมเข้ากับการเพิ่มประสิทธิภาพระดับ -O
เช่น
emcc -g temp.c -o temp.html \ -O3 -fno-inline
การแยกข้อมูลการแก้ไขข้อบกพร่อง
ข้อมูลการแก้ไขข้อบกพร่องจะเก็บรายละเอียดมากมายเกี่ยวกับโค้ด ประเภท ตัวแปร ฟังก์ชัน ขอบเขต และตำแหน่งที่กำหนด รวมถึงตำแหน่งใดก็ตามที่อาจเป็นประโยชน์ต่อโปรแกรมแก้ไขข้อบกพร่อง ด้วยเหตุนี้ แท็กจึงมักจะมีขนาดใหญ่กว่าตัวโค้ด
หากต้องการเพิ่มความเร็วในการโหลดและรวบรวมโมดูล WebAssembly คุณอาจต้องแยกข้อมูลการแก้ไขข้อบกพร่องนี้ออกเป็นไฟล์ WebAssembly แยกต่างหาก หากต้องการดำเนินการใน Emscripten ให้ส่งแฟล็ก -gseparate-dwarf=…
พร้อมชื่อไฟล์ที่ต้องการ:
emcc -g temp.c -o temp.html \ -gseparate-dwarf=temp.debug.wasm
ในกรณีนี้ แอปพลิเคชันหลักจะจัดเก็บเฉพาะชื่อไฟล์ temp.debug.wasm
และส่วนขยายตัวช่วยจะค้นหาและโหลดได้เมื่อคุณเปิดเครื่องมือสำหรับนักพัฒนาเว็บ
เมื่อผสานเข้ากับการเพิ่มประสิทธิภาพตามที่อธิบายไว้ข้างต้น คุณอาจใช้ฟีเจอร์นี้เพื่อจัดส่งบิลด์เวอร์ชันที่ใช้งานจริงที่เกือบมีประสิทธิภาพสูงสุดสำหรับแอปพลิเคชันของคุณ และแก้ไขข้อบกพร่องด้วยไฟล์ฝั่งในเครื่องในภายหลังได้ ในกรณีนี้ เราจะต้องลบล้าง URL ที่เก็บไว้เพื่อช่วยส่วนขยายค้นหาไฟล์ด้านข้างได้ เช่น
emcc -g temp.c -o temp.html \ -O3 -fno-inline \ -gseparate-dwarf=temp.debug.wasm \ -s SEPARATE_DWARF_URL=file://[local path to temp.debug.wasm]
การดำเนินการต่อไป...
โอ้โห เป็นฟีเจอร์ใหม่ๆ เยอะมาก
การผสานรวมใหม่เหล่านั้นทำให้ Chrome DevTools กลายเป็นเครื่องมือแก้ไขข้อบกพร่องที่ทำงานได้จริงและทรงพลัง ไม่เพียงสำหรับ JavaScript เท่านั้น แต่ยังรวมถึงแอป C และ C++ ด้วย ทำให้ใช้แอปได้ง่ายขึ้นกว่าที่เคย มีเทคโนโลยีมากมายที่นำมาปรับใช้ในเว็บที่แชร์ข้ามแพลตฟอร์ม
อย่างไรก็ตาม การเดินทางของเรายังไม่สิ้นสุด สิ่งที่เราจะทำต่อไป มีดังต่อไปนี้
- ลบขอบที่หยาบๆ ในการแก้ไขข้อบกพร่อง
- เพิ่มการรองรับตัวจัดรูปแบบประเภทที่กำหนดเอง
- ดำเนินการปรับปรุงการทำโปรไฟล์สำหรับแอป WebAssembly
- เพิ่มการรองรับการครอบคลุมของโค้ดเพื่อให้ค้นหาโค้ดที่ไม่ได้ใช้ได้ง่ายขึ้น
- ปรับปรุงการรองรับนิพจน์ในการประเมินคอนโซล
- เพิ่มการรองรับภาษาอื่นๆ
- …และอีกมากมาย
ในระหว่างนี้ โปรดช่วยเราด้วยการลองใช้เวอร์ชันเบต้าปัจจุบันในโค้ดของคุณเอง และรายงานปัญหาที่พบไปยัง https://bugs.chromium.org/p/chromium/issues/entry?template=DevTools+issue
ดาวน์โหลดช่องตัวอย่าง
ลองใช้ Chrome Canary, Dev หรือเบต้าเป็นเบราว์เซอร์สำหรับการพัฒนาเริ่มต้น ตัวอย่างช่องทางเหล่านี้จะช่วยให้คุณสามารถเข้าถึงฟีเจอร์ล่าสุดของเครื่องมือสำหรับนักพัฒนาเว็บ ทดสอบ API แพลตฟอร์มเว็บที่ล้ำสมัย และค้นหาปัญหาในเว็บไซต์ก่อนที่ผู้ใช้จะทำงานได้
ติดต่อทีมเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome
ใช้ตัวเลือกต่อไปนี้เพื่อพูดคุยเกี่ยวกับฟีเจอร์ใหม่ๆ และการเปลี่ยนแปลงในโพสต์หรือเรื่องอื่นๆ ที่เกี่ยวข้องกับเครื่องมือสำหรับนักพัฒนาเว็บ
- ส่งคำแนะนำหรือความคิดเห็นถึงเราผ่าน crbug.com
- รายงานปัญหาเกี่ยวกับเครื่องมือสำหรับนักพัฒนาเว็บโดยใช้ตัวเลือกเพิ่มเติม > ความช่วยเหลือ > รายงานปัญหาเกี่ยวกับเครื่องมือสำหรับนักพัฒนาเว็บในเครื่องมือสำหรับนักพัฒนาเว็บ
- ทวีตที่ @ChromeDevTools
- แสดงความคิดเห็นเกี่ยวกับ "มีอะไรใหม่ในวิดีโอ YouTube สำหรับเครื่องมือสำหรับนักพัฒนาเว็บ" หรือเคล็ดลับเครื่องมือสำหรับนักพัฒนาเว็บวิดีโอ YouTube