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

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

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

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

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

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

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

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

ความจุ

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

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

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

เสียงรบกวน

แม้ว่าความจุที่จำเป็นสำหรับเวิร์กโหลดจะดูได้ง่าย แต่จิitter เป็นแนวคิดที่ คลุมเครือกว่า หากต้องการทำความเข้าใจเกี่ยวกับ Jitter ในฐานะอุปสรรคต่อระบบที่รวดเร็ว เราขอแนะนำให้อ่านเอกสารชื่อThe Case of the Missing Supercomputer Performance: Achieving Optimal Performance on the 8,192 processors of ASCI Q (เป็นการตรวจสอบว่าเหตุใดซูเปอร์คอมพิวเตอร์ ASCI Q จึงไม่สามารถบรรลุประสิทธิภาพตามที่คาดไว้ และเป็น การแนะนำการเพิ่มประสิทธิภาพระบบขนาดใหญ่ที่ยอดเยี่ยม)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

เหตุการณ์เหล่านี้จะยังคงเปิดใช้เมื่อคุณเรียกใช้ Systrace เพื่อให้คุณเห็นข้อมูลเพิ่มเติมใน Trace เกี่ยวกับไปป์ไลน์การแสดงผล (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 แสดงผลแต่ละเฟรมของ Benchmark X ใน 10 มิลลิวินาทีและได้คะแนน 10,000
• SOC 2 แสดงผลเฟรม 99% ใน 1 มิลลิวินาที แต่แสดงผลเฟรม 1% ใน 100 มิลลิวินาที และได้คะแนน 19,900 ซึ่งเป็นคะแนนที่ดีขึ้นอย่างมาก

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

ใช้รายงานข้อบกพร่อง

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

ใช้ TouchLatency

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

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

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

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

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