ต้องการความคิดเห็นของนักพัฒนาซอฟต์แวร์ - Frame Timing API

ในช่วง 2-3 ปีที่ผ่านมา เบราว์เซอร์ได้พัฒนาประสิทธิภาพการแสดงผลไปอย่างมาก โดยเฉพาะบนอุปกรณ์เคลื่อนที่ ก่อนหน้านี้คุณอาจไม่มีความหวังที่จะได้เฟรมเรตที่ราบรื่นสำหรับเนื้อหาที่ซับซ้อน แต่ตอนนี้คุณก็สามารถทำได้หากทำอย่างระมัดระวัง

แต่สำหรับพวกเราส่วนใหญ่แล้ว สิ่งที่เราทดสอบในอุปกรณ์ของตัวเองได้นั้นไม่ตรงกับสิ่งที่ผู้ใช้ได้รับ หากผู้ใช้ไม่ได้รับประสบการณ์การรับชมที่ราบรื่นระดับ 60 fps ประสบการณ์การใช้งานของผู้ใช้ก็จะแย่ลง และท้ายที่สุดผู้ใช้ก็จะเปลี่ยนไปใช้บริการอื่นและเราก็จะได้รับผลกระทบ ด้วยเหตุนี้ W3C จึงกำลังพูดคุยเกี่ยวกับ API ใหม่ที่จะช่วยให้เราเห็นสิ่งที่ผู้ใช้เห็น ซึ่งก็คือ Frame Timing API

เมื่อเร็วๆ นี้ Jake Archibald และฉันได้บันทึกวิดีโอภาพรวมของ API นี้ไว้ หากต้องการดูแทนการอ่าน โปรดดูวิดีโอต่อไปนี้

การใช้ Frame Timing API

คุณสามารถทําสิ่งต่างๆ มากมายด้วย Frame Timing API และที่สำคัญคือคุณสามารถวัดสิ่งที่สําคัญต่อคุณและโปรเจ็กต์ อย่างไรก็ตาม ต่อไปนี้เป็นแนวคิดบางส่วน

  • ติดตาม FPS ของภาพเคลื่อนไหว JavaScript และ CSS
  • ติดตามความลื่นไหลของการเลื่อนหน้าเว็บ (หรือรายการแบบเลื่อนได้ไม่รู้จบที่ยอดเยี่ยมที่คุณมี)
  • ลดเอฟเฟกต์ภาพให้น้อยลงโดยอัตโนมัติตามภาระงานปัจจุบันของอุปกรณ์
  • การทดสอบแบบถดถอยในเมตริกประสิทธิภาพรันไทม์

การเสนอขายโดยใช้เวลาสั้นๆ

หน้าตาของ API ในข้อกําหนดปัจจุบันเป็นอย่างไร คุณสามารถดึงข้อมูลเกี่ยวกับเวลาของเธรดโปรแกรมแสดงผล ซึ่ง JavaScript, สไตล์ และเลย์เอาต์ทํางานอยู่ (คุณอาจเคยได้ยินว่าเทรดเดอร์เรนเดอร์เรียกว่าเทรดหลัก ซึ่งก็คือชื่อเรียกอีกอย่างของสิ่งเดียวกัน)

var rendererEvents = window.performance.getEntriesByType("renderer");

ระเบียนแต่ละรายการของเธรดโปรแกรมแสดงผลที่คุณได้รับจะมีลักษณะดังนี้

    {
      sourceFrameNumber: 120,
      startTime: 1342.549374253
      cpuTime: 6.454313323
    }

โดยพื้นฐานแล้ว แต่ละระเบียนคือออบเจ็กต์ที่มีหมายเลขเฟรมที่ไม่ซ้ำกัน การประทับเวลาความละเอียดสูงสำหรับเวลาที่เฟรมเริ่มต้น และอีกรายการสำหรับระยะเวลาที่ใช้ CPU เมื่อใช้อาร์เรย์เหล่านี้ คุณสามารถดูค่า startTime แต่ละค่าและดูว่าเธรดหลักทำงานที่ 60 fps หรือไม่ โดยพื้นฐานแล้ว "startTime ของเฟรมแต่ละเฟรมเพิ่มขึ้นเป็นกลุ่มๆ ประมาณ 16 มิลลิวินาทีหรือไม่"

แต่ที่สำคัญกว่านั้น คุณจะได้รับ cpuTime ด้วย เพื่อที่จะทราบว่าคุณอยู่ในขอบเขต 16 มิลลิวินาทีอย่างสบายๆ หรืออยู่ในขอบเขตแบบฉุกเฉิน หาก cpuTime อยู่ใกล้กับขอบเขต 16 มิลลิวินาที แสดงว่าระบบมีเวลาไม่มากนักสำหรับการดำเนินการต่างๆ เช่น การเริ่มรวบรวมขยะ และการใช้งาน CPU ที่สูงจะทำให้แบตเตอรี่หมดเร็วขึ้นด้วย

นอกจากข้อมูลของเธรดโปรแกรมแสดงผลแล้ว คุณยังดึงข้อมูลเกี่ยวกับเวลาของเธรดคอมโพสิตได้อีกด้วย ซึ่งจะเป็นที่ที่การวาดภาพและการคอมโพสิตเกิดขึ้น

var compositeThreadEvents = window.performance.getEntriesByType("composite");

แต่ละรายการเหล่านี้จะแสดงผลพร้อมหมายเลขเฟรมต้นทางด้วย ซึ่งคุณใช้เพื่อเชื่อมโยงกับเหตุการณ์ของเธรดหลักได้

{
    sourceFrameNumber: 120,
    startTime: 1352.343235321
}

เนื่องจากวิธีคอมโพสมักจะทํางานในเบราว์เซอร์ บันทึกเหล่านี้จึงอาจมีหลายรายการต่อบันทึกเธรดโปรแกรมแสดงผล 1 รายการ คุณจึงใช้ sourceFrameNumber เพื่อเชื่อมโยงบันทึกเหล่านั้นกลับเข้าด้วยกันได้ นอกจากนี้ ยังมีการสนทนากันว่าควรระบุเวลา CPU ในระเบียนเหล่านี้ด้วยหรือไม่ ดังนั้นหากคุณมีความเห็นที่แน่ชัด ก็แสดงความคิดเห็นในปัญหา GitHub

ข้อมูลเพิ่มเติม

API นี้ยังไม่พร้อมใช้งาน แต่หวังว่าจะพร้อมใช้งานเร็วๆ นี้ ในระหว่างนี้ คุณสามารถอ่านและทำสิ่งต่อไปนี้ได้