ตรวจสอบคุณภาพทางเทคนิคของแอปด้วย Android Vitals

หากต้องการดูรายละเอียดเพิ่มเติมเกี่ยวกับเมตริก ให้เลือกดูรายละเอียด () ข้างเมตริกที่ต้องการ ในหน้าจอถัดไป คุณจะดูรายการต่อไปนี้ได้

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

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

เมตริกอัตรา ANR มีด้วยกัน 3 รายการ ดังนี้

• อัตรา ANR ที่ผู้ใช้รับรู้: เปอร์เซ็นต์ของผู้ใช้ที่ใช้งานอยู่รายวันที่พบ ANR ที่ผู้ใช้รับรู้อย่างน้อย 1 ครั้ง ANR ที่ผู้ใช้รับรู้คือ ANR ที่ผู้ใช้มีแนวโน้มที่จะสังเกตเห็นได้ ปัจจุบันระบบจะนับเฉพาะ ANR ประเภท "หมดเวลานำส่งอินพุต" เมตริกนี้จะต่ำกว่าอัตรา ANR โดยรวมของคุณอยู่เสมอ เนื่องจากได้รับการทำให้เป็นมาตรฐานตามการใช้งานรายวัน แต่ไม่ได้นับ ANR ทั้งหมด
  อัตรา ANR ที่ผู้ใช้รับรู้เป็น Vitals หลัก ซึ่งหมายความว่าเมตริกนี้ส่งผลกระทบต่อการค้นพบได้ของแอปคุณใน Google Play และมีความสำคัญเนื่องจาก ANR ที่เมตริกนี้นับอาจเกิดขึ้นทุกครั้งที่ผู้ใช้มีส่วนร่วมกับแอป ซึ่งทำให้เกิดการหยุดชะงักมากที่สุด
• อัตรา ANR: เปอร์เซ็นต์ของผู้ใช้รายวันที่พบ ANR อย่างน้อย 1 ครั้ง เมตริกนี้รวม ANR ที่ไม่ได้จัดประเภทเป็น ANR ที่ผู้ใช้รับรู้ไว้ด้วย แต่เราไม่รับประกันว่า ANR เหล่านี้จะไม่ส่งผลกระทบต่อผู้ใช้
• อัตรา ANR หลายครั้ง: เปอร์เซ็นต์ของผู้ใช้รายวันที่พบ ANR อย่างน้อย 2 ครั้ง เมตริกนี้ช่วยเน้นว่าปัญหาเกิดขึ้นซ้ำๆ

แก้ปัญหา

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

เว็บไซต์ของนักพัฒนาแอป Android มีคำแนะนำเกี่ยวกับการวินิจฉัยและแก้ไข ANR

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

เมตริกอัตราการขัดข้องมีด้วยกัน 3 รายการ ดังนี้

• อัตราการขัดข้องที่ผู้ใช้รับรู้: เปอร์เซ็นต์ของผู้ใช้รายวันที่พบการขัดข้องที่ผู้ใช้รับรู้อย่างน้อย 1 ครั้ง การขัดข้องที่ผู้ใช้รับรู้คือการขัดข้องที่ผู้ใช้มีแนวโน้มที่จะสังเกตเห็นได้ ตัวอย่างเช่น การขัดข้องที่เกิดขึ้นเมื่อแอปแสดงกิจกรรมหรือทำหน้าที่เป็นบริการที่ทำงานอยู่เบื้องหน้า เมตริกนี้จะต่ำกว่าอัตราการขัดข้องโดยรวมของคุณอยู่เสมอ เนื่องจากได้รับการทำให้เป็นมาตรฐานตามการใช้งานรายวัน แต่ไม่ได้นับการขัดข้องทั้งหมด
  อัตราการขัดข้องที่ผู้ใช้รับรู้เป็น Vitals หลัก ซึ่งหมายความว่าเมตริกนี้ส่งผลกระทบต่อการค้นพบได้ของแอปคุณใน Google Play และมีความสำคัญเนื่องจากการขัดข้องที่เมตริกนี้นับอาจเกิดขึ้นทุกครั้งที่ผู้ใช้มีส่วนร่วมกับแอป ซึ่งทำให้เกิดการหยุดชะงักมากที่สุด ซึ่งเป็นเหตุผลว่าทำไมคุณจึงต้องดูแลไม่ให้แอปมีเมตริกนี้เกินเกณฑ์ลักษณะการทำงานที่ไม่ถูกต้อง

• อัตราการขัดข้อง: เปอร์เซ็นต์ของผู้ใช้รายวันที่พบการขัดข้องอย่างน้อย 1 ครั้ง เมตริกนี้รวมการขัดข้องที่ไม่ได้จัดประเภทเป็นการขัดข้องที่ผู้ใช้รับรู้ไว้ด้วย แต่เราไม่รับประกันว่าการขัดข้องเหล่านี้จะไม่ส่งผลกระทบต่อผู้ใช้

• อัตราการขัดข้องหลายครั้ง: เปอร์เซ็นต์ของผู้ใช้รายวันที่พบการขัดข้องอย่างน้อย 2 ครั้ง เมตริกนี้ช่วยเน้นว่าปัญหาเกิดขึ้นซ้ำๆ

แก้ปัญหา

เว็บไซต์ของนักพัฒนาแอป Android มีคำแนะนำเกี่ยวกับการวินิจฉัยและแก้ไขข้อขัดข้อง

หน้าเวลาเริ่มต้นมีรายละเอียดเกี่ยวกับเวลาที่แอปค่อยๆ เริ่มทำงานโดยที่ระบบมีสถานะตั้งแต่ Cold, Warm ไปจนถึง Hot เวลาเริ่มต้นจะวัดระยะเวลาที่ใช้ตั้งแต่ตอนผู้ใช้เปิดแอปไปจนถึงตอนที่เฟรมแรกปรากฏขึ้นบนหน้าจอ หรือเรียกอีกอย่างว่า "เวลาที่ใช้ในการแสดงผลครั้งแรก"

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

รายละเอียดการเก็บรวบรวมข้อมูล

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

รายละเอียดสำคัญ

• เซสชันที่ได้รับผลกระทบ: เปอร์เซ็นต์ของเซสชันในช่วงที่ผู้ใช้พบช่วงเวลาเริ่มต้นช้าสำหรับแต่ละสถานะของระบบ ดังนี้
  • Cold Start ช้า: 5 วินาทีขึ้นไป
  • เริ่มต้นอุ่นเครื่องช้า: 2 วินาทีขึ้นไป
  • เริ่มร้อนช้า: 1 วินาทีขึ้นไป
• จำนวนเซสชัน: จำนวนเซสชันที่บันทึกไว้โดยประมาณ
• เปอร์เซ็นไทล์ที่ 90/99: 10%/1% ของเซสชันรายวันที่ผู้ใช้พบเวลาเริ่มต้นของแอปช้าสำหรับแอปของคุณ

แก้ปัญหา

หากแอปมีเวลาเริ่มต้นของแอปช้าจำนวนมาก ให้ไปที่เว็บไซต์ของนักพัฒนาแอป Android เพื่อดูวิธีแก้ปัญหาที่แนะนำ

ทำไมจึงสำคัญ

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

ทำความเข้าใจข้อมูลของแอป

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

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

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

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

Vitals จะเริ่มตรวจสอบอัตราเฟรมหลังจากที่เกมทำงานไปแล้ว 1 นาทีเท่านั้น

รายละเอียดการเก็บรวบรวมข้อมูล

เมตริกเซสชันที่ช้าคำนวณด้วยข้อมูลที่เก็บรวบรวมมาจาก SurfaceFlinger เพื่อให้เห็นภาพมากขึ้นก็คือ อัตราเฟรมของเซสชันเป็นค่าประมาณโดยอิงจากเวลาระหว่างการวาดเฟรมบนแพลตฟอร์มที่แอปเป็นเจ้าของ และมีเฟรมที่แสดงภาพโดย OpenGL, Vulkan ตลอดจนชุดเครื่องมือ Android UI ปัจจุบันเมตริกนี้ใช้ได้กับเกมเท่านั้น

ระบบจะเก็บรวบรวมข้อมูลอัตราเฟรมของเซสชันที่ช้าสำหรับอุปกรณ์ที่ใช้ Android 9 ขึ้นไป

การแสดงผลของแดชบอร์ด

• อัตราเฟรมตัวแทน: ประสิทธิภาพอัตราเฟรมของเกมในอุปกรณ์ที่ใช้ Android 9 ขึ้นไป โดยคำนวณจากเปอร์เซ็นไทล์ที่ 75 ซึ่งหมายความว่า 75% ของเซสชันมีอัตราเฟรมนี้หรือเร็วกว่า 75% ของเวลาดังกล่าว
• อัตราเซสชันที่ช้าตามช่วงเวลา: อนุกรมเวลาที่แสดงเปอร์เซ็นต์ของเซสชันที่ระบุว่าเป็นเซสชันที่ช้า
• การกระจายอัตราเฟรม: ฮิสโตแกรมแสดงอัตราเฟรมเปอร์เซ็นไทล์ที่ 75 ในเซสชันต่างๆ ซึ่งหมายความว่า 75% ของเฟรมในเซสชันแสดงเร็วกว่าอัตราเฟรมที่ใช้เพื่อเก็บข้อมูลเซสชัน

แก้ปัญหา

หากแอปมีเซสชันที่ช้าจำนวนมาก โปรดไปที่เว็บไซต์ของนักพัฒนาแอป Android เพื่อดูวิธีแก้ปัญหาที่แนะนำ

ทำความเข้าใจข้อมูลของแอป

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

รายละเอียดการเก็บรวบรวมข้อมูล

Google เก็บรวบรวมเวลาในการแสดงผลที่แอปแสดงผลแต่ละเฟรม เมื่อใช้เฟรมเวิร์กชุดเครื่องมือ UI โดยจะไม่เก็บรวบรวมเฟรมที่แสดงผลโดยใช้ OpenGL หรือ Vulkan โดยตรง

การแสดงผลของแดชบอร์ด

เมื่อเลือกแถว คุณจะเห็นข้อมูลแบ่งออกเป็นเปอร์เซ็นไทล์

• เซสชันที่ได้รับผลกระทบ: เปอร์เซ็นต์ของเซสชันรายวันที่ผู้ใช้พบปัญหาที่เฟรมมากกว่า 50% มีเวลาในการแสดงผลนานกว่า 16 มิลลิวินาที เซสชันรายวันหมายถึงวันที่มีการใช้แอป เช่น หากผู้ใช้ 2 รายใช้แอปเป็นเวลา 2 วัน ก็จะเกิดเซสชันรายวัน 4 ครั้ง
• จำนวนเซสชัน: จำนวนเซสชันที่บันทึกไว้โดยประมาณ
• เปอร์เซ็นไทล์ที่ 90/99: 90%/99% จากเฟรมทั้งหมดมีเวลาในการแสดงผลต่ำกว่าตัวเลขที่แสดง ตัวเลขเหล่านี้จะอิงจากเฟรมที่เก็บรวบรวมทั้งหมด

เมื่อคุณคลิกรายการในตาราง จะเห็นแผนภูมิ "เวลาในการแสดงผลการกระจาย UI" ระหว่างที่ดูแผนภูมิ ให้ตรวจสอบว่าเฟรมส่วนใหญ่ของแอปเท่ากับหรือต่ำกว่า 16 มิลลิวินาที

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

• Vsync ที่ไม่ได้รับ: จำนวนเหตุการณ์ Vsync ที่ไม่ได้รับ หารด้วยจำนวนเฟรม สำหรับเฟรมทั้งหมดที่แสดงผลนานกว่า 16 มิลลิวินาที
• เวลาในการตอบสนองการป้อนข้อมูลสูง: จำนวนเหตุการณ์การป้อนข้อมูลที่ใช้เวลานานกว่า 24 มิลลิวินาที หารด้วยจำนวนเฟรม สำหรับเฟรมทั้งหมดที่แสดงผลนานกว่า 16 มิลลิวินาที
• เธรด UI ที่ช้า: จำนวนครั้งที่เธรด UI ใช้เวลาดำเนินการให้เสร็จสิ้นนานกว่า 8 มิลลิวินาที หารด้วยจำนวนเฟรม สำหรับเฟรมทั้งหมดที่แสดงผลนานกว่า 16 มิลลิวินาที
• คำสั่งวาดใช้เวลานาน: จำนวนครั้งที่การส่งคำสั่งวาดไปยัง GPU ใช้เวลานานกว่า 12 มิลลิวินาที หารด้วยจำนวนเฟรม สำหรับเฟรมทั้งหมดที่แสดงผลนานกว่า 16 มิลลิวินาที
• การอัปโหลดบิตแมปที่ช้า: จำนวนครั้งที่บิตแมปใช้เวลานานกว่า 3.2 มิลลิวินาทีในการอัปโหลดไปยัง GPU หารด้วยจำนวนเฟรม สำหรับเฟรมทั้งหมดที่แสดงผลนานกว่า 16 มิลลิวินาที

แก้ปัญหา

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

ทำความเข้าใจข้อมูลของแอป

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

รายละเอียดการเก็บรวบรวมข้อมูล

Google เก็บรวบรวมเวลาในการแสดงผลที่แอปแสดงผลแต่ละเฟรม เมื่อใช้เฟรมเวิร์กชุดเครื่องมือ UI โดยจะไม่เก็บรวบรวมเฟรมที่แสดงผลโดยใช้ OpenGL หรือ Vulkan โดยตรง

การแสดงผลของแดชบอร์ด

เมื่อเลือกแถว คุณจะเห็นข้อมูลแบ่งออกเป็นเปอร์เซ็นไทล์

• เซสชันที่ได้รับผลกระทบ: เปอร์เซ็นต์ของเซสชันรายวันที่ผู้ใช้พบปัญหาที่เฟรมมากกว่า 50% มีเวลาในการแสดงผลนานกว่า 16 มิลลิวินาที เซสชันรายวันหมายถึงวันที่มีการใช้แอป เช่น หากผู้ใช้ 2 รายใช้แอปเป็นเวลา 2 วัน ก็จะเกิดเซสชันรายวัน 4 ครั้ง
• จำนวนเซสชัน: จำนวนเซสชันที่บันทึกไว้โดยประมาณ
• เปอร์เซ็นไทล์ที่ 90/99: 90%/99% จากเฟรมทั้งหมดมีเวลาในการแสดงผลต่ำกว่าตัวเลขที่แสดง ตัวเลขเหล่านี้จะอิงจากเฟรมที่เก็บรวบรวมทั้งหมด

เมื่อคุณคลิกรายการในตาราง จะเห็นแผนภูมิ "เวลาในการแสดงผลการกระจาย UI" ระหว่างที่ดูแผนภูมิ ให้ตรวจสอบว่าเฟรมส่วนใหญ่ของแอปเท่ากับหรือต่ำกว่า 16 มิลลิวินาที

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

• Vsync ที่ไม่ได้รับ: จำนวนเหตุการณ์ Vsync ที่ไม่ได้รับ หารด้วยจำนวนเฟรม สำหรับเฟรมทั้งหมดที่แสดงผลนานกว่า 16 มิลลิวินาที
• เวลาในการตอบสนองการป้อนข้อมูลสูง: จำนวนเหตุการณ์การป้อนข้อมูลที่ใช้เวลานานกว่า 24 มิลลิวินาที หารด้วยจำนวนเฟรม สำหรับเฟรมทั้งหมดที่แสดงผลนานกว่า 16 มิลลิวินาที
• เธรด UI ที่ช้า: จำนวนครั้งที่เธรด UI ใช้เวลาดำเนินการให้เสร็จสิ้นนานกว่า 8 มิลลิวินาที หารด้วยจำนวนเฟรม สำหรับเฟรมทั้งหมดที่แสดงผลนานกว่า 16 มิลลิวินาที
• คำสั่งวาดใช้เวลานาน: จำนวนครั้งที่การส่งคำสั่งวาดไปยัง GPU ใช้เวลานานกว่า 12 มิลลิวินาที หารด้วยจำนวนเฟรม สำหรับเฟรมทั้งหมดที่แสดงผลนานกว่า 16 มิลลิวินาที
• การอัปโหลดบิตแมปที่ช้า: จำนวนครั้งที่บิตแมปใช้เวลานานกว่า 3.2 มิลลิวินาทีในการอัปโหลดไปยัง GPU หารด้วยจำนวนเฟรม สำหรับเฟรมทั้งหมดที่แสดงผลนานกว่า 16 มิลลิวินาที

แก้ปัญหา

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

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

รายละเอียดการเก็บรวบรวมข้อมูล

• เพื่อความเป็นส่วนตัว แท็กระบุ Wake Lock บางส่วนจะเป็นแบบไม่ระบุตัวบุคคล
• ระบบจะรวบรวมข้อมูลเกี่ยวกับ Wake Lock บางส่วนเมื่ออุปกรณ์ไม่ได้กำลังชาร์จและหน้าจอปิดอยู่
• ระบบจะรวบรวมข้อมูลเกี่ยวกับ Wake Lock แบบต่อเนื่องบางส่วน (เบื้องหลัง) เมื่อแอปทำงานอยู่เบื้องหลังเท่านั้น
• Google จะคำนวณช่วงเวลา Wake Lock บางส่วนสูงสุดต่อ 1 เซสชันแบตเตอรี่เพื่อแสดงจำนวนเซสชันที่ได้รับผลกระทบจาก Wake Lock ที่ยาวนาน ตัวอย่างเช่น หากผู้ใช้ทริกเกอร์ Wake Lock เป็นเวลา 2 ชั่วโมง Google จะใช้ค่า Wake Lock สูงสุดซึ่งเท่ากับ 1 ชั่วโมง
• สำหรับแอปที่ตั้งค่า sharedUserId ในไฟล์ Manifest จะเห็นข้อมูลเฉพาะในกรณีที่ติดตั้งแอปไม่เกิน 1 รายการซึ่งมี sharedUserId เดียวกัน

รายละเอียดสำคัญ

• เซสชันที่ได้รับผลกระทบ: เปอร์เซ็นต์ของเซสชันแบตเตอรี่ที่ผู้ใช้พบการทำงานขณะล็อกอย่างน้อย 1 ครั้งที่นานกว่า 1 ชั่วโมง
• จำนวนเซสชัน: จำนวนเซสชันที่บันทึกไว้โดยประมาณ
• เปอร์เซ็นไทล์ที่ 90/99: 10%/1% ของเซสชันรายวันที่ผู้ใช้พบช่วง Wake Lock บางส่วนที่นานกว่าตัวเลขที่แสดง
• เกณฑ์ลักษณะการทำงานที่ไม่ถูกต้อง: หากแอปมีอัตราการเกิดขึ้นเท่ากับหรือสูงกว่าเกณฑ์ที่แสดงไว้ หมายความว่าแอปอยู่ในกลุ่ม 25% ล่างสุดของแอปยอดนิยม 1,000 แอปใน Google Play (ตามจำนวนการติดตั้ง)

แก้ปัญหา

หากแอปมี Wake Lock แบบต่อเนื่องบางส่วนจำนวนมาก ให้ไปที่เว็บไซต์ของนักพัฒนาแอป Android เพื่อดูวิธีแก้ปัญหาที่แนะนำ

หน้าการปลุกระบบบ่อยเกินไปจะแสดงการปลุกระบบของ Alarm Manager ซึ่งแอปเรียกใช้ คุณจะเห็นข้อมูลการปลุกระบบของคลาส ELAPSED_REALTIME_WAKEUP หรือ RTC_WAKEUP

รายละเอียดการเก็บรวบรวมข้อมูล

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

รายละเอียดสำคัญ

• เซสชันที่ได้รับผลกระทบ: เปอร์เซ็นต์ของเซสชันแบตเตอรี่ที่ผู้ใช้พบการปลุกระบบมากกว่า 10 ครั้งต่อชั่วโมง เซสชันแบตเตอรี่เป็นการรวมรายงานแบตเตอรี่ทั้งหมดที่ได้รับภายในระยะเวลา 24 ชั่วโมง ใน Android 10 รายงานแบตเตอรี่หมายถึงช่วงเวลาระหว่างการชาร์จแบตเตอรี่ 2 ครั้งจากต่ำกว่า 20% ถึงมากกว่า 80% หรือจากค่าใดก็ตามถึง 100% ใน Android 11 ขึ้นไป รายงานแบตเตอรี่หมายถึงระยะเวลา 24 ชั่วโมงแบบคงที่ Google จะรวบรวมข้อมูลเมื่ออุปกรณ์ไม่ได้กำลังชาร์จเท่านั้น
• จำนวนเซสชัน: จำนวนเซสชันที่บันทึกไว้โดยประมาณ
• เปอร์เซ็นไทล์ที่ 90/99: 10%/1% ของเซสชันรายวันที่ผู้ใช้พบการปลุกระบบต่อชั่วโมงนานกว่าค่าที่แสดง
• เกณฑ์ลักษณะการทำงานที่ไม่ถูกต้อง: หากแอปมีอัตราการเกิดขึ้นเท่ากับหรือสูงกว่าเกณฑ์ที่แสดงไว้ หมายความว่าแอปอยู่ในกลุ่ม 25% ล่างสุดของแอปยอดนิยม 1,000 แอปใน Google Play (ตามจำนวนการติดตั้ง)

แก้ปัญหา

หากแอปของคุณพบการปลุกระบบบ่อยครั้ง ให้ไปที่เว็บไซต์ของนักพัฒนาแอป Android เพื่อดูวิธีแก้ปัญหาที่แนะนำ

หน้าการสแกน Wi-Fi บ่อยเกินไป (พื้นหลัง) จะแสดงเมื่อการสแกน Wi-Fi ทำให้มีการใช้งานแบตเตอรี่สูง

รายละเอียดการเก็บรวบรวมข้อมูล

ข้อมูลเกี่ยวกับการสแกน Wi-Fi จะรวบรวมเมื่ออุปกรณ์ไม่ได้กำลังชาร์จและแอปทำงานอยู่ในเบื้องหลัง

รายละเอียดสำคัญ

• เซสชันที่ได้รับผลกระทบ: เปอร์เซ็นต์ของเซสชันแบตเตอรี่ที่ผู้ใช้พบว่าระบบสแกนหา Wi-Fi มากกว่า 4 ครั้งต่อชั่วโมง
• จำนวนเซสชัน: จำนวนเซสชันที่บันทึกไว้โดยประมาณ
• เปอร์เซ็นไทล์ที่ 90/99: 10%/1% ของเซสชันรายวันที่ผู้ใช้พบการสแกนหา Wi-Fi อยู่เบื้องหลังต่อชั่วโมงบ่อยกว่าตัวเลขที่แสดง

แก้ปัญหา

หากแอปสแกนหา Wi-Fi อยู่ในเบื้องหลังบ่อยครั้ง ให้ไปที่เว็บไซต์ของนักพัฒนาแอป Android เพื่อดูวิธีแก้ปัญหาที่แนะนำ

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

รายละเอียดการเก็บรวบรวมข้อมูล

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

รายละเอียดสำคัญ

• เซสชันที่ได้รับผลกระทบ: เปอร์เซ็นต์ของเซสชันแบตเตอรี่ที่ผู้ใช้พบการใช้เครือข่ายในเบื้องหลังมากกว่า 50 MB ต่อวัน
• จำนวนเซสชัน: จำนวนเซสชันที่บันทึกไว้โดยประมาณ
• เปอร์เซ็นไทล์ที่ 90/99: 10%/1% ของเซสชันรายวันที่ผู้ใช้พบการใช้งานเครือข่ายต่อวันในเบื้องหลังมากกว่าตัวเลขที่แสดง

แก้ปัญหา

หากแอปมีการใช้เครือข่ายอยู่เบื้องหลังเป็นปริมาณมาก ให้ไปที่เว็บไซต์ของนักพัฒนาแอป Android เพื่อดูวิธีแก้ปัญหาที่แนะนำ

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

รายละเอียดการเก็บรวบรวมข้อมูล

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

รายละเอียดสำคัญ

• การปฏิเสธ: เปอร์เซ็นต์ของเซสชันสิทธิ์รายวันซึ่งเป็นระยะเวลาที่ผู้ใช้ปฏิเสธสิทธิ์
• ไม่ต้องถามอีก: เปอร์เซ็นต์ของเซสชันสิทธิ์รายวันที่ผู้ใช้ปฏิเสธการให้สิทธิ์โดยเลือก "ไม่ต้องถามอีก"
• เซสชันทั้งหมด: จำนวนเซสชันที่บันทึกไว้โดยประมาณ

แก้ปัญหา

หากแอปของคุณมีการปฏิเสธสิทธิ์จำนวนมาก ให้ไปที่เว็บไซต์ของนักพัฒนาแอป Android เพื่อดูวิธีแก้ปัญหาที่แนะนำ

Google Play กำหนดเกณฑ์ลักษณะการทำงานที่ไม่ถูกต้องเกี่ยวกับอัตรา ANR ที่ผู้ใช้รับรู้ไว้ดังนี้

• ลักษณะการทำงานที่ไม่ถูกต้องโดยรวม: ผู้ใช้ที่ใช้งานอยู่รายวันอย่างน้อย 0.47% พบ ANR ที่ผู้ใช้รับรู้ในอุปกรณ์ทุกรุ่น

• ลักษณะการทำงานที่ไม่ถูกต้องในแต่ละอุปกรณ์: ผู้ใช้ที่ใช้งานอยู่รายวันอย่างน้อย 8% พบ ANR ที่ผู้ใช้รับรู้ในอุปกรณ์รุ่นใดรุ่นหนึ่ง

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

Android Vitals จะแจ้งให้คุณทราบหากมีแง่มุมที่เจาะจงของฮาร์ดแวร์หรือซอฟต์แวร์ของอุปกรณ์ซึ่งอาจมีส่วนทำให้เกิดอัตรา ANR นอกจากนี้ คุณยังสำรวจความเชื่อมโยงได้ด้วยตนเองในหน้าภาพรวมการเข้าถึงและอุปกรณ์ (ตรวจสอบและปรับปรุง > การเข้าถึงและอุปกรณ์ > ภาพรวม)

Google Play กำหนดเกณฑ์ลักษณะการทำงานที่ไม่ถูกต้องเกี่ยวกับอัตราการขัดข้องที่ผู้ใช้รับรู้ไว้ดังนี้

• ลักษณะการทำงานที่ไม่ถูกต้องโดยรวม: ผู้ใช้ที่ใช้งานอยู่รายวันอย่างน้อย 1.09% พบการขัดข้องที่ผู้ใช้รับรู้ในอุปกรณ์ทุกรุ่น

• ลักษณะการทำงานที่ไม่ถูกต้องในแต่ละอุปกรณ์: ผู้ใช้ที่ใช้งานอยู่รายวันอย่างน้อย 8% พบการขัดข้องที่ผู้ใช้รับรู้ในอุปกรณ์รุ่นใดรุ่นหนึ่ง

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

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