ข้อมูลเชิงลึกใหม่เกี่ยวกับปัญหาและคำแนะนำด้านคุณภาพแอป
ตอนนี้ระบบจะแสดงปัญหาความเข้ากันได้ของแอป ลักษณะการทำงานที่ไม่ถูกต้อง และคำแนะนำ UX บางอย่าง เราจะตรวจหาและแสดงปัญหาด้านคุณภาพเพิ่มเติม รวมถึงให้คำแนะนำเพิ่มเติมในปีหน้า
ใช้ Android Vitals เพื่อช่วยทำความเข้าใจและปรับปรุงความเสถียร ประสิทธิภาพ การใช้งานแบตเตอรี่ และอื่นๆ ของแอป
เลือกวิธีเข้าถึงข้อมูลของแอป
คุณใช้ Android Vitals ได้ 2 วิธีด้วยกัน ได้แก่ ผ่านทาง Play Console และ Play Developer Reporting API
API ให้สิทธิ์เข้าถึง Android Vitals แบบเป็นโปรแกรมสำหรับนักพัฒนาแอปที่ต้องการผสานรวมข้อมูล Android Vitals เข้ากับชุดข้อมูลอื่นๆ หรือใส่ไว้ในเวิร์กโฟลว์ของตน หากต้องการดูข้อมูลเพิ่มเติมเกี่ยวกับการใช้ API เพื่อเข้าถึง Android Vitals โปรดไปที่หน้า Google Play Developer Reporting API
วิธีดูและตรวจสอบข้อมูล Android Vitals ของแอปใน Play Console
- เปิด Play Console แล้วไปที่หน้าภาพรวมของ Android Vitals (คุณภาพ > Android Vitals > ภาพรวม)
- เลือกช่วงข้อมูลที่ต้องการดูโดยใช้ตัวเลือกช่วงวันที่ที่ด้านขวาบน
สำคัญ: หากไม่มีข้อมูล หมายความว่าแอปมีจุดข้อมูลไม่เพียงพอสำหรับตัวกรองนั้นๆ ในการระบุปัญหาที่เกิดขึ้น
ตรวจสอบ Vitals หลักของแอป
ที่ด้านบนของหน้าภาพรวมของ Android Vitals คุณจะเห็นข้อมูลเกี่ยวกับ Vitals หลักของแอป ซึ่งเป็นเมตริกทางเทคนิคที่สำคัญที่สุดและส่งผลต่อการค้นพบได้ใน Google Play ของแอปคุณ Vitals หลัก ได้แก่
Google Play กำหนดเกณฑ์ลักษณะการทำงานที่ไม่ถูกต้องไว้ในเมตริกเหล่านี้ แอปที่มีเมตริกเหล่านี้เกินเกณฑ์อาจได้รับการค้นพบน้อยลงใน Google Play บางกรณี ระบบอาจแสดงคำเตือนที่ข้อมูลผลิตภัณฑ์ใน Store ของแอปเพื่อให้ผู้ใช้ทราบถึงสิ่งที่อาจพบ
คุณสามารถดูส่วน "ปัญหาร้ายแรง" เพื่อให้ทราบได้อย่างรวดเร็วเกี่ยวกับด้านต่างๆ ที่แอปควรปรับปรุง ปัญหาร้ายแรงมีด้วยกัน 2 ประเภท ได้แก่
- ลักษณะการทำงานที่ไม่ถูกต้อง: เมตริกที่เกินเกณฑ์ลักษณะการทำงานที่ไม่ถูกต้อง
- ความผิดปกติ: การเปลี่ยนแปลงสำคัญในข้อมูล (เช่น อัตรา ANR ที่ผู้ใช้รับรู้ที่เพิ่มขึ้นอย่างรวดเร็ว)
หากต้องการรับการแจ้งเตือนทางอีเมล ให้ไปที่การตั้งค่า > การแจ้งเตือน หรือคลิกจัดการการแจ้งเตือนที่มุมของส่วน "Vitals หลัก" (คุณภาพ > Android Vitals > ภาพรวม) โปรดทราบว่าปัจจุบันระบบจะแจ้งเตือนเกี่ยวกับความผิดปกติเท่านั้น
เรียกดู Vitals ทั้งหมดคุณดูข้อมูลเกี่ยวกับ Vitals ทั้งหมดในแง่ของคุณภาพได้ที่บริเวณตรงกลางหน้าภาพรวมของ Android Vitals
คุณดูเมตริกของระยะเวลาปัจจุบันและก่อนหน้านี้ได้ในตาราง และยังดูประสิทธิภาพของแอปเทียบกับแอปอื่นๆ ใน Google Play ได้ด้วย
หากต้องการดูรายละเอียดเพิ่มเติมเกี่ยวกับเมตริก ให้เลือกดูรายละเอียด () ข้างเมตริกที่ต้องการ ในหน้าจอถัดไป คุณจะดูรายการต่อไปนี้ได้
- เกณฑ์ลักษณะการทำงานที่ไม่ถูกต้อง
- การเปรียบเทียบตามหมวดหมู่
- การเปรียบเทียบเกณฑ์การเปรียบเทียบโดยละเอียด
- ที่บริเวณด้านบนของหน้า ในการ์ดการเปรียบเทียบกับแอปเทียบเท่า ให้เลือกแก้ไขกลุ่มแอปเทียบเท่า เพื่อแก้ไขกลุ่มแอปเทียบเท่าที่กำหนดเอง หลังจากสร้างกลุ่มแอปดังกล่าวแล้ว คุณจะเห็นการเปรียบเทียบระหว่างแอปของคุณกับแอปอื่นๆ ใน Google Play ที่คุณเลือกไว้
- แนวโน้มของเมตริกในช่วงเวลาต่างๆ
เมตริกจะแบ่งออกเป็นมิติข้อมูลต่างๆ เพื่อช่วยคุณจัดระเบียบ จัดกลุ่ม และวิเคราะห์ข้อมูลได้สะดวกขึ้น เมตริกทั้งหมดมีรายละเอียดต่อไปนี้
- อาร์ติแฟกต์: เวอร์ชันของแอปที่เกิดปัญหาขึ้น
- เวอร์ชัน Android (SDK): เวอร์ชันของระบบปฏิบัติการ Android ที่รายงานโดยอุปกรณ์ของผู้ใช้
- รูปแบบของอุปกรณ์: ประเภทอุปกรณ์ที่เรียกใช้แอป (เช่น โทรศัพท์ แท็บเล็ต ทีวี อุปกรณ์ที่สวมใส่ได้)
- รุ่นอุปกรณ์: คำอธิบายระดับสูงของอุปกรณ์ ซึ่งประกอบไปด้วยแบรนด์และตัวระบุอุปกรณ์ที่ไม่ซ้ำกัน เช่น "Google oriole" อุปกรณ์รุ่นหนึ่งอาจมีผลิตภัณฑ์ย่อยซึ่งมีเวอร์ชัน Android, RAM, พื้นที่เก็บข้อมูล หรือระบบวงจรรวมบนชิป (SoC) ที่ต่างกัน
- ประเทศ/ภูมิภาค: ตำแหน่งที่รายงานโดยอุปกรณ์ของผู้ใช้ ณ เวลาที่เกิดปัญหา
เคล็ดลับ: หากต้องการดูรายละเอียดตามแง่มุมที่เจาะจงของฮาร์ดแวร์หรือซอฟต์แวร์อุปกรณ์ (เช่น รุ่นของอุปกรณ์หรือเวอร์ชัน Android) ให้คลิกสัญลักษณ์ () ข้างรายการในตาราง
เมตริกบางรายการมีรายละเอียดเพิ่มเติม ดังนี้
- ชื่อ Wake Lock: แท็กที่ตั้งค่าโดยใช้โปรแกรมเมื่อใช้ Power Manager API ในแอป
- ชื่อการปลุกระบบ: แท็กที่ตั้งค่าโดยใช้โปรแกรมเมื่อใช้ Alarm Manager API ในแอป
- ชื่อกิจกรรมที่เกิด ANR: ชื่อที่สมบูรณ์ในตัวเองของคลาสกิจกรรมที่ ANR เกิดขึ้น (หากมี)
- ประเภท ANR: เวลาที่ ANR เกิดขึ้น (เช่น ขณะที่ให้บริการ) (หากมี)
หากมีรายละเอียดเพิ่มเติม (เช่น คลัสเตอร์ข้อขัดข้องหรือ ANR ที่เกี่ยวข้องกับรายละเอียดดังกล่าว) คุณสามารถดูได้โดยเลือกดูรายละเอียด () ข้างรายการที่ต้องการ
เคล็ดลับ: คุณสลับระหว่างเมตริกต่างๆ ในหมวดหมู่เดียวกันได้โดยใช้ปุ่มสลับที่ด้านบนของหน้าจอ และกรองหน้า
ประเภทข้อมูลและเมตริก
ข้อมูล Android Vitals จะคงอยู่เป็นเวลา 90 วันใน Play Console และ 3 ปีใน Play Developer Reporting API
ข้อมูลรวบรวมมาจากผู้ใช้ที่เลือกจะแชร์ข้อมูลการใช้งานและการวินิจฉัยโดยอัตโนมัติจากอุปกรณ์ Android บางรุ่นและระบบปฏิบัติการบางเวอร์ชัน ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีที่ผู้ใช้ Android เลือกที่จะแชร์ข้อมูลได้ที่ศูนย์ช่วยเหลือของบัญชี
Android Vitals ได้รับการอัปเดตทุกวัน บางครั้งข้อมูลสำหรับอุปกรณ์ที่ใช้ Android 10 ขึ้นไปอาจมาถึงก่อนข้อมูลสำหรับอุปกรณ์ที่เก่ากว่า Android 10 ในกรณีนี้ คุณจะเห็นข้อมูลของ Android 10 ขึ้นไปเฉพาะสำหรับวันที่มีข้อมูล
หมายเหตุ: เมตริก Android Vitals ไม่รวมปัญหาทางเทคนิคที่เกิดขึ้นในรุ่นอุปกรณ์ที่ไม่ได้รับการรับรอง หรือในเวอร์ชันของแอปที่ไม่ได้ติดตั้งผ่าน Google Play
ความเสถียร
เมตริกอัตรา ANRเมตริกอัตรา 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 เพื่อดูวิธีแก้ปัญหาที่แนะนำ
การแสดงภาพ
การแสดงภาพทั้งหมด
อัตราเซสชันที่ช้า (30 FPS หรือ 20 FPS) [เกมเท่านั้น]ทำไมจึงสำคัญ
คุณสามารถใช้ข้อมูลเซสชันที่ช้า เพื่อทำความเข้าใจประสิทธิภาพอัตราเฟรมของเกมซึ่งส่งผลต่อความลื่นไหลของเกมสำหรับผู้ใช้
ทำความเข้าใจข้อมูลของแอป
ในหน้าเซสชันที่ช้า คุณจะเห็นรายละเอียดเกี่ยวกับเปอร์เซ็นต์ของเซสชันรายวันซึ่งผู้ใช้พบปัญหาที่เฟรมมากกว่า 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 เพื่อดูวิธีแก้ปัญหาที่แนะนำ
การแสดงภาพชุดเครื่องมือ Android UI
เฟรมที่ช้ามากเกินไป [แอปเท่านั้น]ทำความเข้าใจข้อมูลของแอป
ในหน้าเฟรมที่ช้ามากเกินไป คุณจะเห็นรายละเอียดเกี่ยวกับเปอร์เซ็นต์ของเซสชันรายวันซึ่งผู้ใช้พบปัญหาที่เฟรมมากกว่า 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 แบบต่อเนื่องบางส่วนและ 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 เพื่อดูวิธีแก้ปัญหาที่แนะนำ
เกณฑ์ลักษณะการทำงานที่ไม่ถูกต้องของ Vitals หลัก
Google Play กำหนดเกณฑ์ลักษณะการทำงานที่ไม่ถูกต้องไว้ใน Vitals หลักของแอปคุณ
หากแอปมีเมตริกเกินเกณฑ์ลักษณะการทำงานที่ไม่ถูกต้อง ก็มีแนวโน้มที่จะค้นพบได้น้อยลงใน Google Play หากแอปมีลักษณะการทำงานที่ไม่ถูกต้องในอุปกรณ์บางรุ่น Google Play จะเลี่ยงไม่ให้ผู้ใช้อุปกรณ์ดังกล่าวพบกับแอปเหล่านี้และนำผู้ใช้ไปยังแอปอื่นๆ ที่เหมาะสมมากกว่า บางกรณีระบบอาจแสดงคำเตือนในข้อมูลผลิตภัณฑ์ใน Store ของแอปคุณเพื่อให้ผู้ใช้ทราบถึงสิ่งที่อาจพบและให้ตัวเลือกในการหาแอปอื่นที่มีคุณภาพทางเทคนิคมากกว่า
โดยทั่วไป Google Play จะคำนวณคุณภาพของแอปโดยพิจารณาจากข้อมูล 28 วันล่าสุด แต่อาจดำเนินการเร็วกว่านั้นหากเกิดช่วงที่มีจำนวนผู้ใช้เพิ่มขึ้น
ความเสถียร
เกณฑ์อัตรา ANR ที่ผู้ใช้รับรู้Google Play กำหนดเกณฑ์ลักษณะการทำงานที่ไม่ถูกต้องเกี่ยวกับอัตรา ANR ที่ผู้ใช้รับรู้ไว้ดังนี้
-
ลักษณะการทำงานที่ไม่ถูกต้องโดยรวม: ผู้ใช้ที่ใช้งานอยู่รายวันอย่างน้อย 0.47% พบ ANR ที่ผู้ใช้รับรู้ในอุปกรณ์ทุกรุ่น
-
ลักษณะการทำงานที่ไม่ถูกต้องในแต่ละอุปกรณ์: ผู้ใช้ที่ใช้งานอยู่รายวันอย่างน้อย 8% พบ ANR ที่ผู้ใช้รับรู้ในอุปกรณ์รุ่นใดรุ่นหนึ่ง
หากต้องการปรับปรุงอัตรา ANR ให้แก้ไขคลัสเตอร์ ANR ที่เกี่ยวข้องซึ่งมีการรายงานไว้ในหน้าข้อขัดข้องและ ANR ยิ่งมีจำนวนผู้ใช้ที่ได้รับผลกระทบมากขึ้น คลัสเตอร์นั้นก็ยิ่งมีส่วนทำให้เกิดอัตรา ANR มากขึ้น
Android Vitals จะแจ้งให้คุณทราบหากมีแง่มุมที่เจาะจงของฮาร์ดแวร์หรือซอฟต์แวร์ของอุปกรณ์ซึ่งอาจมีส่วนทำให้เกิดอัตรา ANR นอกจากนี้ คุณยังสำรวจความเชื่อมโยงได้ด้วยตนเองในหน้าภาพรวมการเข้าถึงและอุปกรณ์ (รุ่น > การเข้าถึงและอุปกรณ์ > ภาพรวม)
Google Play กำหนดเกณฑ์ลักษณะการทำงานที่ไม่ถูกต้องเกี่ยวกับอัตราการขัดข้องที่ผู้ใช้รับรู้ไว้ดังนี้
-
ลักษณะการทำงานที่ไม่ถูกต้องโดยรวม: ผู้ใช้ที่ใช้งานอยู่รายวันอย่างน้อย 1.09% พบการขัดข้องที่ผู้ใช้รับรู้ในอุปกรณ์ทุกรุ่น
-
ลักษณะการทำงานที่ไม่ถูกต้องในแต่ละอุปกรณ์: ผู้ใช้ที่ใช้งานอยู่รายวันอย่างน้อย 8% พบการขัดข้องที่ผู้ใช้รับรู้ในอุปกรณ์รุ่นใดรุ่นหนึ่ง
หากต้องการปรับปรุงอัตราการขัดข้อง ให้แก้ไขคลัสเตอร์ข้อขัดข้องที่เกี่ยวข้องซึ่งมีการรายงานไว้ในหน้าข้อขัดข้องและ ANR ยิ่งมีจำนวนผู้ใช้ที่ได้รับผลกระทบมากขึ้น คลัสเตอร์นั้นก็ยิ่งมีส่วนทำให้เกิดอัตราการขัดข้องมากขึ้น
Android Vitals จะแจ้งให้คุณทราบหากมีแง่มุมที่เจาะจงของฮาร์ดแวร์หรือซอฟต์แวร์ของอุปกรณ์ซึ่งอาจมีส่วนทำให้เกิดอัตราการขัดข้อง นอกจากนี้ คุณยังสำรวจความเชื่อมโยงได้ด้วยตนเองในหน้าภาพรวมการเข้าถึงและอุปกรณ์ (รุ่น > การเข้าถึงและอุปกรณ์ > ภาพรวม)
เนื้อหาที่เกี่ยวข้อง
อ่านแนวทางปฏิบัติแนะนำสำหรับการใช้ Android Vitals เพื่อปรับปรุงประสิทธิภาพและความเสถียรของแอป