Theo dõi chất lượng kỹ thuật của ứng dụng bằng Android vitals

Để biết thêm chi tiết về một chỉ số, hãy chọn biểu tượng Xem chi tiết () bên cạnh chỉ số đó. Trên màn hình tiếp theo, bạn có thể xem xét:

• Ngưỡng hành vi xấu
• Điểm chuẩn của danh mục
• Thông tin so sánh chi tiết theo điểm chuẩn
  • Ở gần đầu trang, trong thẻ so sánh ứng dụng ngang hàng, hãy chọn Chỉnh sửa nhóm ứng dụng ngang hàng để chỉnh sửa nhóm ứng dụng ngang hàng tuỳ chỉnh. Sau khi tạo một nhóm ứng dụng ngang hàng tuỳ chỉnh, bạn có thể so sánh ứng dụng của mình với các ứng dụng khác trên Google Play mà bạn chọn.
• Xu hướng của chỉ số theo thời gian

Các chỉ số về Tỷ lệ lỗi ANR cho thấy thông tin tổng quan về chất lượng của ứng dụng. Chỉ số này được tính bằng cách lấy số lượng người dùng ứng dụng của bạn gặp phải lỗi ANR rồi chuẩn hoá con số này dựa trên mức sử dụng ứng dụng. Chỉ số này được báo cáo theo tỷ lệ phần trăm số người dùng hoạt động hằng ngày, trong đó người dùng hoạt động hằng ngày được định nghĩa là người dùng sử dụng ứng dụng trên một thiết bị trong một ngày. Nếu một người dùng sử dụng ứng dụng của bạn trên nhiều thiết bị trong một ngày, thì từng thiết bị đó cũng sẽ đóng góp vào số lượng người dùng đang hoạt động trong ngày đó. Nếu nhiều người dùng sử dụng cùng một thiết bị trong một ngày, thì việc này chỉ được tính là một người dùng đang hoạt động.

Có 3 chỉ số về Tỷ lệ lỗi ANR:

• Tỷ lệ lỗi ANR mà người dùng nhận thấy: Tỷ lệ phần trăm người dùng đang hoạt động hằng ngày gặp phải ít nhất 1 lỗi ANR mà người dùng nhận thấy. Lỗi ANR mà người dùng nhận thấy là lỗi ANR có thể người dùng đã chú ý đến. Hiện tại, chỉ có lỗi ANR "hết giờ gửi dữ liệu đầu vào" được tính. Chỉ số này sẽ luôn thấp hơn Tỷ lệ lỗi ANR tổng thể vì được chuẩn hoá theo mức sử dụng hằng ngày, nhưng không tính tất cả lỗi ANR.
  Tỷ lệ lỗi ANR mà người dùng nhận thấy là một chỉ số quan trọng chính, tỷ lệ này ảnh hưởng đến khả năng người dùng thấy được ứng dụng của bạn trên Google Play. Đây là một chỉ số quan trọng vì các lỗi ANR mà chỉ số này tính đến luôn xảy ra khi người dùng tương tác với ứng dụng, do đó gây gián đoạn nhiều nhất.
• Tỷ lệ lỗi ANR: Tỷ lệ phần trăm người dùng hằng ngày gặp phải ít nhất 1 lỗi ANR. Chỉ số này bao gồm những lỗi ANR không được phân loại là lỗi ANR mà người dùng nhận thấy. Tuy nhiên, chúng tôi không thể đảm bảo rằng những lỗi ANR đó không ảnh hưởng đến người dùng.
• Tỷ lệ lỗi ANR nhiều lần: Tỷ lệ phần trăm người dùng đang hoạt động hằng ngày gặp phải ít nhất 2 lỗi ANR. Chỉ số này giúp làm nổi bật vòng lặp vấn đề.

Khắc phục vấn đề

Các lỗi ANR góp phần tạo nên chỉ số Tỷ lệ lỗi ANR được báo cáo trên trang Sự cố và lỗi ANR. Trên trang này, bạn có thể lọc ra các lỗi ANR mà người dùng nhận thấy.

Trang web dành cho nhà phát triển Android có đưa ra hướng dẫn về cách chẩn đoán và khắc phục lỗi ANR.

Chỉ số về tỷ lệ sự cố cho biết thông tin tổng quan về chất lượng của ứng dụng. Chỉ số này được tính bằng cách lấy số lượng người dùng ứng dụng gặp phải sự cố rồi chuẩn hoá con số này dựa trên mức sử dụng ứng dụng. Chỉ số này được báo cáo theo tỷ lệ phần trăm số người dùng hằng ngày, trong đó người dùng hằng ngày được định nghĩa là người dùng sử dụng ứng dụng trên một thiết bị trong một ngày. Nếu một người dùng có nhiều thiết bị, thì người dùng đó sẽ được tính nhiều lần. Ví dụ: nếu 2 người dùng sử dụng ứng dụng trong hai ngày, mỗi người dùng sử dụng 1 thiết bị, thì tổng số phiên hằng ngày là 4.

Có 3 chỉ số tỷ lệ sự cố:

• Tỷ lệ sự cố mà người dùng nhận thấy: Tỷ lệ phần trăm người dùng hằng ngày nhận thấy ít nhất một sự cố. Sự cố mà người dùng nhận thấy là sự cố có thể người dùng đã chú ý đến. Ví dụ: các sự cố xảy ra trong khi ứng dụng của bạn cho thấy một hoạt động hoặc chạy dưới dạng dịch vụ trên nền trước. Chỉ số này sẽ luôn thấp hơn tỷ lệ sự cố tổng thể vì được chuẩn hoá theo mức sử dụng hằng ngày, nhưng không tính tất cả sự cố.
  Tỷ lệ sự cố mà người dùng nhận thấy là một chỉ số rất quan trọng, tỷ lệ này ảnh hưởng đến khả năng người dùng phát hiện được ứng dụng của bạn trên Google Play. Đây là chỉ số quan trọng vì các sự cố mà chỉ số này tính đến luôn xảy ra khi người dùng tương tác với ứng dụng, do đó gây gián đoạn nhiều nhất. Đó là lý do bạn cần đảm bảo ứng dụng của mình không vượt quá ngưỡng hành vi xấu đối với chỉ số này.

• Tỷ lệ sự cố: Tỷ lệ phần trăm người dùng hằng ngày gặp phải ít nhất một sự cố. Chỉ số này bao gồm những sự cố không được phân loại là sự cố mà người dùng nhận thấy. Tuy nhiên, chúng tôi không thể đảm bảo rằng những sự cố đó không ảnh hưởng đến người dùng.

• Tỷ lệ sự cố nhiều lần: Tỷ lệ phần trăm người dùng hằng ngày gặp phải ít nhất 2 sự cố. Chỉ số này giúp làm nổi bật vòng lặp vấn đề.

Khắc phục vấn đề

Trang web dành cho nhà phát triển Android có hướng dẫn về cách chẩn đoán và khắc phục sự cố.

Trên trang Thời gian khởi động, bạn có thể xem thông tin chi tiết về thời điểm ứng dụng của bạn khởi động chậm theo các trạng thái hệ thống nguội, ấm và nóng. Thời gian khởi động được tính từ khi người dùng mở ứng dụng cho đến khi các khung hình đầu tiên xuất hiện trên màn hình. Chỉ số này còn gọi là "thời gian xuất hiện khung hình đầu tiên".

Có thể sau thời điểm này người dùng vẫn chưa bắt đầu tương tác được với ứng dụng, chẳng hạn như trong trường hợp ứng dụng cần tải thêm khung hình khác.

Thông tin chi tiết về hoạt động thu thập dữ liệu

• Thời gian khởi động chỉ được ghi lại khi người dùng kích hoạt một hoạt động.
  • Ví dụ: Đối với các ứng dụng bàn phím, thời gian khởi động bằng thời gian khởi động của ứng dụng đồng hành.
• Nếu ứng dụng khởi động nhiều lần trong cùng một ngày trên cùng một trạng thái hệ thống, thì thời gian khởi động tối đa của ngày đó sẽ được ghi lại.
• Thời gian khởi động bắt đầu được theo dõi khi ứng dụng hoàn thành tải khung hình đầu tiên, ngay cả khi đó không phải là màn hình mà người dùng tương tác.
  • Ví dụ: Nếu ứng dụng khởi động với màn hình chờ, thì thời gian khởi động bằng thời gian cần thiết để hiển thị màn hình chờ.

Các thông tin chi tiết chính yếu

• Phiên bị ảnh hưởng: Tỷ lệ phần trăm số phiên trong đó người dùng gặp phải thời gian khởi động ứng dụng chậm ở từng trạng thái hệ thống tương ứng:
  • Khởi động lạnh chậm: 5 giây trở lên
  • Khởi động ấm chậm: 2 giây trở lên
  • Khởi động nóng chậm: 1 giây trở lên
• Số lượng phiên: Số lượng phiên ước tính ghi nhận được.
• Phân vị thứ 90/99: 10%/1% số phiên hằng ngày trong đó người dùng gặp phải tình trạng ứng dụng khởi động chậm.

Khắc phục vấn đề

Nếu ứng dụng của bạn có nhiều lần khởi động ứng dụng chậm, hãy truy cập trang web dành cho nhà phát triển Android để nắm được các giải pháp được đề xuất.

Tại sao điều này quan trọng

Khi sử dụng phiên bị chậm, bạn có thể hiểu rõ hiệu suất tốc độ khung hình của trò chơi. Hiệu suất này ảnh hưởng đến sự mượt mà và linh hoạt của trò chơi theo cảm nhận của người dùng.

Hiểu rõ dữ liệu của ứng dụng

Trên trang Phiên bị chậm, bạn sẽ thấy thông tin chi tiết về tỷ lệ phần trăm phiên hằng ngày mà người dùng gặp phải hơn 25% số khung hình chậm hơn 30 hoặc 20 khung hình/giây, tuỳ vào điểm chuẩn bạn chọn. Bạn cũng có thể xem dữ liệu phân bổ của các phiên theo tốc độ khung hình của trò chơi. (Tốc độ khung hình ở cấp phiên được đo ở bách phân vị thứ 75, tức là ít nhất 75% số khung hình đạt được tốc độ khung hình này.)

Hầu hết trò chơi trên Google Play nên nhắm đến tốc độ 30 khung hình/giây trở lên. Tốc độ này mang lại trải nghiệm phù hợp cho người dùng, bất kể họ đang chơi loại trò chơi nào (mặc dù một số người dùng sẽ thích ít nhất 60 khung hình/giây, đặc biệt là trên thiết bị cao cấp hơn). Hãy theo dõi chỉ số tỷ lệ phiên bị chậm (30 khung hình/giây) để đảm bảo bạn đạt được ngưỡng này. Xin lưu ý rằng chỉ số này chỉ bao gồm các phiên trong đó có hơn 25% số khung hình không đạt tốc độ 30 khung hình/giây, vì vậy chỉ số này có dung sai về biến động tốc độ khung hình.

Mặc dù tốc độ 30 khung hình/giây mang lại trải nghiệm phù hợp, nhưng có thể có những thời điểm hoặc loại trò chơi cần giảm tốc độ khung hình xuống dưới mức này, hoặc có thể người dùng muốn chơi trò chơi của bạn trên điện thoại không thể hỗ trợ 30 khung hình/giây. Trong các trường hợp như vậy, ít nhất 75% số khung hình trong một phiên vẫn phải đạt được 20 khung hình/giây trở lên. Hãy theo dõi chỉ số tỷ lệ phiên bị chậm (20 khung hình/giây) để đảm bảo bạn đạt được ngưỡng này.

Android vitals báo cáo các phiên bị chậm (30 khung hình/giây) và các phiên bị chậm (20 khung hình/giây) cho từng thiết bị đối với mọi thiết bị và phiên. Hãy sử dụng chỉ số tổng thể để nắm được trải nghiệm tổng thể của người dùng, nhưng cũng nên chú ý đến hiệu suất theo từng thiết bị. Trong lúc đó, Play sẽ bắt đầu chuyển hướng người dùng khỏi những trò chơi không thể đạt được 20 khung hình/giây trên điện thoại của họ.

Vitals chỉ bắt đầu theo dõi tốc độ khung hình sau khi trò chơi của bạn chạy được 1 phút.

Thông tin chi tiết về hoạt động thu thập dữ liệu

Chỉ số phiên bị chậm được tính toán bằng dữ liệu thu thập qua SurfaceFlinger. Cụ thể hơn, tốc độ khung hình của một phiên được ước tính dựa trên thời gian giữa các khung hình được vẽ trên các phần trên giao diện của ứng dụng, trong đó có cả các khung hình do OpenGL, Vulkan, cũng như bộ công cụ giao diện người dùng Android kết xuất. Chỉ số này hiện chỉ áp dụng với trò chơi.

Dữ liệu tốc độ khung hình cho Phiên bị chậm được thu thập trên thiết bị chạy Android 9 trở lên.

Cách thể hiện trên trang tổng quan

• Tốc độ khung hình tiêu biểu: Hiệu suất tốc độ khung hình của trò chơi trên thiết bị chạy Android 9 trở lên, được tính ở bách phân vị thứ 75. Tức là 75% số phiên có tốc độ khung hình này hoặc nhanh hơn trong 75% trường hợp.
• Tỷ lệ phiên bị chậm theo thời gian: Một chuỗi thời gian cho thấy tỷ lệ phần trăm số phiên được xác định là Phiên bị chậm.
• Phân bổ tốc độ khung hình: Biểu đồ thể hiện tốc độ khung hình ở bách phân vị thứ 75 trong các phiên. Tức là 75% số khung hình trong một phiên nhanh hơn tốc độ khung hình dùng để nhóm phiên đó.

Khắc phục vấn đề

Nếu ứng dụng của bạn có nhiều Phiên bị chậm hơn, hãy truy cập trang web dành cho nhà phát triển Android để xem các giải pháp được đề xuất.

Hiểu rõ dữ liệu của ứng dụng

Trên trang Quá nhiều khung hình chậm, bạn sẽ thấy thông tin chi tiết về tỷ lệ phần trăm các phiên hằng ngày trong đó người dùng gặp hơn 50% số khung hình không đáp ứng thời hạn kết xuất của thiết bị. Các hoạt động tương tác của người dùng với ứng dụng của bạn cần diễn ra ở tốc độ 60 khung hình/giây mà không có khung hình nào bị bỏ qua hoặc bị trễ.

Thông tin chi tiết về hoạt động thu thập dữ liệu

Google thu thập thời gian mà ứng dụng của bạn kết xuất mỗi khung hình khi sử dụng khung Bộ công cụ giao diện người dùng. Khung trực tiếp kết xuất bằng OpenGL hoặc Vulkan không được thu thập.

Cách thể hiện trên trang tổng quan

Khi chọn một hàng, bạn sẽ thấy dữ liệu được chia nhỏ thành các phân vị.

• Phiên bị ảnh hưởng: Tỷ lệ phần trăm số phiên hằng ngày mà người dùng gặp phải hơn 50% số khung hình có thời gian kết xuất lớn hơn 16 mili giây. Phiên hằng ngày tức là một ngày mà ứng dụng của bạn được sử dụng. Ví dụ: nếu hai người dùng sử dụng ứng dụng trong hai ngày, thì tổng số phiên hằng ngày là 4.
• Số lượng phiên: Số lượng phiên ước tính ghi nhận được.
• Phân vị thứ 90/99: 90%/99% tổng số khung hình có thời gian kết xuất thấp hơn số hiển thị. Những số liệu này dựa trên tất cả các khung hình thu thập được.

Khi nhấp vào một mục trong bảng, bạn sẽ thấy biểu đồ "Phân phối thời gian hiển thị giao diện người dùng". Khi xem biểu đồ này, bạn cần đảm bảo rằng phần lớn các khung hình của ứng dụng ở mức 16 mili giây hoặc thấp hơn.

Dữ liệu bên dưới biểu đồ cho biết hiệu suất kết xuất của ứng dụng và có thể giúp bạn tìm ra nguyên nhân chính của các vấn đề liên quan tới thời gian kết xuất. Ví dụ như nếu tỷ lệ phần trăm 'Độ trễ đầu vào cao' là cao, bạn có thể cần xem lại mã của ứng dụng dùng để xử lý dữ liệu do người dùng nhập. Để biết thêm thông tin về các chỉ số này, hãy chuyển đến phần thử nghiệm hiệu suất của giao diện người dùng.

• Số lần Vsync bị bỏ lỡ: Số lượng các sự kiện Vsync bị bỏ lỡ chia cho số khung hình, đối với tất cả khung hình có thời gian kết xuất lâu hơn 16 mili giây.
• Độ trễ đầu vào cao: Số sự kiện đầu vào mất hơn 24 mili giây chia cho số khung hình, đối với tất cả khung hình có thời gian kết xuất lâu hơn 16 mili giây.
• Luồng giao diện người dùng chậm: Số lần luồng giao diện người dùng mất hơn 8 mili giây để hoàn tất chia cho số khung hình, đối với tất cả khung hình có thời gian kết xuất lâu hơn 16 mili giây.
• Lệnh vẽ chậm: Số lần gửi lệnh vẽ tới GPU mất hơn 12 mili giây chia cho số khung hình, đối với tất cả khung hình có thời gian kết xuất lâu hơn 16 mili giây.
• Tải bitmap lên chậm: Số lần tải bitmap lên GPU mất hơn 3,2 mili giây chia cho số khung hình, đối với tất cả khung hình có thời gian kết xuất lâu hơn 16 mili giây.

Khắc phục vấn đề

Nếu ứng dụng của bạn có nhiều khung hình hơn với thời gian kết xuất lâu hơn 16 mili giây, hãy truy cập trang web dành cho nhà phát triển Android để xem các giải pháp được đề xuất.

Hiểu rõ dữ liệu của ứng dụng

Trên trang Quá nhiều khung hình chậm, bạn sẽ thấy thông tin chi tiết về tỷ lệ phần trăm các phiên hằng ngày trong đó người dùng gặp hơn 50% số khung hình không đáp ứng thời hạn kết xuất của thiết bị. Các hoạt động tương tác của người dùng với ứng dụng của bạn cần diễn ra ở tốc độ 60 khung hình/giây mà không có khung hình nào bị bỏ qua hoặc bị trễ.

Thông tin chi tiết về hoạt động thu thập dữ liệu

Google thu thập thời gian mà ứng dụng của bạn kết xuất mỗi khung hình khi sử dụng khung Bộ công cụ giao diện người dùng. Khung trực tiếp kết xuất bằng OpenGL hoặc Vulkan không được thu thập.

Cách thể hiện trên trang tổng quan

Khi chọn một hàng, bạn sẽ thấy dữ liệu được chia nhỏ thành các phân vị.

• Phiên bị ảnh hưởng: Tỷ lệ phần trăm số phiên hằng ngày mà người dùng gặp phải hơn 50% số khung hình có thời gian kết xuất lớn hơn 16 mili giây. Phiên hằng ngày tức là một ngày mà ứng dụng của bạn được sử dụng. Ví dụ: nếu hai người dùng sử dụng ứng dụng trong hai ngày, thì tổng số phiên hằng ngày là 4.
• Số lượng phiên: Số lượng phiên ước tính ghi nhận được.
• Phân vị thứ 90/99: 90%/99% tổng số khung hình có thời gian kết xuất thấp hơn số hiển thị. Những số liệu này dựa trên tất cả các khung hình thu thập được.

Khi nhấp vào một mục trong bảng, bạn sẽ thấy biểu đồ "Phân phối thời gian hiển thị giao diện người dùng". Khi xem biểu đồ này, bạn cần đảm bảo rằng phần lớn các khung hình của ứng dụng ở mức 16 mili giây hoặc thấp hơn.

Dữ liệu bên dưới biểu đồ cho biết hiệu suất kết xuất của ứng dụng và có thể giúp bạn tìm ra nguyên nhân chính của các vấn đề liên quan tới thời gian kết xuất. Ví dụ như nếu tỷ lệ phần trăm 'Độ trễ đầu vào cao' là cao, bạn có thể cần xem lại mã của ứng dụng dùng để xử lý dữ liệu do người dùng nhập. Để biết thêm thông tin về các chỉ số này, hãy chuyển đến phần thử nghiệm hiệu suất của giao diện người dùng.

• Số lần Vsync bị bỏ lỡ: Số lượng các sự kiện Vsync bị bỏ lỡ chia cho số khung hình, đối với tất cả khung hình có thời gian kết xuất lâu hơn 16 mili giây.
• Độ trễ đầu vào cao: Số sự kiện đầu vào mất hơn 24 mili giây chia cho số khung hình, đối với tất cả khung hình có thời gian kết xuất lâu hơn 16 mili giây.
• Luồng giao diện người dùng chậm: Số lần luồng giao diện người dùng mất hơn 8 mili giây để hoàn tất chia cho số khung hình, đối với tất cả khung hình có thời gian kết xuất lâu hơn 16 mili giây.
• Lệnh vẽ chậm: Số lần gửi lệnh vẽ tới GPU mất hơn 12 mili giây chia cho số khung hình, đối với tất cả khung hình có thời gian kết xuất lâu hơn 16 mili giây.
• Tải bitmap lên chậm: Số lần tải bitmap lên GPU mất hơn 3,2 mili giây chia cho số khung hình, đối với tất cả khung hình có thời gian kết xuất lâu hơn 16 mili giây.

Khắc phục vấn đề

Nếu ứng dụng của bạn có nhiều khung hình hơn với thời gian kết xuất lâu hơn 16 mili giây, hãy truy cập trang web dành cho nhà phát triển Android để xem các giải pháp được đề xuất.

Các trang Lỗi với khoá chế độ thức một phần và Lỗi với khoá chế độ thức một phần (nền) cho thấy các khoá chế độ thức một phần mà ứng dụng của bạn thu thập thông qua lớp PowerManager. Chế độ khoá chế độ thức một phần giúp đảm bảo CPU vẫn chạy nhưng cho phép tắt màn hình và đèn nền bàn phím.

Thông tin chi tiết về hoạt động thu thập dữ liệu

• Vì mục đích bảo vệ quyền riêng tư, các thẻ nhận dạng khoá chế độ thức một phần được ẩn danh.
• Dữ liệu về khoá chế độ thức một phần được thu thập khi thiết bị đang không sạc pin và màn hình đang tắt.
• Dữ liệu về lỗi với khoá chế độ thức một phần (nền) chỉ được thu thập khi ứng dụng đang chạy ở chế độ nền.
• Google tính toán khoảng thời gian tối đa khoá chế độ thức một phần trên mỗi phiên pin để cho biết có bao nhiêu phiên bị ảnh hưởng bởi khoá chế độ thức lâu. Ví dụ: nếu người dùng kích hoạt khoá chế độ thức trong hai giờ, Google sẽ sử dụng giá trị khoá chế độ thức tối đa là một giờ.
• Đối với các ứng dụng đã đặt sharedUserId trong tệp kê khai: Bạn sẽ chỉ thấy dữ liệu nếu đã cài đặt tối đa một ứng dụng có cùng sharedUserId.

Các thông tin chi tiết chính yếu

• Phiên bị ảnh hưởng: Tỷ lệ phần trăm các phiên pin trong đó người dùng gặp ít nhất 1 lần khoá chế độ thức trong hơn 1 giờ.
• Số lượng phiên: Số lượng phiên ước tính ghi nhận được.
• Phân vị thứ 90/99: 10%/1% số phiên hằng ngày trong đó người dùng gặp phải khoảng thời gian khoá chế độ thức một phần lớn hơn con số hiển thị.
• Ngưỡng hành vi xấu: Nếu ứng dụng của bạn có tỷ lệ xuất hiện hành vi xấu bằng hoặc cao hơn ngưỡng mà bạn thấy thì ứng dụng đó sẽ thuộc nhóm 25% ứng dụng dưới cùng trong số 1.000 ứng dụng hàng đầu trên Google Play (tính theo số lượt cài đặt).

Khắc phục vấn đề

Nếu ứng dụng của bạn có nhiều lượt khoá chế độ thức một phần, hãy truy cập vào trang web nhà phát triển Android để xem các giải pháp được đề xuất.

Trang Đánh thức quá nhiều lần cho thấy những lượt đánh thức qua Alarm Manager mà ứng dụng của bạn đã kích hoạt. Bạn sẽ thấy dữ liệu đánh thức cho các lớp ELAPSED_REALTIME_WAKEUP hoặc RTC_WAKEUP.

Thông tin chi tiết về hoạt động thu thập dữ liệu

• Vì mục đích bảo vệ quyền riêng tư, các thẻ nhận dạng đánh thức được ẩn danh.
• Số lần đánh thức được thu thập khi thiết bị đang không sạc pin.
• Để cung cấp chỉ số chuẩn hoá, số lần đánh thức được so sánh với thời gian thiết bị sử dụng pin. Google tính toán số lần đánh thức/người dùng/giờ để cho biết có bao nhiêu người dùng bị ảnh hưởng bởi tỷ lệ đánh thức cao.
• Đối với các ứng dụng đã đặt sharedUserId trong tệp kê khai: Bạn sẽ chỉ thấy dữ liệu nếu đã cài đặt tối đa một ứng dụng có cùng sharedUserId.

Các thông tin chi tiết chính yếu

• Phiên bị ảnh hưởng: Tỷ lệ phần trăm số phiên pin mà người dùng gặp hơn 10 lần đánh thức mỗi giờ. Phiên pin là tập hợp tất cả báo cáo về pin nhận được trong mỗi khoảng thời gian 24 giờ cụ thể. Trên Android 10, báo cáo về pin được tính trong khoảng thời gian giữa hai lần sạc pin, hoặc là từ khi sạc được dưới 20% đến trên 80% hoặc là từ bất kỳ mức pin nào đến 100%. Trên Android 11 trở lên, báo cáo về pin được tính trong một khoảng thời gian 24 giờ cố định. Google chỉ thu thập dữ liệu khi thiết bị không sạc pin.
• Số lượng phiên: Số lượng phiên ước tính ghi nhận được.
• Phân vị thứ 90/99: 10%/1% số phiên hằng ngày mà người dùng gặp số lần đánh thức mỗi giờ lớn hơn giá trị hiển thị.
• Ngưỡng hành vi xấu: Nếu ứng dụng của bạn có tỷ lệ xuất hiện hành vi xấu bằng hoặc cao hơn ngưỡng mà bạn thấy thì ứng dụng đó sẽ thuộc nhóm 25% ứng dụng dưới cùng trong số 1.000 ứng dụng hàng đầu trên Google Play (tính theo số lượt cài đặt).

Khắc phục vấn đề

Nếu ứng dụng của bạn có số lần đánh thức thường xuyên, hãy truy cập trang web dành cho nhà phát triển Android để xem các giải pháp đề xuất.

Trang Quét tìm Wi-Fi quá mức (nền) hiển thị khi số lần quét tìm Wi-Fi đang dẫn đến mức sử dụng pin cao.

Thông tin chi tiết về hoạt động thu thập dữ liệu

Dữ liệu về quét tìm Wi-Fi được thu thập khi thiết bị đang không sạc và ứng dụng đang chạy trong nền.

Các thông tin chi tiết chính yếu

• Phiên bị ảnh hưởng: Tỷ lệ phần trăm số phiên pin mà người dùng gặp hơn 4 lần quét tìm Wi-Fi mỗi giờ.
• Số lượng phiên: Số lượng phiên ước tính ghi nhận được.
• Bách phân vị thứ 90/99: 10%/1% số phiên hằng ngày trong đó người dùng gặp tình trạng số lần quét tìm Wi-Fi hằng giờ ở chế độ nền lớn hơn con số hiện ra.

Khắc phục vấn đề

Nếu ứng dụng của bạn có nhiều lần quét tìm Wi-Fi ở chế độ nền, hãy truy cập trang web dành cho nhà phát triển Android để biết các giải pháp được đề xuất.

Trang Tỷ lệ sử dụng mạng quá mức xuất hiện khi có một lượng lớn dữ liệu mạng liên quan tới một dịch vụ nền. Khi việc sử dụng mạng di động diễn ra ở chế độ nền, người dùng thường khó tìm ra các nút điều khiển để ngừng hoạt động chuyển dữ liệu.

Thông tin chi tiết về hoạt động thu thập dữ liệu

Dữ liệu về việc sử dụng mạng di động được thu thập khi thiết bị đang không sạc và ứng dụng đang chạy trong nền.

Các thông tin chi tiết chính yếu

• Phiên bị ảnh hưởng: Tỷ lệ phần trăm các phiên pin mà người dùng gặp tình trạng sử dụng hơn 50 MB dung lượng mạng ở chế độ nền mỗi ngày.
• Số lượng phiên: Số lượng phiên ước tính ghi nhận được.
• Bách phân vị thứ 90/99: 10%/1% số phiên hằng ngày trong đó người dùng gặp tình trạng mức sử dụng mạng hằng ngày ở chế độ nền lớn hơn con số hiện ra.

Khắc phục vấn đề

Nếu ứng dụng của bạn có mức sử dụng mạng cao ở chế độ nền, hãy truy cập trang web dành cho nhà phát triển Android để nắm được các giải pháp đề xuất.

Trên trang Từ chối cấp quyền, bạn có thể xem thông tin chi tiết về tỷ lệ phần trăm các phiên yêu cầu cấp quyền hằng ngày mà người dùng đã từ chối cấp quyền. Phiên yêu cầu cấp quyền hằng ngày tức là khoảng thời gian một ngày trong đó ứng dụng của bạn yêu cầu người dùng cấp ít nhất một quyền.

Thông tin chi tiết về hoạt động thu thập dữ liệu

Dữ liệu về các lần từ chối cấp quyền được thu thập khi người dùng phản hồi yêu cầu cấp quyền trong ứng dụng của bạn.

Các thông tin chi tiết chính yếu

• Lượt từ chối: Tỷ lệ phần trăm các phiên yêu cầu cấp quyền hằng ngày mà người dùng đã từ chối cấp quyền.
• Không bao giờ hỏi lại: Tỷ lệ phần trăm các phiên yêu cầu cấp quyền hằng ngày mà người dùng đã từ chối cấp quyền bằng cách chọn Không bao giờ hỏi lại.
• Tổng số phiên: Số lượng phiên ước tính ghi nhận được.

Khắc phục vấn đề

Nếu ứng dụng của bạn có số lượt từ chối cấp quyền ở mức cao, hãy truy cập trang web dành cho Nhà phát triển Android để nắm được các giải pháp được đề xuất.

Google Play đã xác định ngưỡng hành vi xấu đối với Tỷ lệ lỗi ANR mà người dùng nhận thấy:

• Hành vi xấu nói chung: Ít nhất 0,47% số người dùng hoạt động hằng ngày gặp phải lỗi ANR mà người dùng nhận thấy trên mọi kiểu thiết bị.

• Hành vi xấu theo thiết bị: Ít nhất 8% số người dùng hoạt động hằng ngày gặp phải lỗi ANR mà người dùng nhận thấy trên một kiểu thiết bị cụ thể.

Để cải thiện tỷ lệ lỗi ANR, hãy khắc phục các cụm lỗi ANR cơ bản được báo cáo trên trang Sự cố và lỗi ANR. Số người dùng bị ảnh hưởng càng nhiều thì phần đóng góp của cụm lỗi ANR đó vào tỷ lệ lỗi ANR của bạn càng gia tăng.

Nếu một số khía cạnh cụ thể về phần cứng hoặc phần mềm thiết bị có thể là nguyên nhân làm gia tăng tỷ lệ lỗi ANR, thì Android vitals sẽ thông báo cho bạn. Bạn cũng có thể tự tìm hiểu các mối liên kết trên trang Tổng quan về phạm vi tiếp cận và thiết bị (Bản phát hành > Phạm vi tiếp cận và thiết bị > Tổng quan).

Google Play đã xác định ngưỡng hành vi xấu đối với tỷ lệ sự cố mà người dùng nhận thấy:

• Hành vi xấu nói chung: Ít nhất 1,09% số người dùng hằng ngày gặp sự cố mà người dùng nhận thấy trên tất cả mẫu thiết bị.

• Hành vi xấu theo thiết bị: Ít nhất 8% người dùng hằng ngày gặp phải sự cố mà người dùng nhận thấy trên một mẫu thiết bị cụ thể.

Để cải thiện tỷ lệ sự cố, hãy khắc phục những cụm sự cố cơ bản được báo cáo trên trang Sự cố và lỗi ANR. Số người dùng bị ảnh hưởng càng nhiều thì phần đóng góp của cụm sự cố đó vào tỷ lệ sự cố của bạn càng lớn.

Nếu một số khía cạnh cụ thể của phần cứng hoặc phần mềm thiết bị là nguyên nhân làm gia tăng tỷ lệ sự cố, thì Android vitals sẽ thông báo cho bạn. Bạn cũng có thể tự tìm hiểu các mối liên kết trên trang Tổng quan về phạm vi tiếp cận và thiết bị (Bản phát hành > Phạm vi tiếp cận và thiết bị > Tổng quan).