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

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

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

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

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

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

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

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

ความจุ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• SOC 1 แสดงแต่ละเฟรมของเกณฑ์มาตรฐาน 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 และมีสองโหมด: touch latency และ bouncing ball (หากต้องการเปลี่ยนโหมด ให้คลิกปุ่มที่มุมบนขวา)

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

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

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

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