เรียนรู้เกี่ยวกับการวัดภาพเคลื่อนไหว วิธีคิดเกี่ยวกับเฟรมภาพเคลื่อนไหว และความราบรื่นของหน้าโดยรวม
คุณอาจเคยเจอกับหน้าที่ "ติดขัด" หรือ "ตรึง" ในระหว่างการเลื่อนหรือ ภาพเคลื่อนไหว เราชอบบอกว่าประสบการณ์เหล่านี้ไม่ได้ราบรื่น ถึงที่อยู่ ปัญหาประเภทนี้ ทีม Chrome กำลังพยายามเพิ่มการสนับสนุน เครื่องมือสำหรับห้องทดลองในการตรวจจับภาพเคลื่อนไหวของเรา ตลอดจนการปรับปรุงอย่างต่อเนื่อง ไปยังการวินิจฉัยไปป์ไลน์การแสดงผลภายใน Chromium
เราต้องการแบ่งปันความคืบหน้าล่าสุด ให้คำแนะนำการใช้เครื่องมือที่เป็นรูปธรรม และ พูดคุยเกี่ยวกับแนวคิดเกี่ยวกับเมตริกความลื่นไหลของภาพเคลื่อนไหวในอนาคต และเช่นเคย เพื่อรับฟังความคิดเห็นจากคุณ
โพสต์นี้จะมีหัวข้อหลัก 3 หัวข้อ ดังนี้
- ดูภาพเคลื่อนไหวและเฟรมภาพเคลื่อนไหวอย่างรวดเร็ว
- ความคิดปัจจุบันของเราเกี่ยวกับการวัดความลื่นไหลของภาพเคลื่อนไหวโดยรวม
- คำแนะนำบางส่วนที่นำไปใช้ได้จริงในห้องทดลองวันนี้
ภาพเคลื่อนไหวคืออะไร
ภาพเคลื่อนไหวช่วยเพิ่มชีวิตชีวาให้กับเนื้อหา ด้วยการทำให้เนื้อหาเคลื่อนไหว โดยเฉพาะในการตอบสนอง การโต้ตอบของผู้ใช้ ภาพเคลื่อนไหว ทำให้ประสบการณ์ที่เป็นธรรมชาติมากขึ้น เข้าใจได้และสนุก
แต่ภาพเคลื่อนไหวที่ได้ประสิทธิภาพไม่ดี หรือการเพิ่มภาพเคลื่อนไหวมากเกินไปอาจทำให้ ทำให้ประสบการณ์การใช้งานแย่ลงและรู้สึกว่าไม่สนุกเลย เราทุกคนน่าจะ โต้ตอบกับอินเทอร์เฟซที่เพิ่งเพิ่ม "มีประโยชน์" มากเกินไป การเปลี่ยน ซึ่งก่อให้เกิดความเสียหายกับประสบการณ์เมื่อมีประสิทธิภาพต่ำ ดังนั้น ผู้ใช้บางรายอาจ ต้องการลดการเคลื่อนไหว ซึ่งเป็นค่ากำหนดของผู้ใช้ ที่คุณควรเคารพ
ภาพเคลื่อนไหวทำงานอย่างไร
กล่าวโดยสรุปคือ ไปป์ไลน์การแสดงผล ประกอบด้วย 2-3 ขั้นที่ตามลำดับ ได้แก่
- รูปแบบ: คำนวณค่า สไตล์ที่ใช้กับองค์ประกอบ
- เลย์เอาต์: สร้างคอมโพเนนต์ เรขาคณิตและตำแหน่งสำหรับแต่ละองค์ประกอบ
- สี: กรอกข้อมูลใน ขององค์ประกอบแต่ละอย่างลงในเลเยอร์ต่างๆ
- ผสม: วาด หลายเลเยอร์กับหน้าจอ
แม้ว่าจะมีหลากหลายวิธีในการกำหนดภาพเคลื่อนไหว โดยพื้นฐานแล้วก็ทำงานผ่าน ดำเนินการอย่างใดอย่างหนึ่งต่อไปนี้
- กำลังปรับเลย์เอาต์ พร็อพเพอร์ตี้
- กำลังปรับสี พร็อพเพอร์ตี้
- การปรับ composite พร็อพเพอร์ตี้
เนื่องจากขั้นตอนต่างๆ เรียงตามลำดับ จึงเป็นสิ่งสำคัญที่จะกำหนดภาพเคลื่อนไหวใน ของพร็อพเพอร์ตี้ที่อยู่ลึกลงไปในไปป์ไลน์ ยิ่งอัปเดตนานเท่าไร กระบวนการจะยิ่งมีต้นทุนสูง และมีแนวโน้มต่ำที่จะ อย่างราบรื่น (ดูการแสดงภาพ ประสิทธิภาพ เพื่อดูรายละเอียดเพิ่มเติม)
แม้ว่าการทำให้คุณสมบัติการจัดวางเป็นภาพเคลื่อนไหวจะทำได้สะดวก แต่ก็ยังมีต้นทุนในการ แม้ว่าค่าใช้จ่ายเหล่านั้นจะไม่ได้เห็นชัดในทันทีก็ตาม ภาพเคลื่อนไหวควร กำหนดไว้ในรูปของการเปลี่ยนแปลงพร็อพเพอร์ตี้แบบผสมเมื่อเป็นไปได้
การกำหนดภาพเคลื่อนไหว CSS ที่มีการประกาศหรือใช้เว็บ ภาพเคลื่อนไหว, และการทำให้แน่ใจว่าคุณทำให้องค์ประกอบเคลื่อนไหว พร็อพเพอร์ตี้ เป็นขั้นตอนแรกที่ยอดเยี่ยมในการทำให้ภาพเคลื่อนไหวลื่นไหลและมีประสิทธิภาพ แต่ถึงอย่างนั้น แต่รับประกันไม่ได้ว่าจะมีความลื่นไหล เพราะแม้แต่ภาพเคลื่อนไหวบนเว็บที่มีประสิทธิภาพ มีขีดจำกัดด้านประสิทธิภาพ ด้วยเหตุนี้การวัดผลจึงเป็นสิ่งสำคัญเสมอ
เฟรมภาพเคลื่อนไหวคืออะไร
การอัปเดตการแสดงภาพหน้าเว็บจะใช้เวลาสักครู่จึงจะปรากฏ ภาพ การเปลี่ยนแปลงจะนำไปสู่เฟรมภาพเคลื่อนไหวใหม่ ซึ่งในที่สุดจะแสดงผลบน จอแสดงผลของผู้ใช้
แสดงการอัปเดตในบางช่วงเวลา ดังนั้นการอัปเดตภาพจึงรวมเป็นชุด จอแสดงผลหลายจอ อัปเดตตามช่วงเวลาที่กำหนดไว้ เช่น 60 ครั้งต่อวินาที 60 Hz) จอแสดงผลที่ทันสมัยกว่าบางรุ่นอาจมีอัตราการรีเฟรชสูงกว่า (90–120 Hz เริ่มแพร่หลายแล้ว) จอแสดงผลเหล่านี้มักปรับเปลี่ยนได้ตลอดเวลา ระหว่างอัตราการรีเฟรชตามต้องการ หรือแม้กระทั่งเสนออัตราเฟรมที่เปลี่ยนแปลงได้โดยสมบูรณ์
เป้าหมายสำหรับแอปพลิเคชันใดๆ ก็ตาม เช่น เกม หรือเบราว์เซอร์ คือการประมวลผลข้อมูลทั้งหมด อัปเดตภาพเป็นชุดๆ และสร้างเฟรมภาพเคลื่อนไหวที่สมบูรณ์ภายใน ทุกครั้ง โปรดทราบว่าเป้าหมายนี้แตกต่างจาก งานที่สำคัญของเบราว์เซอร์ เช่น การโหลดเนื้อหาจากเครือข่ายอย่างรวดเร็ว หรือ การใช้งาน JavaScript อย่างมีประสิทธิภาพ
บางครั้ง การอัปเดตภาพทั้งหมดภายใน กำหนดเวลาที่จัดสรรไว้ซึ่งหน้าจอกำหนดไว้ ในกรณีนี้ เบราว์เซอร์ ทำเฟรมตก หน้าจอไม่ดับ เพียงแค่เล่นซ้ำ คุณเห็น การอัปเดตภาพเดิมให้นานขึ้นอีกเล็กน้อย นั่นคือเฟรมภาพเคลื่อนไหวเดิม แสดงที่โอกาสของเฟรมก่อนหน้า
ซึ่งมักเกิดขึ้นบ่อย ผู้ใช้ไม่จำเป็นต้องรับรู้ได้ด้วยซ้ำ โดยเฉพาะอย่างยิ่ง เนื้อหาแบบคงที่หรือคล้ายเอกสาร ซึ่งพบได้ทั่วไปในแพลตฟอร์มเว็บใน โดยเฉพาะ เฟรมที่ถูกตัดออกจะเห็นได้ชัดเมื่อมีภาพสำคัญเท่านั้น อย่างภาพเคลื่อนไหว ซึ่งเราต้องการ ภาพเคลื่อนไหวที่สม่ำเสมอ อัปเดตเพื่อแสดงการเคลื่อนไหวที่ลื่นไหล
สิ่งที่ส่งผลต่อเฟรมภาพเคลื่อนไหว
นักพัฒนาเว็บอาจส่งผลกระทบอย่างมากต่อความสามารถของเบราว์เซอร์ในการ แสดงผลและนำเสนอการอัปเดตภาพอย่างมีประสิทธิภาพ!
ตัวอย่างมีดังต่อไปนี้
- ใช้เนื้อหาที่มีขนาดใหญ่หรือต้องใช้ทรัพยากรมากเกินไปในการถอดรหัสอย่างรวดเร็วบน อุปกรณ์เป้าหมาย
- การใช้จำนวนมากเกินไป เลเยอร์ ต้องใช้หน่วยความจำ GPU มากเกินไป
- การกำหนดรูปแบบ CSS หรือภาพเคลื่อนไหวบนเว็บที่ซับซ้อนเกินไป
- การใช้การออกแบบที่ต่อต้านรูปแบบที่ปิดใช้การเพิ่มประสิทธิภาพการแสดงผลอย่างรวดเร็ว
- มี JS มากเกินไปในเทรดหลัก นำไปสู่งานที่ใช้เวลานานซึ่งบล็อกภาพ อัปเดต
แต่จะรู้ได้อย่างไรว่าเฟรมภาพเคลื่อนไหวแสดงไม่ทันกำหนดเวลาและ เฟรมที่หล่นลงมา
วิธีการหนึ่งที่ใช้ได้คือ
requestAnimationFrame()
อย่างไรก็ดี มีข้อเสียหลายอย่าง requestAnimationFrame() หรือ "rAF"
จะบอกเบราว์เซอร์ว่าคุณต้องการ
สร้างภาพเคลื่อนไหวและขอให้
ก่อนที่จะทำการระบายสีครั้งต่อไปของไปป์ไลน์การแสดงผล ถ้า
ไม่ได้เรียกใช้ฟังก์ชัน Callback ตามเวลาที่คุณคาดไว้ ซึ่งหมายความว่า
ไม่มีการคัดลอกสี และมีการข้ามเฟรมอย่างน้อย 1 รายการ ด้วยการจัดทำแบบสำรวจและ
นับว่ามีการเรียก rAF บ่อยแค่ไหน คุณก็สามารถคำนวณ
ประเภท "เฟรมต่อวินาที"
(FPS)
let frameTimes = [];
function pollFramesPerSecond(now) {
frameTimes = [...frameTimes.filter(t => t > now - 1000), now];
requestAnimationFrame(pollFramesPerSecond);
console.log('Frames per second:', frameTimes.length);
}
requestAnimationFrame(pollFramesPerSecond);
การใช้แบบสำรวจของ requestAnimationFrame() ไม่ใช่วิธีที่ดีเนื่องด้วยเหตุผลหลายประการดังนี้
- ทุกสคริปต์จะต้องตั้งค่าลูปการสำรวจของตนเอง
- เพราะอาจบล็อกเส้นทางวิกฤติได้
- แม้ว่าการหยั่งสัญญาณ rAF จะเป็นไปอย่างรวดเร็ว แต่ก็สามารถป้องกัน
requestIdleCallback()จากความสามารถในการตั้งเวลาบล็อกที่ไม่ได้ใช้งานเป็นเวลานานเมื่อใช้อย่างต่อเนื่อง (บล็อกที่ เกิน 1 เฟรม) - ในทำนองเดียวกัน การไม่มีการบล็อกการไม่ใช้งานเป็นเวลานานจะทำให้เบราว์เซอร์ไม่สามารถวางกำหนดการอื่นๆ งานที่ใช้เวลานาน (เช่น การเก็บขยะที่ยาวขึ้นและพื้นหลังอื่นๆ หรือ งานแบบไม่เก็งกำไร)
- หากเปิดหรือปิดการสำรวจความคิดเห็น คุณจะพลาดกรณีที่ใช้กรอบงบประมาณ เกินขีดจำกัดแล้ว
- การทำแบบสำรวจจะรายงานผลบวกลวงในกรณีที่เบราว์เซอร์ใช้ ความถี่ในการอัปเดตตัวแปรต่างๆ (เช่น เนื่องจากกำลังไฟฟ้าหรือสถานะการมองเห็น)
- และที่สำคัญที่สุดคือ โมเดลไม่สามารถจับภาพภาพเคลื่อนไหวได้ทุกประเภท อัปเดต
การทำงานในเทรดหลักมากเกินไปอาจส่งผลต่อความสามารถในการมองเห็นเฟรมภาพเคลื่อนไหว โปรดดู Jank ตัวอย่างเพื่อดูว่า ภาพเคลื่อนไหวที่ใช้ rAF เมื่อมีการทำงานมากเกินไปในเทรดหลัก (เช่น ) จะทำให้เฟรมลดลงและการเรียกกลับ rAF น้อยลง และ FPS ที่ลดลง
เมื่อชุดข้อความหลักล้น การอัปเดตภาพจะเริ่มกระตุก นั่นมันวุ่นวายมาก!
เครื่องมือวัดผลจำนวนมากได้มุ่งเน้นอย่างครอบคลุมเกี่ยวกับความสามารถสำหรับ ให้ผลตอบแทนในเวลาที่เหมาะสม และช่วยให้เฟรมภาพเคลื่อนไหวทำงานอย่างราบรื่น แต่นี่ไม่ใช่เรื่องราวทั้งหมด ลองพิจารณาตัวอย่างต่อไปนี้
วิดีโอด้านบนแสดงหน้าที่แทรกงานที่ใช้เวลานานเข้าไปในหน้าหลักเป็นระยะ
ชุดข้อความ งานที่ใช้เวลานานเหล่านี้ทำลายความสามารถของหน้าเว็บในการแสดง
การอัปเดตภาพบางประเภท และคุณจะเห็น
FPS ที่รายงานของ requestAnimationFrame() ลดลงจนเหลือ 0
อย่างไรก็ตาม แม้จะมีงานที่ใช้เวลานานเหล่านี้ หน้าเว็บก็ยังคงเลื่อนดูได้อย่างราบรื่น ช่วงเวลานี้ เพราะในเบราว์เซอร์สมัยใหม่ การเลื่อนมักจะ แยกชุดข้อความ ซึ่งขับเคลื่อนด้วยคอมโพสเซอร์เพียงอย่างเดียว
นี่เป็นตัวอย่างที่ให้มีเฟรมที่วางลดลงจำนวนมากพร้อมกัน แต่ยังคงมีเฟรมการเลื่อนที่แสดงสำเร็จจำนวนมากใน เทรดคอมโพสิต เมื่องานที่ใช้เวลานานเสร็จสมบูรณ์ ระบบจะอัปเดตการระบายสีเทรดหลัก ก็ไม่มีอะไรเปลี่ยนแปลง การสำรวจ rAF แนะนำให้ลดเฟรมเป็น 0 แต่ด้วยภาพ ผู้ใช้คงไม่สามารถสังเกตเห็นความแตกต่าง!
สำหรับเฟรมภาพเคลื่อนไหว เรื่องราวไม่ง่ายนัก
เฟรมภาพเคลื่อนไหว: การอัปเดตที่สำคัญ
ตัวอย่างด้านบนแสดงให้เห็นว่าเรื่องราวไม่ใช่แค่
requestAnimationFrame()
การอัปเดตภาพเคลื่อนไหวและเฟรมภาพเคลื่อนไหวสำคัญเมื่อใด นี่คือ เกณฑ์บางประการที่เรากำลังพิจารณา และเราต้องการรับความคิดเห็นเกี่ยวกับเรื่องต่อไปนี้
- การอัปเดตชุดข้อความหลักและคอมโพสิต
- ไม่มีการอัปเดตการแสดงผล
- กำลังตรวจหาภาพเคลื่อนไหว
- คุณภาพกับปริมาณ
การอัปเดตชุดข้อความหลักและคอมโพสิต
การอัปเดตเฟรมภาพเคลื่อนไหวไม่บูลีน ไม่ได้หมายความว่าเฟรม นำเสนออย่างสมบูรณ์หรือนำเสนอทั้งหมด มีเหตุผลหลายประการที่ทำให้ภาพเคลื่อนไหว อาจมีบางส่วน แสดงอยู่ กล่าวอีกนัยหนึ่งคือ อาจมี เนื้อหาเก่าบางส่วน ในขณะเดียวกันก็มีการอัปเดตภาพใหม่ๆ นำเสนอ
ตัวอย่างที่พบบ่อยที่สุดก็คือเมื่อเบราว์เซอร์ไม่สามารถสร้าง การอัปเดตเทรดหลักภายในกำหนดเวลาของเฟรม แต่มีเทรดคอมโพสิตใหม่ อัปเดต (เช่นตัวอย่างการเลื่อนแบบแยกชุดข้อความจากก่อนหน้านี้)
เหตุผลสำคัญข้อหนึ่งว่าทำไมการใช้ภาพเคลื่อนไหวเชิงประกาศเพื่อทำให้ภาพผสมเคลื่อนไหว ที่แนะนำคือทำให้สามารถขับเคลื่อนภาพเคลื่อนไหว ทั้งหมดของเทรดคอมโพสิตแม้ว่าเทรดหลักจะยังไม่พร้อมใช้งาน ประเภทเหล่านี้ ภาพเคลื่อนไหวสามารถทำให้เกิดการอัปเดตภาพ ได้อย่างมีประสิทธิภาพและ พร้อมกัน
ในทางกลับกัน อาจมีกรณีที่การอัปเดตชุดข้อความหลักกลายเป็น แสดงสำหรับงานนำเสนอได้ แต่หลังจากที่ไม่ได้กำหนดเวลาหลายครั้ง ที่นี่ เบราว์เซอร์จะมีอัปเดตใหม่บางส่วน แต่อาจไม่ล่าสุด
พูดกว้างๆ ก็คือเราพิจารณาเฟรมที่มีการอัปเดตภาพใหม่ๆ ที่ไม่มีการอัปเดตภาพใหม่ทั้งหมด เป็นเฟรมบางส่วน เฟรมบางส่วนมีขนาดพอสมควร ทั่วไป ตามหลักการแล้ว การอัปเดตบางส่วน อย่างน้อยต้องมีองค์ประกอบที่สำคัญที่สุด การอัปเดตภาพ เช่น ภาพเคลื่อนไหว แต่จะเกิดขึ้นได้ก็ต่อเมื่อมีการ ขับเคลื่อนโดยชุดข้อความของคอมโพสิต
ไม่มีการอัปเดตการแสดงผล
การอัปเดตบางส่วนอีกประเภทหนึ่งคือเมื่อสื่ออย่างรูปภาพยังไม่จบ ถอดรหัสและแรสเตอร์ได้ ทันเวลาสำหรับการนำเสนอเฟรม
หรือแม้ว่าหน้าเว็บจะนิ่งสนิท เบราว์เซอร์อาจยังแสดงผลช้าอยู่ การอัปเดตภาพระหว่างการเลื่อนอย่างรวดเร็ว เพราะการแสดงผลพิกเซลของ ระบบอาจทิ้งเนื้อหาที่อยู่นอกวิวพอร์ตที่มองเห็นได้เพื่อประหยัดหน่วยความจำ GPU ทั้งนี้ ใช้เวลาแสดงผลพิกเซล และอาจใช้เวลานานกว่า 1 เฟรม แสดงผลทุกอย่างหลังจากการเลื่อนหน้าจอขนาดใหญ่ เช่น การสะบัดนิ้ว โดยทั่วไปแล้ว ซึ่งเรียกว่าการตรวจสอบกระดานหมากรุก
ด้วยโอกาสในการแสดงผลแต่ละเฟรม ทำให้คุณสามารถติดตาม อัปเดตภาพล่าสุด ได้ปรากฏบนหน้าจอจริงๆ การวัดความสามารถในการดำเนินการนี้ ในหลายเฟรม (หรือเวลา) นั้นเรียกกันอย่างกว้างขวางว่าอัตราการส่งข้อมูลเฟรม
หาก GPU ทำงานหนักมาก เบราว์เซอร์ (หรือแพลตฟอร์ม) อาจเริ่ม ควบคุมอัตราการพยายามอัปเดตภาพให้ต่ำลง อัตราเฟรมที่มีประสิทธิภาพ แต่ในทางเทคนิคแล้วสามารถลดจำนวนการลดลงได้ เฟรมที่อัปเดต รูปลักษณ์จะยังปรากฏเป็นอัตราการส่งข้อมูลของเฟรมระดับล่าง
อย่างไรก็ตาม อัตราการส่งข้อมูลของเฟรมต่ำบางประเภทก็ไม่ได้ไม่ดีนัก หากหน้าเว็บไม่มีการใช้งานเป็นส่วนใหญ่ และไม่มีภาพเคลื่อนไหวที่ใช้งานอยู่ อัตราเฟรมต่ำจะเหมือนกับภาพ ในแบบอัตราเฟรมสูง (และช่วยประหยัดแบตเตอรี่ด้วย)
แล้วอัตราการส่งข้อมูลเฟรมมีความสำคัญเมื่อใด
กำลังตรวจหาภาพเคลื่อนไหว
อัตราการส่งข้อมูลของเฟรมสูงมีความสำคัญโดยเฉพาะในช่วงเวลาที่มีความสำคัญ ภาพเคลื่อนไหว ภาพเคลื่อนไหวประเภทต่างๆ จะขึ้นอยู่กับการอัปเดตภาพจาก เทรดเฉพาะ (main, Compositeor, หรือ Worker) ดังนั้นการอัปเดตภาพ จะขึ้นอยู่กับเทรดนั้นเพื่อแจ้งการอัปเดตภายในกำหนดเวลา เราบอกว่า ชุดข้อความที่ระบุจะมีผลอย่างราบรื่นเมื่อมีภาพเคลื่อนไหวที่ใช้งานอยู่ ขึ้นอยู่กับการอัปเดตชุดข้อความ
ภาพเคลื่อนไหวบางประเภทจะระบุและตรวจจับได้ง่ายกว่าประเภทอื่นๆ ภาพเคลื่อนไหวเชิงประกาศ หรือภาพเคลื่อนไหวที่ผู้ใช้ป้อนมีความชัดเจนในการนิยาม ภาพเคลื่อนไหวที่ทำงานด้วย JavaScript ซึ่งมีการอัปเดตเป็นระยะเพื่อให้ภาพเคลื่อนไหวได้ คุณสมบัติของรูปแบบ
แม้กระทั่งกับคุณ requestAnimationFrame()
ไม่สามารถคิดเสมอไปว่าการเรียกใช้ rAF ทุกครั้งจะต้องสร้าง
อัปเดตหรือภาพเคลื่อนไหว เช่น การใช้การสำรวจ rAF เพื่อติดตามอัตราเฟรม
(ตามที่แสดงด้านบน) จะไม่ส่งผลใดๆ ต่อการวัดความราบรื่นเนื่องจาก
ไม่มีการอัปเดตภาพ
คุณภาพกับปริมาณ
สุดท้าย การตรวจหาภาพเคลื่อนไหวและการอัปเดตเฟรมภาพเคลื่อนไหวยังคงเป็นเพียงส่วนหนึ่งของ เพราะบันทึกเฉพาะจำนวนการอัปเดตภาพเคลื่อนไหวเท่านั้น ไม่ใช่ ของคุณ
ตัวอย่างเช่น คุณอาจเห็นอัตราเฟรมที่คงที่ที่ 60 fps ขณะดู ในการสร้างสรรค์วิดีโอ โดยในทางเทคนิค วิธีนี้ทำได้ราบรื่นดี แต่ตัววิดีโอเองอาจมี อัตราบิตต่ำ หรือปัญหาการบัฟเฟอร์ของเครือข่าย ภาพนี้ไม่ได้ถูกจับภาพโดย ความลื่นไหลของภาพเคลื่อนไหวโดยตรง แต่ก็ยังเป็นอุปสรรคต่อ ผู้ใช้
หรือเกมที่ใช้ประโยชน์จาก <canvas> (อาจถึงขั้นใช้เทคนิค เช่น
นอกหน้าจอ
Canvas ไปยัง
อัตราเฟรมที่คงที่)
อาจทำได้ราบรื่นไม่มีสะดุดในแง่ของ
ของภาพเคลื่อนไหวทั้งหมด แต่ไม่โหลดเนื้อหาเกมคุณภาพสูงลงใน
หรือแสดงภาพอาร์ติแฟกต์
และแน่นอนว่าเว็บไซต์อาจมีภาพเคลื่อนไหวที่ไม่ดีมากๆ 🙂
ฉันเดาว่าช่วงเวลานั้นพวกเขาเจ๋งมาก
สถานะของเฟรมภาพเคลื่อนไหวเดียว
เนื่องจากอาจมีการนำเสนอเฟรมเพียงบางส่วน หรือเฟรมที่ตกลงอาจเกิดขึ้นในลักษณะต่างๆ ที่จะไม่กระทบต่อความราบรื่น เราได้เริ่มคิดว่าแต่ละเฟรม ความสมบูรณ์หรือความราบรื่น
ต่อไปนี้เป็นสเปกตรัมของวิธีที่เราตีความสภาวะหนึ่งๆ เฟรมภาพเคลื่อนไหว โดยเรียงลำดับจากกรณีที่ดีที่สุดไปต่ำสุด
| ไม่ต้องการการอัปเดต | เวลาไม่อยู่ ทำซ้ำเฟรมก่อนหน้า |
| นำเสนออย่างเต็มรูปแบบ | มีการคอมมิตการอัปเดตเทรดหลักภายในกําหนดเวลาหรือไม่ ต้องการการอัปเดตเทรดหลัก |
| นำเสนอแล้วบางส่วน | องค์ประกอบเท่านั้น การอัปเดตเทรดหลักที่ล่าช้าไม่มีภาพ เปลี่ยน |
| นำเสนอแล้วบางส่วน | องค์ประกอบเท่านั้น เทรดหลักมีการอัปเดตภาพ การอัปเดตไม่ได้รวมภาพเคลื่อนไหวที่ส่งผลต่อความลื่นไหล |
| นำเสนอแล้วบางส่วน | องค์ประกอบเท่านั้น เทรดหลักมีการอัปเดตภาพที่ส่งผลกระทบ ความราบรื่น แต่กรอบเก่าก่อนหน้านี้มาถึงและถูกนำมาใช้แทน |
| นำเสนอแล้วบางส่วน | องค์ประกอบเท่านั้น ไม่มีการอัปเดตหลักที่ต้องการ และ การอัปเดต compositor มีภาพเคลื่อนไหวที่ส่งผลต่อความลื่นไหล |
| นำเสนอแล้วบางส่วน | คอมโพสิตเท่านั้นแต่การอัปเดตคอมโพสิตไม่มี ภาพเคลื่อนไหวที่มีผลต่อความลื่นไหล |
| เฟรมที่ถูกตัด | ไม่มีการอัปเดต ไม่มีการอัปเดตคอมโพสิตที่ต้องการ และหลักคือ ล่าช้า |
| เฟรมที่ถูกตัด | ต้องการการอัปเดตคอมโพสิต แต่เกิดความล่าช้า |
| เฟรมที่ไม่มีอัปเดต | ต้องการการอัปเดต ซึ่งสร้างโดยโหมดแสดงภาพ แต่ GPU ยังคงไม่แสดงก่อนกำหนดเวลาของ vsync |
คุณสามารถเปลี่ยนสถานะเหล่านี้ให้เป็นคะแนนได้ และอาจเป็นทางหนึ่ง ในการตีความคะแนนนี้คือ ความเป็นไปได้ที่จะได้รับการสังเกตโดย ผู้ใช้รายนั้น เฟรมที่ตกลงมาหนึ่งเฟรมอาจไม่สามารถสังเกตได้มากนัก แต่เป็นลำดับของ เฟรมที่ตกลงมาจำนวนมากส่งผลต่อความลื่นไหลในแถวแน่ๆ
รวมทั้งหมดเข้าด้วยกัน: เมตริกเปอร์เซ็นต์เฟรมที่ทิ้ง
แม้บางครั้งเราจำเป็นต้องเจาะลึกรายละเอียดของสถานการณ์ เฟรมแบบเคลื่อนไหวได้ นอกจากนี้ เพียงแค่กำหนด "การมองผ่าน" อย่างรวดเร็ว คะแนนสำหรับ ประสบการณ์
เพราะเฟรมอาจถูกนำเสนอบางส่วนและแม้แต่ถูกข้ามโดยสมบูรณ์ การอัปเดตเฟรมอาจไม่ส่งผลต่อความลื่นไหล เราจึงต้องการเน้นไปที่ นับเพียงเฟรมและอื่นๆ ในขอบเขตที่เบราว์เซอร์ไม่สามารถ ให้การอัปเดตที่มีภาพที่สมบูรณ์ในเวลาที่สําคัญ
แบบจำลองจิตใจควรมาจาก
- เฟรมต่อวินาทีเป็น
- กำลังตรวจหาอัปเดตภาพเคลื่อนไหวที่สำคัญและหายไป
- เปอร์เซ็นต์ที่ลดลงในระยะเวลาที่กำหนด
สิ่งสำคัญคือ: สัดส่วนของเวลาที่รอข้อมูลสำคัญ อัปเดต เราคิดว่าแอปนี้จะสอดคล้องกับวิธีธรรมชาติที่ผู้ใช้ได้รับความราบรื่น ของเนื้อหาเว็บในเชิงปฏิบัติ ที่ผ่านมา เราจะใช้สิ่งต่างๆ ต่อไปนี้เป็น ชุดเมตริกเริ่มต้น:
- เปอร์เซ็นต์เฉลี่ยที่ลดลง: สำหรับเฟรมของภาพเคลื่อนไหวทั้งหมดที่ไม่ได้ทำงานตลอดเวลา ไทม์ไลน์ทั้งหมด
- กรณีแย่ที่สุดของเปอร์เซ็นต์เฟรมที่ตกลง: ตามที่วัดการเลื่อนไปมา 1 วินาที ในช่วงเวลานั้น
- เปอร์เซ็นไทล์ที่ 95 ของเปอร์เซ็นต์เฟรมที่ทิ้ง: ตามที่วัดในช่วง 1 วินาที หน้าต่างเลื่อนของเวลา
คุณดูคะแนนเหล่านี้ได้ในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ Chrome บางรายการได้แล้ววันนี้ ขณะที่รายการเหล่านี้ เมตริกจะมุ่งเน้นที่อัตราการส่งข้อมูลของเฟรมโดยรวมเท่านั้น เรายังประเมิน อย่างเช่น เวลาในการตอบสนองของเฟรม
ลองใช้งานด้วยตัวเองในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์
HUD ประสิทธิภาพ
Chromium มี HUD สำหรับเพิ่มประสิทธิภาพมากมายซ่อนอยู่หลังธง
(chrome://flags/#show-performance-metrics-hud) ในแอปนี้ คุณจะพบกับ
คะแนนสำหรับสิ่งต่างๆ เช่น Core Web Vitals และคำจำกัดความจากการทดลองอีกส่วนหนึ่ง
เพื่อความลื่นไหลของภาพเคลื่อนไหวโดยอิงตามเปอร์เซ็นต์เฟรมที่ลดลงเมื่อเวลาผ่านไป
สถิติการแสดงผลเฟรม
เปิดใช้งาน "การแสดงภาพเฟรม สถิติ" ในเครื่องมือสำหรับนักพัฒนาเว็บผ่านการตั้งค่าการแสดงผล เพื่อดูภาพสดของเฟรมภาพเคลื่อนไหวใหม่ ซึ่งจะเขียนรหัสสีไว้เพื่อแยกการอัปเดตบางส่วนออกจากเฟรมที่แสดงผลเต็มที่ อัปเดต FPS ที่รายงานมีไว้สำหรับเฟรมที่นำเสนออย่างเต็มรูปแบบเท่านั้น
Frame Viewer ในการบันทึกโปรไฟล์ประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บ
ประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บ มีแผง มีเฟรมมานานแล้ว ผู้ชม อย่างไรก็ตาม โมเดลนี้เริ่มมีความไม่สอดคล้องกับวิธีที่ไปป์ไลน์การแสดงภาพสมัยใหม่ ใช้งานได้จริง มีการปรับปรุงมากมายเมื่อเร็วๆ นี้ แม้ใน Chrome Canary ซึ่งเราคิดว่าจะช่วยแก้ไขปัญหาเกี่ยวกับภาพเคลื่อนไหวได้ง่ายขึ้น
วันนี้คุณจะพบว่าเฟรมในเครื่องมือดูเฟรมอยู่ในแนวเดียวกับ ขอบเขตของ vsync และใช้รหัสสีตามสถานะ ยังไม่เต็ม ที่ระบุไว้ข้างต้นสำหรับความแตกต่างเล็กๆ น้อยๆ ทั้งหมดที่แสดงข้างต้น แต่เรากำลังวางแผนที่จะเพิ่ม ในอนาคตอันใกล้
การติดตาม Chrome
สุดท้ายด้วย Chrome Tracing ซึ่งเป็นเครื่องมือที่เลือกใช้ในการเจาะลึกรายละเอียด
คุณสามารถบันทึก "การแสดงผลเนื้อหาเว็บ" ติดตามผ่าน Perfetto ใหม่
UI (หรือ about:tracing) และเจาะลึกรายละเอียดในส่วน
ไปป์ไลน์ของกราฟิก นี่อาจเป็นงานที่ยุ่งยาก แต่ก็มี 2-3 อย่าง
ที่เพิ่มลงใน Chromium ไปเมื่อเร็วๆ นี้เพื่อให้ใช้งานง่ายขึ้น คุณสามารถดูภาพรวมว่า
มีอยู่ในชีวิตของ
กรอบ
เอกสาร
เมื่อใช้เหตุการณ์การติดตาม คุณจะระบุสิ่งต่อไปนี้ได้
- ภาพเคลื่อนไหวที่กำลังทำงาน (โดยใช้เหตุการณ์ชื่อ
TrackerValidation) - การรับไทม์ไลน์ที่แน่นอนของเฟรมภาพเคลื่อนไหว (โดยใช้เหตุการณ์ชื่อ
PipelineReporter) - สำหรับการอัปเดตภาพเคลื่อนไหวที่มีคุณภาพต่ำ ให้หาว่าอะไรที่บล็อก
ภาพเคลื่อนไหวไม่ทำงานได้เร็วขึ้น (ใช้รายละเอียดของเหตุการณ์ภายใน
PipelineReporterเหตุการณ์) - สำหรับภาพเคลื่อนไหวที่ขับเคลื่อนอินพุต ดูว่าใช้เวลานานเท่าใดกว่าจะได้รับการอัปเดตภาพ
(ใช้เหตุการณ์ชื่อ
EventLatency)
ขั้นตอนถัดไป
โครงการริเริ่ม Web Vitals มีจุดประสงค์ในการให้เมตริกและคำแนะนำสำหรับ ในการสร้างประสบการณ์ที่ยอดเยี่ยมของผู้ใช้บนเว็บ เมตริกจากห้องทดลอง เช่น ทั้งหมด Block Time (TBT) เป็นสิ่งสำคัญสำหรับ ตรวจจับและวิเคราะห์ปัญหาด้านการโต้ตอบที่อาจเกิดขึ้น เรากำลังวางแผนที่จะ ออกแบบเมตริกที่เหมือนกับในห้องทดลองเพื่อสร้างความลื่นไหลของภาพเคลื่อนไหว
เราจะคอยแจ้งให้คุณทราบขณะที่เราเดินหน้าปรับปรุงแนวคิดในการออกแบบ เมตริกที่ครอบคลุมโดยอิงตามข้อมูลเฟรมภาพเคลื่อนไหวแต่ละเฟรม
ในอนาคต เราอยากจะออกแบบ API ที่ช่วยให้วัดผล ความลื่นไหลของภาพเคลื่อนไหว ให้ผู้ใช้งานจริงได้ใช้งานอย่างลื่นไหล รวมทั้งในห้องทดลอง โปรดติดตามข้อมูลอัปเดตด้วยเช่นกัน
ความคิดเห็น
เราตื่นเต้นกับการปรับปรุงล่าสุดและเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ทั้งหมดที่ มาใน Chrome เพื่อวัดความลื่นไหลของภาพเคลื่อนไหว โปรดลองใช้เครื่องมือเหล่านี้ เปรียบเทียบภาพเคลื่อนไหว และแจ้งให้เราทราบว่าภาพเคลื่อนไหวจะนำไปที่ใด
คุณสามารถส่งความคิดเห็นไปยัง web-vitals-feedback Google กลุ่มที่มี "[Smoothness Metrics]" ในบรรทัดเรื่อง เรากำลังพิจารณา หวังว่าเราจะได้ฟังสิ่งที่คุณคิด