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

ใช้ 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, การรีสตาร์ทบริการ และการแคชหน้าเว็บที่ทำงานหนัก การลดการใช้หน่วยความจําช่วยหลีกเลี่ยงสาเหตุโดยตรงของประสิทธิภาพที่ไม่ดีได้ แต่อาจมีการปรับปรุงอื่นๆ ที่มุ่งเน้นที่หลีกเลี่ยงสาเหตุเหล่านั้นด้วย (เช่น การปักหมุดเฟรมเวิร์กเพื่อป้องกันไม่ให้ระบบย้ายเฟรมเวิร์กออกเมื่อระบบจะย้ายเฟรมเวิร์กกลับเข้ามาในไม่ช้า)

วิเคราะห์ประสิทธิภาพของอุปกรณ์ครั้งแรก

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

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

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

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

  • ตรวจสอบว่าเคอร์เนลมีแพตช์ 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 อาจทำให้เฟรมตก