การประเมินประสิทธิภาพ

ใช้ Simpleperf เพื่อประเมินประสิทธิภาพของอุปกรณ์ Simpleperf เป็นเครื่องมือสร้างโปรไฟล์ดั้งเดิมสำหรับทั้งแอปพลิเคชันและกระบวนการดั้งเดิมบน Android ใช้ CPU Profiler เพื่อตรวจสอบการใช้งาน CPU ของแอปและกิจกรรมเธรดแบบเรียลไทม์

มีตัวบ่งชี้ประสิทธิภาพที่ผู้ใช้มองเห็นได้สองตัว:

• ประสิทธิภาพที่คาดการณ์ได้และรับรู้ได้ ส่วนติดต่อผู้ใช้ (UI) ปล่อยเฟรมหรือแสดงผลสม่ำเสมอที่ 60FPS หรือไม่ เล่นเสียงโดยไม่มีสิ่งประดิษฐ์หรือเสียงแตกหรือไม่? ความล่าช้าระหว่างผู้ใช้สัมผัสหน้าจอและเอฟเฟกต์ที่แสดงบนหน้าจอนานแค่ไหน?
• ระยะเวลาที่จำเป็นสำหรับการดำเนินการที่ยาวนานขึ้น (เช่น การเปิดแอปพลิเคชัน)

ครั้งแรกจะเห็นได้ชัดเจนกว่าครั้งที่สอง โดยทั่วไปผู้ใช้จะสังเกตเห็นข้อผิดพลาด แต่จะไม่สามารถบอกเวลาเริ่มต้นแอปพลิเคชัน 500ms และ 600ms ได้ เว้นแต่ว่าพวกเขาจะดูอุปกรณ์สองเครื่องเคียงข้างกัน เวลาแฝงของการสัมผัสจะสังเกตเห็นได้ทันทีและมีส่วนอย่างมากต่อการรับรู้ของอุปกรณ์

ด้วยเหตุนี้ ในอุปกรณ์ที่รวดเร็ว ไปป์ไลน์ UI จึงเป็นสิ่งสำคัญที่สุดในระบบ นอกเหนือจากที่จำเป็นเพื่อให้ไปป์ไลน์ UI ทำงานได้ ซึ่งหมายความว่าไปป์ไลน์ UI ควรยึดงานอื่นใดที่ไม่จำเป็นสำหรับ UI ที่ลื่นไหล เพื่อรักษา UI ที่ลื่นไหล การซิงค์ในพื้นหลัง การส่งการแจ้งเตือน และงานที่คล้ายกันจะต้องล่าช้าทั้งหมดหากสามารถเรียกใช้งาน UI ได้ เป็นที่ยอมรับในการแลกเปลี่ยนประสิทธิภาพของการดำเนินการที่ยาวนานกว่า (รันไทม์ HDR+, การเริ่มต้นแอปพลิเคชัน ฯลฯ) เพื่อรักษา UI ที่ลื่นไหล

ความจุเทียบกับความกระวนกระวายใจ

เมื่อพิจารณาถึงประสิทธิภาพของอุปกรณ์ ความจุ และ ความกระวนกระวายใจ เป็นสองตัวชี้วัดที่มีความหมาย

ความจุ

ความจุคือจำนวนทรัพยากรทั้งหมดที่อุปกรณ์มีอยู่ในช่วงเวลาหนึ่ง ซึ่งอาจเป็นทรัพยากร CPU, ทรัพยากร GPU, ทรัพยากร I/O, ทรัพยากรเครือข่าย, แบนด์วิดท์หน่วยความจำ หรือตัวชี้วัดใดๆ ที่คล้ายกัน เมื่อตรวจสอบประสิทธิภาพทั้งระบบ อาจมีประโยชน์ในการสรุปแต่ละส่วนประกอบและถือว่าตัววัดตัวเดียวที่กำหนดประสิทธิภาพ (โดยเฉพาะอย่างยิ่งเมื่อปรับแต่งอุปกรณ์ใหม่เนื่องจากปริมาณงานที่รันบนอุปกรณ์นั้นมีแนวโน้มที่จะได้รับการแก้ไขแล้ว)

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

ความจุที่ต้องการในเวลาที่กำหนดถูกกำหนดโดยแอปพลิเคชันที่ทำงานอยู่อย่างท่วมท้น ด้วยเหตุนี้ แพลตฟอร์มจึงสามารถปรับความจุที่จำเป็นสำหรับปริมาณงานที่กำหนดได้เพียงเล็กน้อย และวิธีการดังกล่าวจำกัดอยู่เพียงการปรับปรุงรันไทม์ (เฟรมเวิร์ก Android, ART, ไบโอนิค, คอมไพเลอร์/ไดรเวอร์ GPU, เคอร์เนล)

กระวนกระวายใจ

แม้ว่าความจุที่จำเป็นสำหรับปริมาณงานจะมองเห็นได้ง่าย แต่ความกระวนกระวายใจนั้นเป็นแนวคิดที่คลุมเครือมากกว่า หากต้องการทราบเบื้องต้นเกี่ยวกับ jitter ซึ่งเป็นอุปสรรคต่อระบบที่รวดเร็ว โปรดดู กรณีประสิทธิภาพการทำงานของซูเปอร์คอมพิวเตอร์ที่หายไป: การบรรลุประสิทธิภาพที่เหมาะสมที่สุดบนโปรเซสเซอร์ 8,192 ตัวของ ASCl Q (เป็นการตรวจสอบว่าเหตุใดซูเปอร์คอมพิวเตอร์ ASCI Q จึงไม่บรรลุประสิทธิภาพตามที่คาดหวัง และเป็นการแนะนำที่ดีในการเพิ่มประสิทธิภาพระบบขนาดใหญ่)

หน้านี้ใช้คำว่า jitter เพื่ออธิบายสิ่งที่กระดาษ ASCI Q เรียกว่า Noise กระวนกระวายใจคือพฤติกรรมของระบบแบบสุ่มที่ป้องกันไม่ให้งานที่รับรู้ทำงานได้ มักเป็นงานที่ต้องดำเนินการ แต่อาจไม่มีข้อกำหนดด้านเวลาที่เข้มงวดซึ่งทำให้ต้องรันในเวลาใดเวลาหนึ่ง เนื่องจากเป็นการสุ่ม จึงเป็นเรื่องยากมากที่จะหักล้างการมีอยู่ของความกระวนกระวายใจสำหรับเวิร์กโหลดที่กำหนด นอกจากนี้ยังเป็นเรื่องยากมากที่จะพิสูจน์ว่าแหล่งที่มาของความกระวนกระวายใจนั้นเป็นสาเหตุของปัญหาประสิทธิภาพการทำงานโดยเฉพาะ เครื่องมือที่ใช้กันมากที่สุดในการวินิจฉัยสาเหตุของการกระวนกระวายใจ (เช่น การติดตามหรือการบันทึก) สามารถทำให้เกิดความกระวนกระวายใจของตัวเองได้

แหล่งที่มาของความกระวนกระวายใจที่พบในการใช้งาน Android ในโลกแห่งความเป็นจริง ได้แก่ :

• ความล่าช้าของตัวกำหนดเวลา
• ขัดจังหวะตัวจัดการ
• รหัสไดรเวอร์ทำงานนานเกินไปโดยปิดใช้งานการจองล่วงหน้าหรือการขัดจังหวะ
• softirqs ที่ใช้งานได้ยาวนาน
• การช่วงชิงการล็อค (แอปพลิเคชัน, เฟรมเวิร์ก, ไดรเวอร์เคอร์เนล, การล็อคเครื่องผูก, การล็อค mmap)
• ข้อโต้แย้งตัวอธิบายไฟล์ที่เธรดที่มีลำดับความสำคัญต่ำล็อคไว้บนไฟล์ ป้องกันไม่ให้เธรดที่มีลำดับความสำคัญสูงทำงาน
• การเรียกใช้โค้ดที่มีความสำคัญต่อ UI ในคิวงานซึ่งอาจล่าช้าได้
• การเปลี่ยนแปลงที่ไม่ได้ใช้งานของ CPU
• การบันทึก
• ความล่าช้าของ I/O
• การสร้างกระบวนการที่ไม่จำเป็น (เช่น การออกอากาศ CONNECTIVITY_CHANGE)
• แคชของเพจพังที่เกิดจากหน่วยความจำว่างไม่เพียงพอ

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

สุดท้ายนี้ ไม่เหมือนกับความจุตรงที่ความกระวนกระวายใจเกือบทั้งหมดอยู่ภายในโดเมนของผู้จำหน่ายระบบ

การใช้หน่วยความจำ

การใช้หน่วยความจำมักถูกตำหนิว่ามีประสิทธิภาพต่ำ แม้ว่าการบริโภคจะไม่ใช่ปัญหาด้านประสิทธิภาพ แต่ก็อาจทำให้เกิดการกระวนกระวายใจผ่านค่าใช้จ่าย lowmemorykiller การรีสตาร์ทบริการ และแคชของเพจพัง การลดการใช้หน่วยความจำสามารถหลีกเลี่ยงสาเหตุโดยตรงของประสิทธิภาพที่ไม่ดี แต่อาจมีการปรับปรุงที่กำหนดเป้าหมายอื่นๆ ที่หลีกเลี่ยงสาเหตุเหล่านั้นเช่นกัน (ตัวอย่างเช่น การปักหมุดกรอบงานเพื่อป้องกันไม่ให้ถูกเพจออกเมื่อจะถูกเพจในเร็วๆ นี้หลังจากนั้น)

การวิเคราะห์ประสิทธิภาพอุปกรณ์เริ่มต้น

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

ให้ใช้วิธีการทั่วไปต่อไปนี้แทนเมื่อเปิดอุปกรณ์ใหม่:

1. ให้ระบบบูทไปที่ UI โดยที่ไดรเวอร์ทั้งหมดทำงานอยู่และการตั้งค่าตัวควบคุมความถี่พื้นฐานบางอย่าง (หากคุณเปลี่ยนการตั้งค่าตัวควบคุมความถี่ ให้ทำซ้ำขั้นตอนทั้งหมดด้านล่าง)
2. ตรวจสอบให้แน่ใจว่าเคอร์เนลรองรับจุดติดตาม sched_blocked_reason เช่นเดียวกับจุดติดตามอื่นๆ ในไปป์ไลน์การแสดงผลที่แสดงว่าเฟรมถูกส่งไปยังจอแสดงผลเมื่อใด
3. ติดตามไปป์ไลน์ UI ทั้งหมดอย่างยาวนาน (ตั้งแต่การรับอินพุตผ่าน IRQ ไปจนถึงการสแกนครั้งสุดท้าย) ในขณะที่รันเวิร์กโหลดที่เบาและสม่ำเสมอ (เช่น UiBench หรือการทดสอบบอลใน TouchLatency)
4. แก้ไขการตกของเฟรมที่ตรวจพบในปริมาณงานที่เบาและสม่ำเสมอ
5. ทำซ้ำขั้นตอนที่ 3-4 จนกว่าคุณจะสามารถวิ่งโดยไม่มีเฟรมหลุดเป็นเวลา 20+ วินาทีในแต่ละครั้ง
6. ไปยังแหล่งที่มาของ jank อื่นๆ ที่ผู้ใช้มองเห็นได้

สิ่งง่ายๆ อื่นๆ ที่คุณสามารถทำได้ตั้งแต่เนิ่นๆ ในการเรียกอุปกรณ์ ได้แก่:

• ตรวจสอบให้แน่ใจว่าเคอร์เนลของคุณมี แพทช์ติดตามจุด sched_blocked_reason จุดติดตามนี้เปิดใช้งานด้วยหมวดหมู่การติดตามตามกำหนดเวลาใน systrace และจัดเตรียมฟังก์ชันที่รับผิดชอบในการนอนหลับเมื่อเธรดนั้นเข้าสู่โหมดสลีปอย่างต่อเนื่อง เป็นสิ่งสำคัญสำหรับการวิเคราะห์ประสิทธิภาพ เนื่องจากการนอนหลับอย่างต่อเนื่องเป็นตัวบ่งชี้ความกระวนกระวายใจที่พบบ่อยมาก
• ตรวจสอบให้แน่ใจว่าคุณมีการติดตามเพียงพอสำหรับ GPU และไปป์ไลน์การแสดงผล ใน Qualcomm SOC ล่าสุด จุดติดตามถูกเปิดใช้งานโดยใช้:

adb shell "echo 1 > /d/tracing/events/kgsl/enable"
adb shell "echo 1 > /d/tracing/events/mdss/enable"

เหตุการณ์เหล่านี้ยังคงเปิดใช้งานเมื่อคุณเรียกใช้ systrace เพื่อให้คุณสามารถดูข้อมูลเพิ่มเติมในการสืบค้นกลับเกี่ยวกับไปป์ไลน์การแสดงผล (MDSS) ในส่วน mdss_fb0 บน Qualcomm SOC คุณจะไม่เห็นข้อมูลเพิ่มเติมใดๆ เกี่ยวกับ GPU ในมุมมองระบบมาตรฐาน แต่ผลลัพธ์จะแสดงอยู่ในการติดตาม (สำหรับรายละเอียด โปรดดู การทำความเข้าใจระบบ systrace )

สิ่งที่คุณต้องการจากการติดตามการแสดงผลประเภทนี้คือเหตุการณ์เดียวที่บ่งบอกโดยตรงว่ามีการส่งเฟรมไปยังจอแสดงผลแล้ว จากนั้น คุณจะสามารถทราบได้ว่าคุณได้ใช้เฟรมไทม์สำเร็จหรือไม่ หากเหตุการณ์ X n เกิดขึ้นน้อยกว่า 16.7ms หลังจากเหตุการณ์ X n-1 (สมมติว่าเป็นจอแสดงผล 60Hz) คุณจะรู้ว่าคุณไม่ได้ jak หาก SOC ของคุณไม่ได้ส่งสัญญาณดังกล่าว ให้ทำงานร่วมกับผู้จำหน่ายของคุณเพื่อรับสัญญาณดังกล่าว การดีบักการกระวนกระวายใจเป็นเรื่องยากมากหากไม่มีสัญญาณที่แน่ชัดว่าเฟรมเสร็จสมบูรณ์

การใช้เกณฑ์มาตรฐานสังเคราะห์

การวัดประสิทธิภาพสังเคราะห์มีประโยชน์ในการรับรองว่ามีฟังก์ชันพื้นฐานของอุปกรณ์อยู่ อย่างไรก็ตาม การใช้เกณฑ์มาตรฐานเสมือนเป็นพร็อกซีสำหรับประสิทธิภาพของอุปกรณ์ที่รับรู้นั้นไม่มีประโยชน์

จากประสบการณ์กับ SOC ความแตกต่างในประสิทธิภาพเกณฑ์มาตรฐานสังเคราะห์ระหว่าง SOC ไม่มีความสัมพันธ์กับความแตกต่างที่คล้ายกันในประสิทธิภาพ UI ที่รับรู้ได้ (จำนวนเฟรมที่ตก เวลาเฟรมเปอร์เซ็นไทล์ที่ 99 ฯลฯ) การวัดประสิทธิภาพสังเคราะห์คือการวัดประสิทธิภาพเฉพาะความจุเท่านั้น ความกระวนกระวายใจส่งผลกระทบต่อประสิทธิภาพที่วัดได้ของการวัดประสิทธิภาพเหล่านี้โดยการขโมยเวลาจากการดำเนินการจำนวนมากของการวัดประสิทธิภาพเท่านั้น ด้วยเหตุนี้ คะแนนมาตรฐานสังเคราะห์จึงส่วนใหญ่ไม่เกี่ยวข้องในฐานะตัวชี้วัดประสิทธิภาพที่ผู้ใช้รับรู้

พิจารณา SOC สองตัวที่ใช้ Benchmark X ซึ่งเรนเดอร์ UI ได้ 1,000 เฟรม และรายงานเวลาเรนเดอร์ทั้งหมด (คะแนนต่ำกว่าจะดีกว่า)

• SOC 1 เรนเดอร์แต่ละเฟรมของ Benchmark X ใน 10 มิลลิวินาที และได้คะแนน 10,000
• SOC 2 เรนเดอร์ 99% ของเฟรมใน 1 มิลลิวินาที แต่ 1% ของเฟรมใน 100 มิลลิวินาที และได้คะแนน 19,900 ซึ่งเป็นคะแนนที่ดีกว่าอย่างมาก

หากเกณฑ์มาตรฐานบ่งบอกถึงประสิทธิภาพ UI ที่แท้จริง SOC 2 จะไม่สามารถใช้งานได้ สมมติว่าอัตราการรีเฟรช 60Hz SOC 2 จะมีเฟรมที่ไม่สม่ำเสมอทุกๆ 1.5 วินาทีของการทำงาน ในขณะเดียวกัน SOC 1 (SOC ที่ช้ากว่าตามเกณฑ์มาตรฐาน X) จะเป็นของเหลวอย่างสมบูรณ์แบบ

การใช้รายงานข้อผิดพลาด

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

การใช้ TouchLatency

ตัวอย่างพฤติกรรมที่ไม่ดีหลายตัวอย่างมาจาก TouchLatency ซึ่งเป็นปริมาณงานตามระยะเวลาที่ต้องการสำหรับ Pixel และ Pixel XL มีให้บริการที่ frameworks/base/tests/TouchLatency และมีสองโหมด: เวลาแฝงแบบสัมผัสและลูกบอลเด้ง (หากต้องการสลับโหมด ให้คลิกปุ่มที่มุมขวาบน)

การทดสอบลูกบอลกระดอนนั้นง่ายเหมือนที่ปรากฏ: ลูกบอลจะกระดอนไปรอบๆ หน้าจอตลอดไป ไม่ว่าผู้ใช้จะป้อนข้อมูลอย่างไรก็ตาม โดยปกติแล้วจะเป็นการทดสอบที่ยาก ที่สุด ในการทำงานอย่างสมบูรณ์แบบ แต่ยิ่งเข้าใกล้การทำงานโดยไม่มีเฟรมตก อุปกรณ์ของคุณก็จะยิ่งดีขึ้นเท่านั้น การทดสอบลูกบอลกระดอนนั้นทำได้ยากเนื่องจากเป็นเวิร์กโหลดเล็กน้อยแต่มีความสม่ำเสมออย่างสมบูรณ์แบบซึ่งทำงานที่สัญญาณนาฬิกาต่ำมาก (ซึ่งถือว่าอุปกรณ์มีตัวควบคุมความถี่ หากอุปกรณ์ทำงานด้วยนาฬิกาคงที่แทน ให้ดาวน์คล็อก CPU/GPU ให้ใกล้ค่าต่ำสุด เมื่อทำการทดสอบลูกเด้งครั้งแรก) เมื่อระบบหยุดทำงานและนาฬิกาเข้าใกล้สถานะไม่ได้ใช้งาน เวลา CPU/GPU ที่ต้องการต่อเฟรมจะเพิ่มขึ้น คุณสามารถดูลูกบอลและมองเห็นสิ่งต่าง ๆ ที่ขาดหายไป และคุณจะสามารถเห็นเฟรมที่พลาดใน systrace ได้เช่นกัน

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

เนื่องจากความกระวนกระวายใจมักจะไม่แปรผันตามความเร็วสัญญาณนาฬิกา (แต่ไม่เสมอไป) ให้ใช้การทดสอบที่ทำงานที่นาฬิกาที่ต่ำมากเพื่อวินิจฉัยความกระวนกระวายใจด้วยเหตุผลต่อไปนี้:

• ไม่ใช่ว่าความกระวนกระวายใจทั้งหมดจะแปรผันตามความเร็วสัญญาณนาฬิกา แหล่งที่มาหลายแห่งใช้เวลา CPU เท่านั้น
• Governor ควรได้รับเวลาเฉลี่ยของเฟรมให้ใกล้กับกำหนดเวลาโดยการตอกบัตรลง ดังนั้น เวลาที่ใช้ในการรันงานที่ไม่ใช่ UI จึงสามารถดันงานนั้นข้ามขอบจนทำให้เฟรมตกได้