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

Hãy dùng Android vitals để nắm được và cải thiện độ ổn định, hiệu suất cũng như mức sử dụng pin của ứng dụng, v.v.

Chọn cách truy cập vào dữ liệu của ứng dụng

Bạn có hai cách để sử dụng Android vitals: thông qua Play Console và API Play Developer Reporting.

API này cấp quyền truy cập có lập trình vào Android vitals dành cho những nhà phát triển muốn tích hợp dữ liệu Android vitals với các tập dữ liệu khác hoặc đưa dữ liệu này vào quy trình làm việc. Nếu bạn muốn tìm hiểu thêm về cách sử dụng API để truy cập vào Android vitals, hãy xem trang của Google Play Developer Reporting API..

Cách tìm và xem lại dữ liệu Android vitals của ứng dụng trong Play Console:

  1. Mở Play Console.
  2. Chọn ứng dụng.
  3. Trên trình đơn bên trái, hãy chọn Chất lượng > Android vitals > Tổng quan.
  4. Chọn phạm vi dữ liệu mà bạn muốn xem bằng cách sử dụng bộ chọn phạm vi ngày ở phía trên bên phải.

Lưu ý quan trọng: Nếu không có sẵn dữ liệu thì ứng dụng của bạn sẽ không có đủ số lượng điểm dữ liệu trong những bộ lọc đã chỉ định để phát hiện vấn đề bất kỳ.

Theo dõi các chỉ số quan trọng chính của ứng dụng

Ở đầu trang Tổng quan, bạn có thể xem dữ liệu về các chỉ số quan trọng chính của ứng dụng. Đây là những chỉ số quan trọng nhất về mặt kỹ thuật và ảnh hưởng đến khả năng người dùng tìm thấy ứng dụng của bạn trên Google Play. Các chỉ số quan trọng chính gồm có:

Google Play xác định ngưỡng hành vi xấu dựa trên những chỉ số này. Nếu vượt quá các ngưỡng này, thì nhiều khả năng ứng dụng của bạn sẽ khó được tìm thấy trên Google Play. Trong một số trường hợp, trang thông tin của ứng dụng của bạn trên Cửa hàng Play còn xuất hiện một cảnh báo để người dùng đặt ra đúng kỳ vọng.

Bạn có thể dùng phần "Vấn đề nghiêm trọng" để nhanh chóng xác định những điểm mà ứng dụng của mình có thể cải thiện. Có hai loại vấn đề nghiêm trọng:

  • Hành vi xấu: Những chỉ số vượt quá ngưỡng hành vi xấu
  • Điểm bất thường: Những thay đổi đáng kể trong dữ liệu (ví dụ: mức tăng mạnh trong tỷ lệ lỗi ANR mà người dùng nhận thấy)

Để nhận thông báo qua email, hãy truy cập phần Thiết lập > Thông báo hoặc nhấp vào Quản lý thông báo ở phía góc của phần "Các chỉ số quan trọng chính" (Chất lượng > Android vitals > Tổng quan). Xin lưu ý rằng hiện tại bạn chỉ xem được thông báo về các điểm bất thường.

Duyệt qua tất cả chỉ số quan trọng

Ở gần giữa trang Tổng quan, bạn có thể xem dữ liệu về tất cả chỉ số quan trọng theo khía cạnh chất lượng.

Trong bảng này, bạn có thể xem xét các chỉ số đối với các khoảng thời gian hiện tại và trước đó. Bạn cũng 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.

Xem các chỉ số chi tiết

Để 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
Phân tích dữ liệu theo phương diện

Để giúp bạn sắp xếp, phân đoạn và phân tích dữ liệu, các chỉ số của bạn được chia nhỏ theo nhiều phương diện. Tất cả chỉ số đều có những bảng chi tiết sau đây:

  • Cấu phần mềm: Phiên bản ứng dụng xảy ra vấn đề
  • Phiên bản Android (SDK): Phiên bản hệ điều hành Android mà thiết bị của người dùng báo cáo
  • Kiểu dáng: Loại thiết bị mà ứng dụng chạy trên đó (ví dụ: điện thoại, máy tính bảng, TV, thiết bị đeo)
  • Kiểu thiết bị: Thông tin mô tả chung về thiết bị, bao gồm tên thương hiệu riêng biệt và mã nhận dạng thiết bị (ví dụ: "Google oriole"). Mỗi kiểu thiết bị có thể có nhiều biến thể với nhiều phiên bản Android, RAM, dung lượng lưu trữ hoặc hệ thống trên chip (SoC).
  • Quốc gia/khu vực: Vị trí nơi thiết bị của người dùng báo cáo tại thời điểm xảy ra vấn đề

Mẹo: Để xem bảng chi tiết theo các khía cạnh cụ thể về phần cứng hoặc phần mềm thiết bị (ví dụ: kiểu thiết bị hoặc phiên bản Android), bạn có thể nhấp vào biểu tượng () bên cạnh một mục trong bảng.

Một vài chỉ số còn có bảng chi tiết bổ sung:

  • Tên khoá chế độ thức: Các thẻ được cài đặt bằng cách lập trình khi sử dụng PowerManager API trong ứng dụng
  • Tên đánh thức: Thẻ được đặt theo lập trình khi sử dụng API AlarmManager trong ứng dụng của bạn
  • Tên hoạt động xảy ra lỗi ANR: Tên đáp ứng điều kiện của loại hoạt động xảy ra lỗi ANR (nếu có)
  • Loại lỗi ANR: Thời điểm xảy ra lỗi ANR (ví dụ: khi thực hiện một dịch vụ) (nếu có)

Bạn có thể xem thông tin chi tiết khác nếu có (ví dụ: nhóm sự cố hoặc lỗi ANR có liên kết với thông tin chi tiết đó) bằng cách chọn Xem chi tiết () bên cạnh mục tương ứng.

Mẹo: Bạn có thể chuyển đổi giữa các chỉ số trong cùng một danh mục bằng cách sử dụng nút bật/tắt ở đầu màn hình để lọc trang.

Loại dữ liệu và chỉ số

Play Console cung cấp dữ liệu Android vitals trong vòng 90 ngày vừa qua (và trong vòng 3 năm nếu qua API Play Developer Reporting).

Dữ liệu được thu thập qua những người dùng lựa chọn tự động chia sẻ dữ liệu sử dụng và chẩn đoán trong một tập hợp thiết bị và phiên bản hệ điều hành Android. Để biết thêm thông tin về cách người dùng Android chọn chia sẻ loại dữ liệu này, hãy truy cập Trung tâm trợ giúp về Tài khoản Google.

Android vitals được cập nhật hằng ngày. Đôi khi, dữ liệu của thiết bị chạy phiên bản Android 10 trở lên có thể đến sớm hơn dữ liệu của thiết bị chạy phiên bản dưới Android 10. Nếu việc này xảy ra, bạn sẽ thấy dữ liệu của Android 10 trở lên cho những ngày chỉ có loại dữ liệu này.

Lưu ý: Các chỉ số của Android vitals không tính đến những vấn đề kỹ thuật xảy ra trên các mẫu thiết bị chưa được chứng nhận hoặc trên các phiên bản ứng dụng không được cài đặt qua Google Play.

Thu gọn tất cả Mở rộng tất cả

Độ ổn định

Các chỉ số về Tỷ lệ lỗi ANR

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ố

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ố.

Thời gian khởi động và tải

Thời gian khởi động (thời gian xuất hiện khung hình đầu tiên)

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, ấmnó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.

Kết xuất

Tất cả kết xuất

Tỷ lệ phiên bị chậm (30 khung hình/giây hoặc 20 khung hình/giây) [chỉ áp dụng với trò chơi]

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.

Kết xuất bằng bộ công cụ Giao diện người dùng Android

Quá nhiều khung hình chậm [chỉ dành cho ứng dụng]

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.

Khung hình bị treo quá nhiều [chỉ dành cho ứng dụng]

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.

Mức sử dụng pin

Lỗi với khoá chế độ thức và lỗi với khoá chế độ thức một phần (ở chế độ nền)

Các trang Lỗi với khoá chế độ thức một phầnLỗ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.

Đánh thức quá nhiều lần

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.

Quét tìm Wi-Fi quá nhiều lần (ở chế độ nền)

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.

Sử dụng mạng quá mức (ở chế độ nền)

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.

Quyền

Từ chối cấp quyền

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.

Ngưỡng hành vi xấu cho các chỉ số quan trọng chính

Google Play đã định nghĩa ngưỡng hành vi xấu trên các chỉ số quan trọng chính của ứng dụng.

Nếu ứng dụng của bạn vượt quá ngưỡng hành vi xấu thì nhiều khả năng người dùng khó tìm thấy ứng dụng đó trên Google Play. Nếu ứng dụng có hành vi xấu trên một số kiểu thiết bị cụ thể, Google Play sẽ hướng người dùng trên những thiết bị đó ra khỏi những ứng dụng như vậy và cho thấy những ứng dụng khác phù hợp hơn. Trong một số trường hợp, trang thông tin của ứng dụng của bạn trên Cửa hàng Play còn cho thấy một cảnh báo để người dùng đặt ra đúng kỳ vọng, đồng thời đưa ra lựa chọn tìm kiếm ứng dụng thay thế có chất lượng kỹ thuật cao hơn.

Thường thì Google Play sẽ xem xét dữ liệu của 28 ngày gần nhất khi đánh giá chất lượng ứng dụng, nhưng cũng có thể thực hiện việc này sớm hơn nếu có mức tăng đột biến.

Thu gọn tất cả Mở rộng tất cả

Độ ổn định

Ngưỡng tỷ lệ lỗi ANR mà người dùng nhận thấy

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).

Ngưỡng tỷ lệ sự cố mà người dùng nhận thấy

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).

Nội dung liên quan

Khám phá các phương pháp hay nhất để sử dụng tính năng Android vitals nhằm cải thiện hiệu suất và độ ổn định của ứng dụng.

Thông tin này có hữu ích không?

Chúng tôi có thể cải thiện trang này bằng cách nào?

Bạn cần trợ giúp thêm?

Hãy thử các bước tiếp theo sau:

true
Tìm kiếm
Xóa nội dung tìm kiếm
Đóng tìm kiếm
Các ứng dụng của Google
Trình đơn chính