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

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

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

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

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

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

ความจุกับ Jitter

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

ความจุ

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

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

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

เสียงรบกวน

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

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

แหล่งที่มาของความแปรปรวนที่พบในการใช้งานจริงของ Android รวมข้อมูลต่อไปนี้

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

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

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

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

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

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

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

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

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

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

  • ตรวจสอบว่าเคอร์เนลมี เหตุผลที่ทำให้ถูกบล็อก แพตช์การย้ายข้อมูล การติดตามจุดนี้เปิดใช้งานด้วยหมวดหมู่การติดตามแบบกำหนด Systrace และให้ฟังก์ชันที่ทำหน้าที่ในการนอนหลับเมื่อนั้น ชุดข้อความเข้าสู่โหมดสลีปอย่างไม่ขาดตอน เป็นสิ่งสำคัญสำหรับการวิเคราะห์ประสิทธิภาพ เพราะการนอนหลับที่ต่อเนื่องเป็นสัญญาณของ Jitter ที่พบได้บ่อยมาก
  • ตรวจสอบว่าคุณมีการติดตามที่เพียงพอสำหรับไปป์ไลน์ 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 ในมุมมอง Sytrace มาตรฐาน แต่ผลลัพธ์ที่ได้ ปรากฏอยู่ในการติดตาม (โปรดดูรายละเอียดที่หัวข้อ การทำความเข้าใจ systrace)

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

ใช้การเปรียบเทียบสังเคราะห์

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

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

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

  • SOC 1 แสดงผล X เปรียบเทียบแต่ละเฟรมโดยใช้เวลา 10 มิลลิวินาทีและคะแนน 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 มากขึ้นเท่าไร โอกาสที่ระบบของคุณจะเสียไปจะน้อยลง ที่ก่อให้เกิดข้อบกพร่องเป็นระยะๆ และทำซ้ำได้ยากในขนาดที่ใหญ่ขึ้น แอป

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

  • ความแปรปรวนของเวลาตอบสนองความต้องการในบางกรณีไม่คงที่ แหล่งที่มาหลายๆ แหล่งนั้น ใช้ CPU
  • ผู้ว่าการรัฐควรได้เวลาเฉลี่ยเฟรมที่ใกล้กับกำหนดเวลาภายใน มีการจำกัดเวลา ดังนั้น เวลาที่ใช้ในการทำงานที่ไม่ใช่ UI อาจรบกวนเวลา การวางเฟรมลง