ใช้ Simpleperf เพื่อประเมินประสิทธิภาพของอุปกรณ์ Simpleperf เป็นเครื่องมือสร้างโปรไฟล์แบบเนทีฟสำหรับทั้ง แอปและกระบวนการแบบเนทีฟใน Android ใช้ เครื่องมือสร้างโปรไฟล์ CPU เพื่อตรวจสอบการใช้ CPU ของแอปและกิจกรรมของเทรดแบบเรียลไทม์
ตัวบ่งชี้ประสิทธิภาพที่ผู้ใช้มองเห็นได้มี 2 อย่าง ได้แก่
- ประสิทธิภาพที่คาดการณ์ได้และรับรู้ได้ อินเทอร์เฟซผู้ใช้ (UI) แสดงเฟรมตกหล่นหรือแสดงผลที่ 60 FPS อย่างสม่ำเสมอหรือไม่ เสียงเล่นโดยไม่มีสิ่งแปลกปลอมหรือเสียงแตกหรือไม่ ระยะเวลาที่ล่าช้าระหว่างที่ผู้ใช้แตะหน้าจอและเอฟเฟกต์ที่แสดงบนจอแสดงผลเป็นเท่าใด
- ระยะเวลาที่ต้องใช้สำหรับการดำเนินการที่ยาวนานขึ้น (เช่น การเปิดแอป)
อย่างแรกสังเกตได้ง่ายกว่าอย่างที่สอง โดยปกติผู้ใช้จะสังเกตเห็นอาการกระตุก แต่จะแยกความแตกต่างระหว่างเวลาเริ่มต้นของแอป 500 มิลลิวินาทีกับ 600 มิลลิวินาทีไม่ได้ เว้นแต่จะดูอุปกรณ์ 2 เครื่องพร้อมกัน ความหน่วงในการสัมผัสสังเกตเห็นได้ทันทีและมีส่วนสำคัญอย่างยิ่งต่อการรับรู้ถึงอุปกรณ์
ด้วยเหตุนี้ ในอุปกรณ์ที่รวดเร็ว ไปป์ไลน์ UI จึงเป็นสิ่งสำคัญที่สุดในระบบ นอกเหนือจากสิ่งที่จำเป็นเพื่อให้ไปป์ไลน์ UI ทำงานได้ ซึ่งหมายความว่าไปป์ไลน์ UI ควรมีลำดับความสำคัญเหนือกว่างานอื่นๆ ที่ไม่จำเป็นสำหรับ UI ที่ราบรื่น เพื่อให้ UI ราบรื่น การซิงค์ในเบื้องหลัง การส่งการแจ้งเตือน และงานที่คล้ายกันทั้งหมดจะต้องล่าช้าหากสามารถเรียกใช้งาน UI ได้ การแลกเปลี่ยนประสิทธิภาพของการดำเนินการที่ยาวนานขึ้น (รันไทม์ HDR+, การเริ่มต้นแอป ฯลฯ) เพื่อรักษา UI ที่ราบรื่นเป็นสิ่งที่ยอมรับได้
ความจุเทียบกับอาการกระตุก
เมื่อพิจารณาประสิทธิภาพของอุปกรณ์ ความจุและ อาการกระตุกเป็นเมตริกที่มีความหมาย 2 อย่าง
ความจุ
ความจุคือปริมาณรวมของทรัพยากรบางอย่างที่อุปกรณ์มีในช่วงระยะเวลาหนึ่ง ซึ่งอาจเป็นทรัพยากร CPU, ทรัพยากร GPU, ทรัพยากร I/O, ทรัพยากรเครือข่าย, แบนด์วิดท์หน่วยความจำ หรือเมตริกที่คล้ายกัน เมื่อตรวจสอบประสิทธิภาพของระบบทั้งหมด การแยกส่วนประกอบแต่ละรายการและสมมติเมตริกเดียวที่กำหนดประสิทธิภาพ (โดยเฉพาะอย่างยิ่งเมื่อปรับอุปกรณ์ใหม่เนื่องจากเวิร์กโหลดที่ทำงานบนอุปกรณ์นั้นมีแนวโน้มที่จะคงที่) อาจเป็นประโยชน์
ความจุของระบบจะแตกต่างกันไปตามทรัพยากรการประมวลผลที่ออนไลน์ การเปลี่ยนความถี่ CPU/GPU เป็นวิธีหลักในการเปลี่ยนความจุ แต่ก็มีวิธีอื่นๆ เช่น การเปลี่ยนจำนวนคอร์ CPU ที่ออนไลน์ ดังนั้น ความจุของระบบจึงสอดคล้องกับการใช้พลังงาน การเปลี่ยนความจุจะส่งผลให้การใช้พลังงานเปลี่ยนแปลงไปในลักษณะเดียวกันเสมอ
ความจุที่จำเป็นในเวลาหนึ่งๆ จะถูกกำหนดโดยแอปที่ทำงานอยู่เป็นส่วนใหญ่ ด้วยเหตุนี้ แพลตฟอร์มจึงทำได้เพียงเล็กน้อยในการปรับความจุที่จำเป็นสำหรับเวิร์กโหลดหนึ่งๆ และวิธีดำเนินการดังกล่าวจะจำกัดอยู่เพียงการปรับปรุงรันไทม์ (เฟรมเวิร์ก Android, ART, Bionic, คอมไพเลอร์/ไดรเวอร์ GPU, เคอร์เนล)
อาการกระตุก
แม้ว่าความจุที่จำเป็นสำหรับเวิร์กโหลดจะดูได้ง่าย แต่อาการกระตุกเป็นแนวคิดที่คลุมเครือกว่า หากต้องการทำความเข้าใจเบื้องต้นเกี่ยวกับอาการกระตุกที่เป็นอุปสรรคต่อระบบที่รวดเร็ว เราขอแนะนำให้อ่านเอกสารชื่อ The Case of the Missing Supercomputer Performance: Achieving Optimal Performance on the 8,192 processors of ASCI Q (เป็นการตรวจสอบว่าทำไมซูเปอร์คอมพิวเตอร์ ASCI Q จึงไม่สามารถทำได้ตามประสิทธิภาพที่คาดหวัง และเป็นข้อมูลเบื้องต้นที่ยอดเยี่ยมสำหรับการเพิ่มประสิทธิภาพระบบขนาดใหญ่)
หน้านี้ใช้คำว่า "อาการกระตุก" เพื่ออธิบายสิ่งที่เอกสาร ASCI Q เรียกว่า สัญญาณรบกวน อาการกระตุกคือลักษณะการทำงานของระบบแบบสุ่มที่ป้องกันไม่ให้งานที่รับรู้ได้ทำงาน ซึ่งมักจะเป็นงานที่ต้องเรียกใช้ แต่ไม่จำเป็นต้องมีข้อกำหนดด้านเวลาที่เข้มงวดซึ่งทำให้งานนั้นทำงานในเวลาใดเวลาหนึ่ง เนื่องจากเป็นแบบสุ่ม จึงเป็นเรื่องยากอย่างยิ่งที่จะพิสูจน์ว่าไม่มีอาการกระตุกสำหรับเวิร์กโหลดหนึ่งๆ นอกจากนี้ยังเป็นเรื่องยากอย่างยิ่งที่จะพิสูจน์ว่าแหล่งที่มาของอาการกระตุกที่ทราบเป็นสาเหตุของปัญหาด้านประสิทธิภาพหนึ่งๆ เครื่องมือที่ใช้บ่อยที่สุดในการวินิจฉัยสาเหตุของอาการกระตุก (เช่น การติดตามหรือการบันทึก) อาจทำให้เกิดอาการกระตุกขึ้นเอง
แหล่งที่มาของอาการกระตุกที่พบในการติดตั้งใช้งาน Android ในโลกแห่งความเป็นจริง ได้แก่
- ความล่าช้าของตัวจัดตารางเวลา
- ตัวจัดการการขัดจังหวะ
- โค้ดไดรเวอร์ทำงานนานเกินไปโดยปิดใช้การขัดจังหวะหรือการขัดจังหวะ
- Softirq ที่ใช้เวลานาน
- การช่วงชิงล็อก (แอป, เฟรมเวิร์ก, ไดรเวอร์เคอร์เนล, ล็อก Binder, ล็อก mmap)
- การช่วงชิงตัวอธิบายไฟล์ที่เธรดที่มีลำดับความสำคัญต่ำจะล็อกไฟล์ไว้ ทำให้เธรดที่มีลำดับความสำคัญสูงไม่สามารถทำงานได้
- การเรียกใช้โค้ดที่สำคัญต่อ UI ใน Workqueue ซึ่งอาจล่าช้า
- การเปลี่ยนสถานะไม่ได้ใช้งานของ CPU
- การบันทึก
- ความล่าช้าของ I/O
- การสร้างกระบวนการที่ไม่จำเป็น (เช่น การออกอากาศ
CONNECTIVITY_CHANGE) - การ Thrash ของแคชหน้าเว็บที่เกิดจากหน่วยความจำว่างไม่เพียงพอ
ระยะเวลาที่จำเป็นสำหรับอาการกระตุกในช่วงเวลาหนึ่งๆ อาจลดลงหรือไม่ลดลงเมื่อความจุเพิ่มขึ้น ตัวอย่างเช่น หากไดรเวอร์ปิดใช้การขัดจังหวะขณะรอการอ่านจากบัส i2c ไดรเวอร์จะใช้เวลาคงที่ไม่ว่า CPU จะอยู่ที่ 384 MHz หรือ 2 GHz การเพิ่มความจุไม่ใช่โซลูชันที่เหมาะสมในการปรับปรุงประสิทธิภาพเมื่อมีอาการกระตุกเข้ามาเกี่ยวข้อง ด้วยเหตุนี้ โปรเซสเซอร์ที่เร็วขึ้นจึงมักจะไม่ปรับปรุงประสิทธิภาพในสถานการณ์ที่มีข้อจำกัดด้านอาการกระตุก
สุดท้ายนี้ อาการกระตุกเกือบทั้งหมดอยู่ในขอบเขตของผู้จำหน่ายระบบ ซึ่งแตกต่างจากความจุ
การใช้หน่วยความจำ
โดยทั่วไปแล้วการใช้หน่วยความจำมักถูกตำหนิว่าเป็นสาเหตุของประสิทธิภาพต่ำ แม้ว่าการใช้หน่วยความจำเองจะไม่ใช่ปัญหาด้านประสิทธิภาพ แต่ก็อาจทำให้เกิดอาการกระตุกผ่านค่าใช้จ่ายเพิ่มเติมของ lowmemorykiller, การรีสตาร์ทบริการ และการทำงานหนักเกินไปของแคชหน้าเว็บ การลดการใช้หน่วยความจำสามารถหลีกเลี่ยงสาเหตุโดยตรงของประสิทธิภาพต่ำได้ แต่ก็อาจมีการปรับปรุงอื่นๆ ที่กำหนดเป้าหมายไว้ซึ่งหลีกเลี่ยงสาเหตุเหล่านั้นได้เช่นกัน (เช่น การปักหมุดเฟรมเวิร์กเพื่อป้องกันไม่ให้มีการเพจเอาต์เมื่อมีการเพจอินในเร็วๆ นี้)
วิเคราะห์ประสิทธิภาพเริ่มต้นของอุปกรณ์
การเริ่มต้นจากระบบที่ทำงานได้แต่มีประสิทธิภาพต่ำและพยายามแก้ไขลักษณะการทำงานของระบบโดยดูจากกรณีแต่ละกรณีที่มีประสิทธิภาพต่ำที่ผู้ใช้มองเห็นได้ ไม่ใช่ กลยุทธ์ที่เหมาะสม เนื่องจากประสิทธิภาพต่ำมักจะทำซ้ำได้ยาก (นั่นคือ อาการกระตุก) หรือเป็นปัญหาของแอป ตัวแปรจำนวนมากในระบบทั้งหมดจะป้องกันไม่ให้กลยุทธ์นี้มีประสิทธิภาพ ด้วยเหตุนี้ จึงเป็นเรื่องง่ายมากที่จะระบุสาเหตุผิดและทำการปรับปรุงเล็กน้อยในขณะที่พลาดโอกาสที่เป็นระบบในการแก้ไขประสิทธิภาพทั่วทั้งระบบ
แต่ให้ใช้วิธีการทั่วไปต่อไปนี้เมื่อนำอุปกรณ์ใหม่ขึ้นมา
- ทำให้ระบบบูตไปยัง UI โดยที่ไดรเวอร์ทั้งหมดทำงานอยู่และการตั้งค่าตัวควบคุมความถี่พื้นฐานบางอย่าง (หากคุณเปลี่ยนการตั้งค่าตัวควบคุมความถี่ ให้ทำซ้ำขั้นตอนทั้งหมดด้านล่าง)
- ตรวจสอบว่าเคอร์เนลรองรับจุดติดตาม
sched_blocked_reasonรวมถึงจุดติดตามอื่นๆ ในไปป์ไลน์การแสดงผลที่ระบุเวลาที่ส่งเฟรมไปยังจอแสดงผล - ใช้การติดตามที่ยาวนานของไปป์ไลน์ UI ทั้งหมด (ตั้งแต่รับอินพุตผ่าน IRQ ไปจนถึงการสแกนเอาต์ขั้นสุดท้าย) ขณะเรียกใช้งานเวิร์กโหลดที่มีน้ำหนักเบาและสอดคล้องกัน (เช่น UiBench หรือการทดสอบลูกบอลใน TouchLatency)
- แก้ไขเฟรมที่ตกหล่นซึ่งตรวจพบในเวิร์กโหลดที่มีน้ำหนักเบาและสอดคล้องกัน
- ทำซ้ำขั้นตอนที่ 3-4 จนกว่าคุณจะเรียกใช้งานโดยไม่มีเฟรมตกหล่นเป็นเวลา 20 วินาทีขึ้นไปในแต่ละครั้ง
- ย้ายไปที่แหล่งที่มาอื่นๆ ของอาการกระตุกที่ผู้ใช้มองเห็นได้
สิ่งง่ายๆ อื่นๆ ที่คุณทำได้ในช่วงแรกๆ ของการนำอุปกรณ์ขึ้นมา ได้แก่
- ตรวจสอบว่าเคอร์เนลมี แพตช์จุดติดตาม sched_blocked_reason จุดติดตามนี้เปิดใช้กับหมวดหมู่การติดตาม sched ใน systrace และให้ฟังก์ชันที่รับผิดชอบในการพักเมื่อเธรดนั้นเข้าสู่การพักที่ขัดจังหวะไม่ได้ ซึ่งมีความสำคัญอย่างยิ่งสำหรับการวิเคราะห์ประสิทธิภาพเนื่องจากการพักที่ขัดจังหวะไม่ได้เป็นตัวบ่งชี้ที่พบบ่อยมากของอาการกระตุก
- ตรวจสอบว่าคุณมีการติดตามที่เพียงพอสำหรับไปป์ไลน์ GPU และการแสดงผล ใน SOC ของ Qualcomm ล่าสุด จุดติดตามจะเปิดใช้โดยใช้คำสั่งต่อไปนี้
adb shell "echo 1 > /d/tracing/events/kgsl/enable"adb shell "echo 1 > /d/tracing/events/mdss/enable"
เหตุการณ์เหล่านี้จะยังคงเปิดใช้เมื่อคุณเรียกใช้ systrace เพื่อให้คุณเห็นข้อมูลเพิ่มเติมในการติดตามเกี่ยวกับไปป์ไลน์การแสดงผล (MDSS) ในส่วน mdss_fb0 ใน SOC ของ Qualcomm คุณจะไม่เห็นข้อมูลเพิ่มเติม
เกี่ยวกับ GPU ในมุมมอง systrace มาตรฐาน แต่ผลลัพธ์จะอยู่ในการติดตามเอง (ดูรายละเอียดได้ที่
ทำความเข้าใจ
systrace)
สิ่งที่คุณต้องการจากการติดตามการแสดงผลประเภทนี้คือเหตุการณ์เดียวที่บ่งชี้โดยตรงว่ามีการส่งเฟรมไปยังจอแสดงผลแล้ว จากนั้นคุณ จะกำหนดได้ว่าคุณทำได้ตามเวลาเฟรมที่กำหนดไว้หรือไม่ หากเหตุการณ์ Xn เกิดขึ้นน้อยกว่า 16.7 มิลลิวินาทีหลังจากเหตุการณ์ Xn-1 (สมมติว่าจอแสดงผล 60 Hz) แสดงว่าไม่มีอาการกระตุก หาก SOC ของคุณไม่มีสัญญาณดังกล่าว ให้ทำงานร่วมกับผู้จำหน่ายเพื่อขอสัญญาณ การแก้ไขข้อบกพร่องของอาการกระตุกเป็นเรื่องยากอย่างยิ่งหากไม่มีสัญญาณที่ชัดเจนว่าเฟรมเสร็จสมบูรณ์
ใช้เกณฑ์มาตรฐานสังเคราะห์
เกณฑ์มาตรฐานสังเคราะห์มีประโยชน์ในการตรวจสอบว่าอุปกรณ์มีฟังก์ชันพื้นฐาน อย่างไรก็ตาม การใช้เกณฑ์มาตรฐานเป็นตัวแทนของประสิทธิภาพของอุปกรณ์ที่รับรู้ได้นั้นไม่มีประโยชน์
จากประสบการณ์การใช้งาน SOC ความแตกต่างของประสิทธิภาพเกณฑ์มาตรฐานสังเคราะห์ระหว่าง SOC ไม่มีความสัมพันธ์กับความแตกต่างที่คล้ายกันในประสิทธิภาพ UI ที่รับรู้ได้ (จำนวนเฟรมที่ตกหล่น, เวลาเฟรมเปอร์เซ็นไทล์ที่ 99 ฯลฯ) เกณฑ์มาตรฐานสังเคราะห์เป็นเกณฑ์มาตรฐานด้านความจุเท่านั้น อาการกระตุกจะส่งผลต่อประสิทธิภาพที่วัดได้ของเกณฑ์มาตรฐานเหล่านี้โดยการขโมยเวลาจากการดำเนินการจำนวนมากของเกณฑ์มาตรฐานเท่านั้น ด้วยเหตุนี้ คะแนนเกณฑ์มาตรฐานสังเคราะห์จึงไม่เกี่ยวข้องเป็นส่วนใหญ่ในฐานะเมตริกของประสิทธิภาพที่ผู้ใช้รับรู้ได้
พิจารณา SOC 2 รายการที่เรียกใช้เกณฑ์มาตรฐาน X ซึ่งแสดงผลเฟรม UI 1,000 เฟรมและรายงานเวลารวมในการแสดงผล (คะแนนต่ำกว่าจะดีกว่า)
- SOC 1 แสดงผลเฟรมแต่ละเฟรมของเกณฑ์มาตรฐาน X ใน 10 มิลลิวินาทีและได้คะแนน 10,000
- SOC 2 แสดงผลเฟรม 99% ใน 1 มิลลิวินาที แต่แสดงผลเฟรม 1% ใน 100 มิลลิวินาทีและได้คะแนน 19,900 ซึ่งเป็นคะแนนที่ดีกว่าอย่างมาก
หากเกณฑ์มาตรฐานบ่งบอกถึงประสิทธิภาพ UI จริง SOC 2 จะใช้งานไม่ได้ โดยสมมติว่าอัตราการรีเฟรช 60 Hz SOC 2 จะมีเฟรมกระตุกทุกๆ 1.5 วินาทีของการทำงาน ในขณะเดียวกัน SOC 1 (SOC ที่ช้ากว่าตามเกณฑ์มาตรฐาน X) จะราบรื่นอย่างสมบูรณ์
ใช้รายงานข้อบกพร่อง
บางครั้งรายงานข้อบกพร่องก็มีประโยชน์สำหรับการวิเคราะห์ประสิทธิภาพ แต่เนื่องจากมีขนาดใหญ่มาก จึงไม่ค่อยมีประโยชน์ในการแก้ไขข้อบกพร่องของปัญหาอาการกระตุกเป็นครั้งคราว รายงานข้อบกพร่องอาจให้คำแนะนำบางอย่างเกี่ยวกับสิ่งที่ระบบกำลังทำอยู่ในช่วงเวลาหนึ่ง โดยเฉพาะอย่างยิ่งหากอาการกระตุกเกิดขึ้นระหว่างการเปลี่ยนแอป (ซึ่งจะมีการบันทึกในรายงานข้อบกพร่อง) รายงานข้อบกพร่องยังระบุได้ด้วยว่ามีบางอย่างผิดปกติกับระบบในวงกว้าง ซึ่งอาจลดความจุที่มีประสิทธิภาพของระบบ (เช่น การจำกัดความเร็วเนื่องจากความร้อนสูงเกินไปหรือการจัดสรรหน่วยความจำ)
ใช้ TouchLatency
ตัวอย่างลักษณะการทำงานที่ไม่ถูกต้องหลายอย่างมาจาก TouchLatency ซึ่งเป็นเวิร์กโหลดเป็นระยะๆ ที่ต้องการใช้สำหรับ Pixel และ Pixel XL โดยมีอยู่ที่ frameworks/base/tests/TouchLatency และมี 2 โหมด ได้แก่ ความหน่วงในการสัมผัสและลูกบอลกระดอน (หากต้องการเปลี่ยนโหมด ให้คลิกปุ่มที่มุมขวาบน)
การทดสอบลูกบอลกระดอนนั้นง่ายอย่างที่เห็น ลูกบอลจะกระดอนไปทั่วหน้าจอไปเรื่อยๆ ไม่ว่าข้อมูลจากผู้ใช้จะป้อนเข้ามาหรือไม่ก็ตาม โดยปกติแล้วการทดสอบนี้ยังเป็นการทดสอบที่ยากที่สุด ที่จะเรียกใช้อย่างสมบูรณ์แบบ แต่ยิ่งการทดสอบนี้ใกล้เคียงกับการเรียกใช้โดยไม่มีเฟรมตกหล่นมากเท่าใด อุปกรณ์ของคุณก็จะยิ่งดีขึ้นเท่านั้น การทดสอบลูกบอลกระดอนทำได้ยากเนื่องจากเป็นเวิร์กโหลดที่เล็กน้อยแต่สอดคล้องกันอย่างสมบูรณ์แบบซึ่งทำงานที่ความเร็วสัญญาณนาฬิกาต่ำมาก (สมมติว่าอุปกรณ์มีตัวควบคุมความถี่ หากอุปกรณ์ทำงานด้วยความเร็วสัญญาณนาฬิกาคงที่ ให้ลดความเร็วสัญญาณนาฬิกา CPU/GPU ลงจนเกือบต่ำสุดเมื่อเรียกใช้การทดสอบลูกบอลกระดอนเป็นครั้งแรก) เมื่อระบบเงียบลงและความเร็วสัญญาณนาฬิกาลดลงจนใกล้เคียงกับความเร็วสัญญาณนาฬิกาขณะไม่ได้ใช้งาน เวลา CPU/GPU ที่จำเป็นต่อเฟรมจะเพิ่มขึ้น คุณสามารถดูลูกบอลและสังเกตเห็นอาการกระตุก และจะเห็นเฟรมที่พลาดไปใน systrace ด้วย
เนื่องจากเวิร์กโหลดมีความสอดคล้องกันมาก คุณจึงระบุแหล่งที่มาส่วนใหญ่ของอาการกระตุกได้ง่ายกว่ามากเมื่อเทียบกับเวิร์กโหลดส่วนใหญ่ที่ผู้ใช้มองเห็นได้ โดยการติดตามสิ่งที่ทำงานอยู่ในระบบอย่างแน่นอนในระหว่างเฟรมที่พลาดไปแต่ละเฟรมแทนที่จะเป็นไปป์ไลน์ UI ความเร็วสัญญาณนาฬิกาที่ต่ำกว่าจะขยายผลของอาการกระตุกโดยทำให้มีแนวโน้มมากขึ้นที่อาการกระตุกจะทำให้เกิดเฟรมตกหล่น ด้วยเหตุนี้ ยิ่ง TouchLatency ใกล้เคียงกับ 60 FPS มากเท่าใด คุณก็ยิ่งมีแนวโน้มน้อยลงที่จะมีลักษณะการทำงานที่ไม่ดีของระบบซึ่งทำให้เกิดอาการกระตุกเป็นครั้งคราวที่ทำซ้ำได้ยากในแอปขนาดใหญ่
เนื่องจากอาการกระตุกมัก (แต่ไม่เสมอไป) ไม่เปลี่ยนแปลงตามความเร็วสัญญาณนาฬิกา ให้ใช้การทดสอบที่ทำงานที่ความเร็วสัญญาณนาฬิกาต่ำมากเพื่อวินิจฉัยอาการกระตุกด้วยเหตุผลต่อไปนี้
- อาการกระตุกบางอย่างไม่ได้ไม่เปลี่ยนแปลงตามความเร็วสัญญาณนาฬิกา แหล่งที่มาจำนวนมากเพียงแค่ใช้เวลา CPU
- ตัวควบคุมควรทำให้เวลาเฟรมเฉลี่ยใกล้เคียงกับกำหนดเวลาโดยการลดความเร็วสัญญาณนาฬิกา ดังนั้นเวลาที่ใช้ในการเรียกใช้งานที่ไม่ใช่ UI อาจทำให้เวลาเฟรมเฉลี่ยเกินกำหนดเวลาจนทำให้เกิดเฟรมตกหล่น