ภาพรวมการวัดประสิทธิภาพแอป

เอกสารนี้จะช่วยคุณระบุและแก้ไขปัญหาด้านประสิทธิภาพที่สําคัญในแอป

ปัญหาด้านประสิทธิภาพที่สำคัญ

ปัญหาที่ทําให้ประสิทธิภาพของแอปแย่ลงมีมากมาย แต่ปัญหาที่พบได้ทั่วไปซึ่งควรตรวจสอบในแอปมีดังนี้

เวลาในการตอบสนองของช่วงเริ่มต้น

เวลาในการตอบสนองเมื่อเริ่มต้นคือระยะเวลาที่ใช้ในการแตะไอคอนแอป การแจ้งเตือน หรือจุดแรกเข้าอื่นๆ และเวลาที่ข้อมูลของผู้ใช้แสดงบนหน้าจอ

มุ่งสู่เป้าหมายต่อไปนี้สำหรับสตาร์ทอัพในแอป

• Cold Start น้อยกว่า 500 มิลลิวินาที Cold Start เกิดขึ้นเมื่อแอปที่เปิดอยู่ไม่ได้อยู่ในหน่วยความจําของระบบ เหตุการณ์นี้เกิดขึ้นเมื่อแอปเปิดขึ้นเป็นครั้งแรกนับตั้งแต่รีบูตหรือตั้งแต่ผู้ใช้หรือระบบหยุดกระบวนการของแอป

  ในทางตรงกันข้าม การเริ่มต้นแบบอุ่นจะเกิดขึ้นเมื่อแอปทำงานอยู่ในเบื้องหลังอยู่แล้ว Cold Start ต้องใช้การทำงานของระบบมากที่สุด เนื่องจากต้องโหลดทุกอย่างจากพื้นที่เก็บข้อมูลและเริ่มต้นแอป โปรดพยายามทำให้ Cold Start ใช้เวลาไม่เกิน 500 มิลลิวินาที

• เวลาในการตอบสนอง P95 และ P99 ใกล้เคียงกับเวลาในการตอบสนองตามค่ามัธยฐานมาก เมื่อแอปใช้เวลานานในการเริ่มต้น ผู้ใช้จะได้รับประสบการณ์การใช้งานที่ไม่ดี การสื่อสารระหว่างกระบวนการ (IPC) และ I/O ที่ไม่จำเป็นในระหว่างเส้นทางที่สำคัญของการเริ่มต้นแอปอาจทำให้เกิดการแข่งขันกันล็อกและทำให้เกิดความไม่สอดคล้อง

การเลื่อนที่กระตุก

การกระตุกเป็นคำที่อธิบายถึงภาพกระตุกที่เกิดขึ้นเมื่อระบบสร้างและแสดงเฟรมไม่ทันเวลาที่จะวาดเฟรมเหล่านั้นบนหน้าจอตามความถี่ที่ขอซึ่งคือ 60 Hz ขึ้นไป อาการกระตุกจะปรากฏชัดที่สุดเมื่อเลื่อนหน้าเว็บ เมื่อมีการสะดุดแทนที่จะมีภาพเคลื่อนไหวที่ราบรื่น อาการกระตุกจะปรากฏขึ้นเมื่อการเคลื่อนไหวหยุดชั่วคราวระหว่างทางอย่างน้อย 1 เฟรม เนื่องจากแอปใช้เวลาในการแสดงผลเนื้อหานานกว่าระยะเวลาของเฟรมในระบบ

แอปต้องกำหนดเป้าหมายเป็นอัตราการรีเฟรช 90Hz อัตราการแสดงผลแบบดั้งเดิมคือ 60Hz แต่อุปกรณ์รุ่นใหม่ๆ จำนวนมากจะทำงานในโหมด 90Hz ในระหว่างที่ผู้ใช้โต้ตอบ เช่น เลื่อน อุปกรณ์บางรุ่นรองรับอัตราการรีเฟรชที่สูงขึ้นถึง 120 Hz

หากต้องการดูอัตราการรีเฟรชที่อุปกรณ์ใช้ ณ เวลาหนึ่ง ให้เปิดใช้การวางซ้อนโดยใช้ตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์ > แสดงอัตราการรีเฟรชในส่วนการแก้ไขข้อบกพร่อง

ทรานซิชันที่ไม่ราบรื่น

ซึ่งจะเห็นได้ชัดในระหว่างการโต้ตอบ เช่น การสลับระหว่างแท็บหรือโหลดกิจกรรมใหม่ ทรานซิชันประเภทนี้ต้องเป็นภาพเคลื่อนไหวที่ราบรื่นและไม่มีภาพกะพริบหรือเกิดความล่าช้า

การใช้พลังงานอย่างไม่มีประสิทธิภาพ

การทำงานจะลดระดับแบตเตอรี่ และการทำงานที่ไม่จำเป็นจะลดอายุการใช้งานแบตเตอรี่

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

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

ระบุปัญหา

เราขอแนะนําเวิร์กโฟลว์ต่อไปนี้เพื่อระบุและแก้ไขปัญหาด้านประสิทธิภาพ

1. ระบุและตรวจสอบเส้นทางของผู้ใช้ที่สําคัญต่อไปนี้
   • ขั้นตอนการเริ่มต้นที่พบบ่อย ซึ่งรวมถึงจากตัวเปิดแอปและการแจ้งเตือน
   • หน้าจอที่ผู้ใช้เลื่อนดูข้อมูล
   • การเปลี่ยนระหว่างหน้าจอ
   • ขั้นตอนการทํางานที่ทำงานต่อเนื่องเป็นเวลานาน เช่น การนําทางหรือการเล่นเพลง
2. ตรวจสอบสิ่งที่เกิดขึ้นระหว่างขั้นตอนก่อนหน้าโดยใช้เครื่องมือแก้ไขข้อบกพร่องต่อไปนี้
   • Perfetto: ช่วยให้คุณเห็นสิ่งที่เกิดขึ้นในอุปกรณ์ทั้งเครื่องพร้อมข้อมูลการจับเวลาอย่างแม่นยำ
   • เครื่องมือวิเคราะห์หน่วยความจำ: ช่วยให้คุณเห็นการจัดสรรหน่วยความจำที่เกิดขึ้นในฮีพ
   • Simpleperf: แสดง Flamegraph ของการเรียกใช้ฟังก์ชันที่ใช้ CPU มากที่สุดในช่วงระยะเวลาหนึ่ง เมื่อคุณพบสิ่งที่ใช้เวลานานใน Systrace แต่ไม่ทราบสาเหตุ Simpleperf จะแสดงข้อมูลเพิ่มเติมได้

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

• ขั้นตอนการเริ่มต้นใช้งาน
  • เมตริกภาคสนาม: เวลาเริ่มต้นของ Play Console
  • การทดสอบในห้องทดลอง: ทดสอบการเริ่มต้นด้วย Macrobenchmark
• Jank
  • เมตริกฟิลด์
    • Play Console Frame Vitals: ใน Play Console คุณจะจํากัดเมตริกให้แคบลงเป็นเส้นทางของผู้ใช้ที่เฉพาะเจาะจงไม่ได้ โดยจะรายงานเฉพาะความกระตุกโดยรวมทั่วทั้งแอป
    • การวัดผลที่กําหนดเองด้วย FrameMetricsAggregator: คุณสามารถใช้ FrameMetricsAggregator เพื่อบันทึกเมตริกการกระตุกในระหว่างเวิร์กโฟลว์หนึ่งๆ ได้
  • การทดสอบในห้องทดลอง
    • การเลื่อนด้วย Macrobenchmark
    • การเปรียบเทียบแบบมาโครจะรวบรวมการกําหนดเวลาเฟรมโดยใช้dumpsys gfxinfoคําสั่ง ที่กําหนดเส้นทางของผู้ใช้เส้นทางเดียว วิธีนี้เป็นวิธีทำความเข้าใจความผันผวนของอาการกระตุกในเส้นทางของผู้ใช้ที่เฉพาะเจาะจง เมตริก RenderTime ซึ่งไฮไลต์ระยะเวลาที่เฟรมใช้ในการวาดภาพมีความสำคัญมากกว่าจํานวนเฟรมที่กระตุกในการระบุการถดถอยหรือการปรับปรุง

ปัญหาเกี่ยวกับการยืนยัน App Link

App Link คือ Deep Link ตาม URL ของเว็บไซต์ที่ได้รับการยืนยันแล้วว่าเป็นของเว็บไซต์ของคุณ ต่อไปนี้คือสาเหตุที่อาจทําให้การตรวจสอบ App Link ไม่สําเร็จ

• ขอบเขตตัวกรอง Intent: เพิ่ม autoVerify เฉพาะในตัวกรอง Intent สำหรับ URL ที่แอปของคุณตอบสนองได้
• การเปลี่ยนโปรโตคอลที่ไม่ได้รับการยืนยัน: การเปลี่ยนเส้นทางฝั่งเซิร์ฟเวอร์และการเปลี่ยนเส้นทางย่อยที่ไม่ได้รับการยืนยันจะถือว่ามีความเสี่ยงด้านความปลอดภัยและยืนยันไม่สําเร็จ ซึ่งจะทำให้ลิงก์ autoVerify ทั้งหมดใช้งานไม่ได้ ตัวอย่างเช่น การเปลี่ยนเส้นทางลิงก์จาก HTTP เป็น HTTPS เช่น example.com เป็น www.example.com โดยไม่ยืนยันลิงก์ HTTPS อาจทําให้การยืนยันไม่สําเร็จ อย่าลืมยืนยัน App Link โดยเพิ่มตัวกรอง Intent
• ลิงก์ที่ยืนยันไม่ได้: การเพิ่มลิงก์ที่ยืนยันไม่ได้เพื่อวัตถุประสงค์ในการทดสอบอาจทําให้ระบบไม่ยืนยัน App Link สําหรับแอปของคุณ
• เซิร์ฟเวอร์ไม่น่าเชื่อถือ: ตรวจสอบว่าเซิร์ฟเวอร์เชื่อมต่อกับแอปไคลเอ็นต์ได้

ตั้งค่าแอปสําหรับการวิเคราะห์ประสิทธิภาพ

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

จุดติดตาม

แอปสามารถเครื่องมือวัดโค้ดด้วยเหตุการณ์การติดตามที่กําหนดเอง

ขณะบันทึกการติดตาม การติดตามจะทำให้เกิดค่าใช้จ่ายเพิ่มเติมเล็กน้อยประมาณ 5μs ต่อส่วน ดังนั้นอย่าใส่การติดตามไว้รอบๆ ทุกเมธอด การติดตามการทํางานขนาดใหญ่กว่า 0.1 มิลลิวินาทีจะให้ข้อมูลเชิงลึกที่สําคัญเกี่ยวกับจุดคอขวด

ข้อควรพิจารณาเกี่ยวกับ APK

ข้อควรระวัง: อย่าวัดประสิทธิภาพในบิลด์แก้ไขข้อบกพร่อง

ตัวแปรการแก้ไขข้อบกพร่องอาจช่วยแก้ปัญหาและแสดงสัญลักษณ์ตัวอย่างสแต็กได้ แต่ส่งผลเสียต่อประสิทธิภาพอย่างมาก อุปกรณ์ที่ใช้ Android 10 (API ระดับ 29) ขึ้นไปสามารถใช้ profileable android:shell="true" ในไฟล์ Manifest เพื่อเปิดใช้การโปรไฟล์ในบิลด์รุ่นที่ใช้งานจริงได้

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

การรวบรวม

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

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

ทั้ง speed และ speed-profile จะลดจํานวนโค้ดที่ทํางานซึ่งตีความจาก dex และจํานวนการคอมไพล์แบบทันท่วงที (JIT) ในเบื้องหลัง ซึ่งอาจทําให้เกิดการรบกวนอย่างมาก มีเพียง speed-profile เท่านั้นที่ลดผลกระทบของการโหลดคลาสรันไทม์จาก dex

คำสั่งต่อไปนี้จะคอมไพล์แอปพลิเคชันโดยใช้โหมด speed

adb shell cmd package compile -m speed -f com.example.packagename

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

/data/misc/profiles/ref/[package-name]/primary.prof

ข้อควรพิจารณาเกี่ยวกับระบบ

ปรับเทียบอุปกรณ์สำหรับการวัดระดับต่ำและความเที่ยงตรงสูง ทำการเปรียบเทียบ A/B ในอุปกรณ์เครื่องเดียวกันและเวอร์ชันระบบปฏิบัติการเดียวกัน ประสิทธิภาพอาจแตกต่างกันอย่างมาก แม้ในอุปกรณ์ประเภทเดียวกัน

ในอุปกรณ์ที่รูท ให้ลองใช้สคริปต์ lockClocks สำหรับ Microbenchmark สคริปต์เหล่านี้จะทําสิ่งต่อไปนี้ด้วย

• ตั้งค่า CPU ให้เป็นความถี่คงที่
• ปิดใช้แกนประมวลผลขนาดเล็กและกำหนดค่า GPU
• ปิดใช้การควบคุมอุณหภูมิ

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

หากเป็นไปได้ ให้พิจารณาใช้เฟรมเวิร์กการทดสอบ เช่น Macrobenchmark ซึ่งจะช่วยลดสัญญาณรบกวนในการวัดผลและป้องกันความคลาดเคลื่อนในการวัด

การเริ่มต้นแอปช้า: กิจกรรมแทรมโพลีนที่ไม่จำเป็น

กิจกรรม Trampoline อาจทำให้เวลาเริ่มต้นของแอปนานขึ้นโดยไม่จำเป็น และคุณควรตรวจสอบว่าแอปของคุณมีกิจกรรมดังกล่าวหรือไม่ ดังที่แสดงในตัวอย่างการติดตามต่อไปนี้ activityStart 1 ตัวตามหลังด้วย activityStart อีกตัวโดยทันที โดยไม่มีเฟรมใดๆ ที่วาดโดยกิจกรรมแรก

รูปที่ 1 ร่องรอยที่แสดงกิจกรรมแทรมโพลีน

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

หมายเหตุ: แอปที่กำหนดเป้าหมายเป็น Android 12 ขึ้นไปจะไม่สามารถเริ่มกิจกรรมจากบริการหรือ Broadcast Receiver ที่ใช้เป็นตัวกระตุ้นให้เข้าสู่กิจกรรมได้ เพื่อปรับปรุงประสิทธิภาพของแอปและ UX

การจัดสรรที่ไม่จำเป็นซึ่งทริกเกอร์ GC บ่อยครั้ง

คุณอาจเห็นว่าการเก็บขยะ (GC) เกิดขึ้นบ่อยกว่าที่คาดไว้ใน Systrace

ในตัวอย่างต่อไปนี้ ทุกๆ 10 วินาทีระหว่างการดำเนินการที่ทำงานเป็นเวลานานคือตัวบ่งชี้ว่าแอปอาจจัดสรรทรัพยากรโดยไม่จำเป็นแต่สม่ำเสมอเมื่อเวลาผ่านไป

รูปที่ 2 ร่องรอยที่แสดงพื้นที่ว่างระหว่างเหตุการณ์ GC

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

เฟรมที่กระตุก

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

เมื่อมีการวาดเฟรมโดยที่แอปต้องทํางานเพียงเล็กน้อย Choreographer.doFrame()จุดติดตามจะปรากฏขึ้นทุก 16.7 มิลลิวินาทีในอุปกรณ์ 60 FPS ดังนี้

รูปที่ 3 ร่องรอยที่แสดงเฟรมที่เร็วบ่อยครั้ง

หากซูมออกและไปยังส่วนต่างๆ ของการติดตาม คุณอาจเห็นว่าเฟรมใช้เวลานานขึ้นเล็กน้อยในการประมวลผล แต่นี่ไม่ใช่ปัญหาเนื่องจากเฟรมใช้เวลาไม่เกิน 16.7 มิลลิวินาทีที่กำหนดไว้

รูปที่ 4 ร่องรอยที่แสดงเฟรมที่เร็วบ่อยครั้งพร้อมกับการทํางานเป็นช่วงๆ

เมื่อเห็นการหยุดชะงักของจังหวะปกตินี้ แสดงว่าเฟรมกระตุก ดังที่แสดงในรูปที่ 5

รูปที่ 5 การติดตามที่แสดงเฟรมที่กระตุก

คุณฝึกระบุสิ่งเหล่านี้ได้

รูปที่ 6 การติดตามที่แสดงเฟรมที่กระตุกมากขึ้น

ในบางกรณี คุณจะต้องซูมเข้าที่จุดติดตามเพื่อดูข้อมูลเพิ่มเติมเกี่ยวกับยอดดูที่เพิ่มขึ้นหรือสิ่งที่ RecyclerView กำลังทํา ในกรณีอื่นๆ คุณอาจต้องตรวจสอบเพิ่มเติม

ดูข้อมูลเพิ่มเติมเกี่ยวกับการระบุเฟรมที่กระตุกและการแก้ไขข้อบกพร่องของสาเหตุได้ที่การแสดงผลช้า

ข้อผิดพลาดที่พบบ่อยเกี่ยวกับ RecyclerView

การทำให้ข้อมูลสำรองทั้งหมดของ RecyclerView ไม่ถูกต้องโดยไม่จำเป็นอาจส่งผลให้เฟรมแสดงผลช้าและกระตุก แต่ให้ลบล้างเฉพาะข้อมูลที่เปลี่ยนแปลงเพื่อลดจํานวนมุมมองที่ต้องอัปเดต

ดูวิธีหลีกเลี่ยงnotifyDatasetChanged()การเรียกใช้ที่เสียค่าใช้จ่ายสูง ซึ่งทําให้เนื้อหาอัปเดตแทนที่จะแทนที่เนื้อหาทั้งหมดได้ที่แสดงข้อมูลแบบไดนามิก

หากคุณไม่รองรับ RecyclerView ที่ฝังอยู่ทุกรายการอย่างถูกต้อง อาจทําให้ระบบสร้าง RecyclerView ภายในขึ้นมาใหม่ทั้งหมดทุกครั้ง RecyclerView ภายในที่ฝังอยู่ทุกรายการต้องมี RecycledViewPool ที่ตั้งค่าไว้เพื่อช่วยในการรีไซเคิลมุมมองระหว่าง RecyclerView ภายในทุกรายการ

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

แก้ไขข้อบกพร่องของแอป

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

แก้ไขข้อบกพร่องการเริ่มต้นแอปด้วย Systrace

ดูภาพรวมของกระบวนการเริ่มต้นของแอปได้ที่เวลาเริ่มต้นของแอป และดูภาพรวมของการติดตามระบบได้ที่วิดีโอต่อไปนี้

คุณระบุประเภทเริ่มต้นให้ชัดเจนได้ในขั้นตอนต่อไปนี้

• การเริ่มต้นแบบ Cold Start: เริ่มสร้างกระบวนการใหม่โดยไม่มีสถานะที่บันทึกไว้
• การเริ่มต้นแบบอุ่น: สร้างกิจกรรมอีกครั้งขณะใช้กระบวนการซ้ำ หรือสร้างกระบวนการอีกครั้งด้วยสถานะที่บันทึกไว้
• การเริ่มต้นแบบ Hot: รีสตาร์ทกิจกรรมและเริ่มที่ช่วงขยาย

เราขอแนะนำให้บันทึก Systraces ด้วยแอปการติดตามระบบในอุปกรณ์ สำหรับ Android 10 ขึ้นไป ให้ใช้ Perfetto สำหรับ Android 9 หรือต่ำกว่า ให้ใช้ Systrace นอกจากนี้ เราขอแนะนำให้ดูไฟล์การติดตามด้วยเครื่องมือดูการติดตาม Perfetto บนเว็บ ดูข้อมูลเพิ่มเติมได้ที่ภาพรวมของการติดตามระบบ

สิ่งที่ควรพิจารณามีดังนี้

• การแย่งชิงทรัพยากรของเครื่องมือตรวจสอบ: การแย่งชิงทรัพยากรที่ได้รับการปกป้องโดยเครื่องมือตรวจสอบอาจทําให้เกิดความล่าช้าอย่างมากในการเริ่มต้นแอป

• ธุรกรรม Binder แบบซิงค์: มองหาธุรกรรมที่ไม่จำเป็นในเส้นทางที่สำคัญของแอป หากการทำธุรกรรมที่จำเป็นมีค่าใช้จ่ายสูง ให้ลองทำงานร่วมกับทีมแพลตฟอร์มที่เกี่ยวข้องเพื่อทำการปรับปรุง

  เคล็ดลับ: คุณสามารถใช้ am trace-ipc start เพื่อดูข้อมูลเพิ่มเติมเกี่ยวกับการโทรเหล่านี้ได้ ปิดใช้ก่อนทำการทดสอบประสิทธิภาพต่อ เนื่องจากมีค่าใช้จ่ายเพิ่มเติมมากและจะยังคงอยู่จนกว่าอุปกรณ์จะรีสตาร์ท

• GC พร้อมกัน: ปัญหานี้เกิดขึ้นได้ทั่วไปและส่งผลกระทบไม่มากนัก แต่หากคุณพบปัญหานี้บ่อยครั้ง ให้ลองตรวจสอบด้วยเครื่องมือวิเคราะห์หน่วยความจำของ Android Studio

• I/O: ตรวจสอบ I/O ที่ดำเนินการระหว่างการเริ่มต้น และมองหาการหยุดทำงานเป็นเวลานาน

• กิจกรรมที่สำคัญในชุดข้อความอื่นๆ: กิจกรรมเหล่านี้อาจรบกวนชุดข้อความ UI ดังนั้นโปรดระวังงานเบื้องหลังระหว่างการเริ่มต้น

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

ใช้การติดตามระบบในอุปกรณ์

คุณสามารถใช้แอประดับระบบที่เรียกว่าการติดตามระบบเพื่อบันทึกการติดตามระบบในอุปกรณ์ แอปนี้ช่วยให้คุณบันทึกร่องรอยจากอุปกรณ์ได้โดยไม่ต้องเสียบปลั๊กหรือเชื่อมต่อกับ adb

ใช้เครื่องมือสร้างโปรไฟล์หน่วยความจำของ Android Studio

คุณสามารถใช้ Android Studio Memory Profiler เพื่อตรวจสอบการกดดันหน่วยความจำที่อาจเกิดจากหน่วยความจำรั่วหรือรูปแบบการใช้งานที่ไม่ถูกต้อง ซึ่งแสดงภาพรวมแบบเรียลไทม์ของการจัดสรรออบเจ็กต์

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

หากต้องการโปรไฟล์หน่วยความจําของแอป ให้ทําตามขั้นตอนต่อไปนี้

1. ตรวจหาปัญหาเกี่ยวกับหน่วยความจำ

   บันทึกเซสชันการโปรไฟล์หน่วยความจําของเส้นทางของผู้ใช้ที่คุณต้องการมุ่งเน้น มองหาจํานวนออบเจ็กต์ที่เพิ่มขึ้น ดังที่แสดงในรูปที่ 7 ซึ่งท้ายที่สุดแล้วจะนำไปสู่ GC ดังที่แสดงในรูปที่ 8

   รูปที่ 7 การเพิ่มจำนวนออบเจ็กต์

   รูปที่ 8 การเก็บขยะ

   หลังจากระบุเส้นทางของผู้ใช้ที่เพิ่มภาระของหน่วยความจําแล้ว ให้วิเคราะห์หาสาเหตุของภาระของหน่วยความจํา

2. วินิจฉัยจุดที่หน่วยความจํามีการใช้งานมาก

   เลือกช่วงในไทม์ไลน์เพื่อแสดงภาพทั้งการจัดสรรและขนาดแบบตื้น ดังที่แสดงในรูปที่ 9

   รูปที่ 9 ค่าสำหรับ Allocations และ Shallow Size

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

   • จัดเรียงตามคลาส: มีประโยชน์เมื่อคุณต้องการค้นหาคลาสที่กำลังสร้างออบเจ็กต์ซึ่งระบบแคชไว้หรือนำกลับมาใช้จากพูลหน่วยความจำ

     ตัวอย่างเช่น หากคุณเห็นแอปสร้างออบเจ็กต์คลาส "Vertex" 2,000 รายการต่อวินาที ระบบจะเพิ่มจํานวนการจัดสรร 2,000 รายการต่อวินาที และคุณจะเห็นเมื่อจัดเรียงตามคลาส หากต้องการนําออบเจ็กต์เหล่านี้กลับมาใช้ใหม่เพื่อหลีกเลี่ยงการสร้างขยะ ให้ใช้พูลหน่วยความจํา

   • จัดเรียงตามกองคําสั่ง: มีประโยชน์เมื่อคุณต้องการค้นหาเส้นทางที่มีการใช้งานบ่อยซึ่งมีการจองหน่วยความจํา เช่น ภายในลูปหรือภายในฟังก์ชันที่เฉพาะเจาะจงซึ่งทํางานการจัดสรรจํานวนมาก

   • ขนาดแบบตื้น: ติดตามเฉพาะหน่วยความจําของออบเจ็กต์นั้นๆ ซึ่งมีประโยชน์สำหรับการติดตามคลาสง่ายๆ ที่ประกอบด้วยค่าพื้นฐานส่วนใหญ่เท่านั้น

   • ขนาดที่เก็บไว้: แสดงหน่วยความจําทั้งหมดเนื่องจากออบเจ็กต์และการอ้างอิงที่ออบเจ็กต์อ้างอิงเพียงอย่างเดียว ซึ่งมีประโยชน์ในการติดตามการกดดันหน่วยความจําเนื่องจากออบเจ็กต์ที่ซับซ้อน หากต้องการทราบค่านี้ ให้ทำ Dump หน่วยความจำทั้งหมดดังที่แสดงในรูปที่ 10 และเพิ่มขนาดที่เก็บไว้เป็นคอลัมน์ดังที่แสดงในรูปที่ 11

     รูปที่ 10 ดัมพ์หน่วยความจำทั้งหมด

     

     รูปที่ 11 คอลัมน์ขนาดที่คงไว้

3. วัดผลกระทบของการเพิ่มประสิทธิภาพ

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

   หากต้องการวัดผลกระทบของการเพิ่มประสิทธิภาพ ให้วัดเวลาระหว่าง GC ในไทม์ไลน์ของเครื่องมือวิเคราะห์โปรไฟล์ จากนั้นคุณจะเห็นระยะเวลาระหว่าง GC นานขึ้น

   ผลกระทบสุดท้ายของการปรับปรุงหน่วยความจํามีดังนี้

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