ใช้ Simpleperf เพื่อประเมินประสิทธิภาพของอุปกรณ์ Simpleperf เป็นเครื่องมือโปรไฟล์แบบเนทีฟสำหรับทั้งแอปและกระบวนการเนทีฟใน Android ใช้เครื่องมือวิเคราะห์โปรไฟล์ CPU เพื่อตรวจสอบการใช้งาน CPU ของแอปและกิจกรรมของชุดข้อความแบบเรียลไทม์
ตัวบ่งชี้ประสิทธิภาพที่ผู้ใช้มองเห็นได้มีอยู่ 2 รายการ ได้แก่
- ประสิทธิภาพที่คาดการณ์ได้และสังเกตได้ อินเทอร์เฟซผู้ใช้ (UI) ตัดเฟรมหรือแสดงผลที่ 60FPS อย่างต่อเนื่องไหม เสียงเล่นโดยไม่มีสิ่งแปลกปลอมหรือเสียงแตกไหม ระยะเวลาที่ล่าช้าระหว่างที่ผู้ใช้แตะหน้าจอกับเวลาที่เอฟเฟกต์แสดงบนจอแสดงผลนานเท่าใด
- ระยะเวลาที่ใช้ในการดำเนินการที่นานขึ้น (เช่น การเปิดแอป)
ข้อความแรกเห็นได้ชัดกว่าข้อความที่ 2 โดยทั่วไปผู้ใช้จะสังเกตเห็นการกระตุก แต่ไม่สามารถบอกได้ว่าเวลาเริ่มต้นของแอป 500 ms กับ 600 ms แตกต่างกันอย่างไร เว้นแต่ว่าผู้ใช้จะดูอุปกรณ์ 2 เครื่องพร้อมกัน เวลาในการตอบสนองต่อการสัมผัสจะสังเกตเห็นได้ทันทีและส่งผลต่อความรู้สึกของผู้ใช้ได้อย่างมาก
ดังนั้นในอุปกรณ์ที่ทำงานเร็ว ไปป์ไลน์ UI จึงเป็นสิ่งสําคัญที่สุดในระบบนอกเหนือจากสิ่งที่จําเป็นต่อการทํางานของไปป์ไลน์ UI ซึ่งหมายความว่าไปป์ไลน์ UI ควรมีลำดับความสำคัญเหนือกว่างานอื่นๆ ที่ไม่จำเป็นสำหรับ UI ที่ราบรื่น หากต้องการให้ UI ทำงานได้อย่างราบรื่น ระบบจะต้องเลื่อนเวลาการซิงค์ในเบื้องหลัง การแสดงการแจ้งเตือน และงานอื่นๆ ที่คล้ายกันทั้งหมด หากสามารถเรียกใช้งาน UI ได้ คุณยอมรับได้ว่าประสิทธิภาพของการดำเนินการที่นานขึ้น (รันไทม์ HDR+, การเริ่มต้นแอป ฯลฯ) เพื่อรักษา UI ให้ลื่นไหล
ความจุเทียบกับ Jitter
เมื่อพิจารณาประสิทธิภาพของอุปกรณ์ ความจุและความผันผวนเป็น 2 เมตริกที่มีความหมาย
ความจุ
ความจุคือปริมาณทรัพยากรบางอย่างทั้งหมดที่อุปกรณ์มีในช่วงเวลาหนึ่ง ซึ่งอาจเป็นทรัพยากร CPU, ทรัพยากร GPU, ทรัพยากร I/O, ทรัพยากรเครือข่าย, แบนด์วิดท์ของหน่วยความจำ หรือเมตริกที่คล้ายกัน เมื่อตรวจสอบประสิทธิภาพทั้งระบบ การแยกองค์ประกอบแต่ละอย่างออกและสมมติว่าเมตริกเดียวเป็นตัวกำหนดประสิทธิภาพอาจมีประโยชน์ (โดยเฉพาะเมื่อปรับแต่งอุปกรณ์ใหม่ เนื่องจากปริมาณงานที่ทำงานในอุปกรณ์นั้นๆ มีแนวโน้มที่จะคงที่)
ความสามารถของระบบจะแตกต่างกันไปตามทรัพยากรการประมวลผลออนไลน์ การเปลี่ยนความถี่ของ CPU/GPU เป็นวิธีหลักในการเปลี่ยนความจุ แต่ก็มีวิธีอื่นๆ เช่น การเปลี่ยนจำนวนแกน CPU ที่ออนไลน์ ดังนั้น ความสามารถของระบบจึงสอดคล้องกับการใช้พลังงาน การเปลี่ยนแปลงความสามารถจึงส่งผลให้เกิดการเปลี่ยนแปลงที่คล้ายกันในการใช้พลังงานเสมอ
ความจุที่จําเป็น ณ เวลาหนึ่งๆ ส่วนใหญ่จะกําหนดโดยแอปที่ทํางานอยู่ แพลตฟอร์มจึงปรับความจุที่จําเป็นสําหรับภาระงานหนึ่งๆ ได้เพียงเล็กน้อย และวิธีที่จะทําเช่นนั้นได้จํากัดอยู่ที่การปรับปรุงรันไทม์ (เฟรมเวิร์ก Android, ART, Bionic, คอมไพเลอร์/ไดรเวอร์ GPU, เคอร์เนล)
เสียงรบกวน
แม้ว่าความจุที่จําเป็นสําหรับปริมาณงานจะดูได้ง่าย แต่ความผันผวนเป็นแนวคิดที่คลุมเครือมากกว่า หากต้องการทราบข้อมูลเบื้องต้นเกี่ยวกับความผันผวนของเวลาเป็นอุปสรรคต่อระบบที่ทำงานเร็ว เราขอแนะนำให้อ่านบทความชื่อ The Case of the Missing Supercomputer Performance: Achieving Optimal Performance on 8,192 processors of ASCI Q (บทความนี้เป็นการสำรวจสาเหตุที่ซูเปอร์คอมพิวเตอร์ ASCI Q ไม่ได้ประสิทธิภาพตามที่คาดไว้ และเป็นข้อมูลเบื้องต้นที่ยอดเยี่ยมเกี่ยวกับการเพิ่มประสิทธิภาพระบบขนาดใหญ่)
หน้านี้ใช้คำว่า "การกระวนกระวาย" เพื่ออธิบายสิ่งที่เอกสาร ASCI Q เรียกว่าสัญญาณรบกวน อาการกระตุกคือลักษณะการทํางานของระบบแบบสุ่มที่ทําให้งานไม่สามารถทํางานได้ มักเป็นงานที่จําเป็นต้องทํา แต่อาจไม่มีข้อกําหนดด้านเวลาอย่างเข้มงวดซึ่งทําให้ต้องทํางานในเวลาที่เจาะจง เนื่องจากเป็นค่าแบบสุ่ม การพิสูจน์ว่าไม่มี Jitter สำหรับปริมาณงานหนึ่งๆ จึงทำได้ยากมาก นอกจากนี้ การพิสูจน์ว่าแหล่งที่มาของเวลาในการตอบสนองที่ทราบเป็นสาเหตุของปัญหาด้านประสิทธิภาพนั้นเป็นเรื่องยากมาก เครื่องมือที่ใช้กันมากที่สุดในการวินิจฉัยสาเหตุของอาการกระตุก (เช่น การติดตามหรือการบันทึก) อาจทำให้เกิดอาการกระตุกได้
แหล่งที่มาของอาการกระตุกที่พบในการใช้งาน Android ในชีวิตจริงมีดังนี้
- ความล่าช้าของเครื่องมือตั้งเวลา
- เครื่องจัดการการขัดจังหวะ
- โค้ดไดรเวอร์ทำงานนานเกินไปโดยปิดใช้การแย่งสิทธิ์หรือขัดจังหวะ
- Softirq ที่ทำงานเป็นเวลานาน
- การแย่งสิทธิ์เข้าถึงล็อก (แอป เฟรมเวิร์ก ไดรเวอร์เคอร์เนล ล็อก Binder, mmap lock)
- การแย่งกันใช้ตัวระบุไฟล์เมื่อชุดข้อความที่มีลําดับความสําคัญต่ำถือการล็อกไฟล์ไว้ ซึ่งทําให้ชุดข้อความที่มีลําดับความสําคัญสูงทํางานไม่ได้
- การเรียกใช้โค้ดสําคัญของ UI ในคิวงานที่อาจเกิดความล่าช้า
- การเปลี่ยนสถานะจากทำงานอยู่เป็นไม่มีการทำงานใน CPU
- การบันทึก
- ความล่าช้าของ I/O
- การสร้างกระบวนการที่ไม่จำเป็น (เช่น การออกอากาศ
CONNECTIVITY_CHANGE) - การเรียกใช้แคชหน้าเว็บมากเกินไปที่เกิดจากหน่วยความจําว่างไม่เพียงพอ
ระยะเวลาที่จ jitter หนึ่งๆ ต้องใช้อาจลดลงหรือไม่ลดลงเมื่อความจุเพิ่มขึ้น เช่น หากไดรเวอร์ปิดใช้การขัดจังหวะขณะรอการอ่านจากบัส i2c ระบบจะใช้เวลาตามจำนวนที่กำหนดไว้ ไม่ว่า CPU จะอยู่ที่ 384 MHz หรือ 2 GHz ก็ตาม การเพิ่มความจุไม่ใช่วิธีแก้ปัญหาที่เป็นไปได้ในการปรับปรุงประสิทธิภาพเมื่อมี jitter เกิดขึ้น ด้วยเหตุนี้ โดยทั่วไปแล้ว โปรเซสเซอร์ที่เร็วขึ้นจะไม่ปรับปรุงประสิทธิภาพในสถานการณ์ที่มีข้อจำกัดด้านความผันผวน
สุดท้าย Jitter เกือบทั้งหมดจะอยู่ในขอบเขตของผู้ให้บริการระบบ ต่างจากความจุ
การใช้หน่วยความจำ
โดยทั่วไปแล้ว การใช้หน่วยความจํามักถูกกล่าวหาว่าเป็นสาเหตุของประสิทธิภาพที่ไม่ดี แม้ว่าการบริโภคเองไม่ใช่ปัญหาด้านประสิทธิภาพ แต่อาจทำให้เกิดความผันผวนผ่านค่าใช้จ่ายเพิ่มเติมของ lowmemorykiller, การรีสตาร์ทบริการ และการแคชหน้าเว็บที่ทำงานหนัก การลดการใช้หน่วยความจําช่วยหลีกเลี่ยงสาเหตุโดยตรงของประสิทธิภาพที่ไม่ดีได้ แต่อาจมีการปรับปรุงอื่นๆ ที่มุ่งเน้นที่หลีกเลี่ยงสาเหตุเหล่านั้นด้วย (เช่น การปักหมุดเฟรมเวิร์กเพื่อป้องกันไม่ให้ระบบย้ายเฟรมเวิร์กออกเมื่อระบบจะย้ายเฟรมเวิร์กกลับเข้ามาในไม่ช้า)
วิเคราะห์ประสิทธิภาพของอุปกรณ์ครั้งแรก
การเริ่มต้นจากระบบที่ใช้งานได้แต่มีประสิทธิภาพต่ำและพยายามแก้ไขลักษณะการทํางานของระบบโดยพิจารณาจากแต่ละกรณีที่ประสิทธิภาพต่ำซึ่งผู้ใช้มองเห็นไม่ใช่กลยุทธ์ที่ถูกต้อง เนื่องจากประสิทธิภาพที่ไม่ดีมักจะทําให้เกิดปัญหาแอปหรือปัญหาอื่นๆ ได้ง่าย (นั่นคือ ปัญหาการกระตุก) และตัวแปรในระบบทั้งหมดมีจํานวนมากเกินไป ทําให้กลยุทธ์นี้ใช้ไม่ได้ผล ด้วยเหตุนี้ คุณจึงอาจระบุสาเหตุไม่ถูกต้องและทำการปรับปรุงเล็กๆ น้อยๆ ไปโดยไม่ได้มองเห็นโอกาสในการแก้ไขปัญหาประสิทธิภาพของระบบอย่างเป็นระบบ
แต่ให้ใช้แนวทางทั่วไปต่อไปนี้เมื่อเปิดใช้งานอุปกรณ์ใหม่
- บูตระบบไปยัง UI โดยให้ไดรเวอร์ทั้งหมดทำงานอยู่และการตั้งค่าตัวควบคุมความถี่พื้นฐานบางอย่าง (หากคุณเปลี่ยนการตั้งค่าตัวควบคุมความถี่ ให้ทำตามขั้นตอนทั้งหมดด้านล่างซ้ำ)
- ตรวจสอบว่าเคอร์เนลรองรับ
sched_blocked_reasonจุดตรวจจับ รวมถึงจุดตรวจจับอื่นๆ ในไปป์ไลน์การแสดงผลที่ระบุเวลาที่ส่งเฟรมไปยังจอแสดงผล - ทำการติดตามแบบยาวของไปป์ไลน์ UI ทั้งหมด (ตั้งแต่การรับอินพุตผ่าน IRQ ไปจนถึงการสแกนเอาต์สุดท้าย) ขณะทำงานที่มีภาระงานเบาและสม่ำเสมอ (เช่น UiBench หรือการทดสอบลูกบอลใน TouchLatency)
- แก้ไขเฟรมที่ลดลงซึ่งตรวจพบในปริมาณงานที่เบาและสม่ำเสมอ
- ทำขั้นตอนที่ 3-4 ซ้ำจนกว่าคุณจะเล่นได้โดยไม่เฟรมตกเป็นเวลานานกว่า 20 วินาทีต่อการเล่น 1 ครั้ง
- ไปยังแหล่งที่มาอื่นๆ ของอาการกระตุกที่ผู้ใช้มองเห็น
สิ่งง่ายๆ อื่นๆ ที่คุณทําได้ในช่วงเริ่มต้นการเริ่มใช้งานอุปกรณ์ ได้แก่
- ตรวจสอบว่าเคอร์เนลมีแพตช์ sched_blocked_reason tracepoint จุดติดตามนี้เปิดใช้ด้วยหมวดหมู่การติดตามการกําหนดเวลาใน 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 ms หลังจากเหตุการณ์ Xn-1 (สมมติว่าใช้จอแสดงผล 60 Hz) แสดงว่าคุณไม่ได้พบปัญหาการกระตุก หาก SOC ไม่ได้ให้สัญญาณดังกล่าว โปรดติดต่อผู้ให้บริการเพื่อขอสัญญาณ การแก้ไขข้อบกพร่องของภาพกระตุกนั้นทำได้ยากมากหากไม่มีสัญญาณที่ชัดเจนว่าเฟรมเสร็จสมบูรณ์
ใช้การเปรียบเทียบแบบสังเคราะห์
การเปรียบเทียบสังเคราะห์มีประโยชน์ในการยืนยันว่าอุปกรณ์มีฟังก์ชันการทำงานพื้นฐาน อย่างไรก็ตาม การใช้การเปรียบเทียบเป็นพร็อกซีสำหรับประสิทธิภาพที่รับรู้ของอุปกรณ์นั้นไม่มีประโยชน์
จากประสบการณ์การใช้งาน SOC พบว่าความแตกต่างของประสิทธิภาพการทดสอบสังเคราะห์ระหว่าง SOC ต่างๆ ไม่ได้มีความเกี่ยวข้องกับความแตกต่างที่คล้ายกันในประสิทธิภาพ UI ที่สังเกตได้ (จำนวนเฟรมที่หลุด เฟรมเวลา 99 เปอร์เซ็นต์ไทล์ ฯลฯ) การเปรียบเทียบแบบสังเคราะห์เป็นการเปรียบเทียบเฉพาะความจุเท่านั้น โดยความผันผวนจะส่งผลต่อประสิทธิภาพที่วัดได้ของการเปรียบเทียบเหล่านี้โดยการแย่งเวลาจากการดำเนินการแบบเป็นกลุ่มของการเปรียบเทียบเท่านั้น ด้วยเหตุนี้ คะแนนการเปรียบเทียบสังเคราะห์จึงแทบจะไม่เกี่ยวข้องกับเมตริกประสิทธิภาพที่ผู้ใช้รับรู้
พิจารณา SOC 2 ตัวที่ใช้การทดสอบประสิทธิภาพ X ซึ่งแสดงผล UI 1,000 เฟรมและรายงานเวลาในการแสดงผลทั้งหมด (คะแนนที่ต่ำลงดีกว่า)
- SOC 1 แสดงผลเฟรมแต่ละเฟรมของ Benchmark X ใน 10 ms และคะแนน 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 ใกล้เคียงกับ 60FPS มากเท่าใด คุณก็ยิ่งมีโอกาสน้อยที่ระบบจะทำงานผิดพลาดซึ่งทำให้เกิดอาการกระตุกเป็นพักๆ ในแอปขนาดใหญ่ซึ่งยากที่จะจำลองได้
เนื่องจากความผันผวนของสัญญาณมัก (แต่ไม่ใช่เสมอไป) ไม่คงที่ตามความเร็วสัญญาณนาฬิกา ให้ใช้การทดสอบที่ทำงานด้วยความเร็วสัญญาณนาฬิกาต่ำมากเพื่อวินิจฉัยความผันผวนของสัญญาณด้วยเหตุผลต่อไปนี้
- อาการกระตุกไม่ได้ขึ้นอยู่กับความถี่สัญญาณเสมอไป แหล่งที่มาหลายแห่งอาจใช้เพียงเวลาของ CPU
- ตัวควบคุมควรทำให้เวลาเฟรมเฉลี่ยอยู่ใกล้กับกำหนดเวลาโดยลดความเร็วลง ดังนั้นเวลาที่ใช้ทำงานที่ไม่ใช่ UI อาจทำให้เฟรมตก