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

พอล ลูอิส
Twitter หน้าแรก

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

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

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

การใช้ Frame Timing API

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

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

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

นี่คือหน้าตาของ 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
}

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

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

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