Tối ưu hoá mức sử dụng pin của ứng dụng bằng chỉ số khoá chế độ thức của Android vitals

Thời lượng pin là một khía cạnh quan trọng trong trải nghiệm người dùng và khoá chế độ thức đóng vai trò quan trọng. Bạn có đang sử dụng quá nhiều không? Trong bài đăng trên blog này, chúng ta sẽ tìm hiểu về khoá chế độ thức, một số phương pháp hay nhất để sử dụng khoá chế độ thức và cách bạn có thể hiểu rõ hơn về hành vi của ứng dụng thông qua chỉ số trên Play Console.

Sử dụng quá nhiều khoá chế độ thức một phần trong Android vitals

Play Console hiện theo dõi mức tiêu hao pin, tập trung vào mức sử dụng khoá chế độ thức một phần quá mức, đây là một chỉ báo hiệu suất chính.

Tính năng này nâng cao tầm quan trọng của hiệu suất pin bên cạnh các chỉ báo ổn định của chỉ số cốt lõi hiện có: sự cố mà người dùng nhận thấy và lỗi ANR quá cao. Chúng tôi đã xác định ngưỡng hành vi xấu đối với tỷ lệ khoá chế độ thức quá mức. Kể từ ngày 1 tháng 3 năm 2026, nếu ứng dụng/trò chơi của bạn không đạt ngưỡng chất lượng này, chúng tôi có thể loại trừ ứng dụng/trò chơi đó khỏi các nền tảng khám phá nổi bật, chẳng hạn như phần đề xuất. Trong một số trường hợp, chúng tôi có thể cho thấy cảnh báo trên trang thông tin của bạn trên Cửa hàng Play để người dùng biết rằng ứng dụng của bạn có thể gây hao pin quá mức.

Cảnh báo về lỗi khoá chế độ thức quá nhiều lần trong Tổng quan về Android vitals.

Đối với thiết bị di động, chỉ số Android vitals áp dụng cho các khoá chế độ thức không được miễn trừ, được thu nạp khi màn hình tắt và ứng dụng đang chạy ở chế độ nền hoặc đang chạy một dịch vụ nền trước. Android vitals coi mức sử dụng khoá chế độ thức một phần là quá mức nếu:

• Khoá chế độ thức được giữ trong ít nhất 2 giờ trong khoảng thời gian 24 giờ.
• Vấn đề này ảnh hưởng đến hơn 5% số phiên của ứng dụng, tính trung bình trong 28 ngày.

Khoá chế độ thức do các API do người dùng khởi tạo như âm thanh, vị trí và JobScheduler tạo ra sẽ được miễn tính vào khoá chế độ thức.

Tìm hiểu về khoá chế độ thức

Khoá chế độ thức là một cơ chế cho phép ứng dụng duy trì hoạt động của CPU trên thiết bị ngay cả khi người dùng không chủ động tương tác với thiết bị. 

Khoá chế độ thức một phần giúp CPU tiếp tục chạy ngay cả khi màn hình tắt, ngăn CPU chuyển sang trạng thái "tạm ngưng" tiêu thụ ít điện năng. Khoá chế độ thức hoàn toàn giúp cả màn hình và CPU luôn hoạt động.

Có 2 phương thức để lấy khoá chế độ thức một phần:

• Ứng dụng thu nạp và giải phóng khoá chế độ thức theo cách thủ công bằng cách sử dụng API PowerManager cho một trường hợp sử dụng cụ thể. Thường thì khoá này được thu nạp cùng với Dịch vụ trên nền trước – một API vòng đời nền tảng dành cho hoạt động mà người dùng có thể nhận thấy.
• Ngoài ra, khoá chế độ thức được một API khác thu nạp và được gán cho ứng dụng do việc sử dụng API đó. Bạn có thể xem thêm thông tin về vấn đề này trong phần các phương pháp hay nhất.

Mặc dù khoá chế độ thức là cần thiết cho các tác vụ như hoàn tất quá trình tải tệp lớn xuống do người dùng bắt đầu, nhưng việc sử dụng quá mức hoặc không đúng cách có thể dẫn đến tình trạng hao pin đáng kể. Chúng tôi đã thấy các trường hợp ứng dụng giữ khoá chế độ thức trong nhiều giờ hoặc không giải phóng khoá đúng cách, dẫn đến việc người dùng phàn nàn về tình trạng hao pin đáng kể ngay cả khi họ không tương tác với ứng dụng.

Các phương pháp hay nhất để sử dụng khoá chế độ thức

Trước khi tìm hiểu cách gỡ lỗi khi sử dụng quá nhiều khoá chế độ thức, hãy đảm bảo bạn đang làm theo các phương pháp hay nhất về khoá chế độ thức. 

Hãy cân nhắc 4 câu hỏi quan trọng sau đây.

1. Bạn đã cân nhắc các lựa chọn thay thế cho khoá chế độ thức chưa?

Trước khi cân nhắc việc lấy khoá chế độ thức một phần theo cách thủ công, hãy làm theo sơ đồ quy trình ra quyết định sau:

Sơ đồ quy trình để quyết định thời điểm cần lấy khoá chế độ thức theo cách thủ công

1. Màn hình có cần luôn bật không?
   • Có: Hãy tham khảo tài liệu Luôn bật màn hình
2. Ứng dụng có đang chạy dịch vụ nền trước không?
   • Không: Bạn không cần phải lấy khoá chế độ thức theo cách thủ công.
3. Việc thiết bị tạm ngưng có gây bất lợi cho trải nghiệm người dùng không?
   • Không: Ví dụ: việc cập nhật thông báo sau khi thiết bị thức dậy không cần khoá chế độ thức.
   • Có: Nếu việc ngăn thiết bị tạm ngưng là rất quan trọng, chẳng hạn như khi đang liên lạc với một thiết bị bên ngoài, hãy tiếp tục.
4. Có API nào giúp thiết bị luôn bật thay cho bạn không?
   • Bạn có thể tham khảo tài liệu Xác định khoá chế độ thức do các API khác tạo để xác định các trường hợp khoá chế độ thức do các API khác tạo, chẳng hạn như LocationManager.
   • Nếu không có API nào, hãy chuyển sang câu hỏi cuối cùng.
5. Nếu đã trả lời tất cả các câu hỏi này và xác định không có giải pháp thay thế nào, bạn nên tiếp tục lấy khoá chế độ thức theo cách thủ công.

2. Bạn có đặt tên chính xác cho khoá chế độ thức không?

Khi lấy khoá chế độ thức theo cách thủ công, việc đặt tên đúng cách là rất quan trọng để gỡ lỗi:

• Bỏ mọi thông tin nhận dạng cá nhân (PII) trong tên, chẳng hạn như địa chỉ email. Nếu phát hiện thấy PII, khoá chế độ thức sẽ được ghi lại dưới dạng _UNKNOWN, gây cản trở quá trình gỡ lỗi.
• Đừng đặt tên cho khoá chế độ thức theo phương thức lập trình bằng cách sử dụng tên lớp hoặc tên phương thức, vì các tên này có thể bị các công cụ như Proguard làm rối mã nguồn. Thay vào đó, hãy dùng một chuỗi được cố định giá trị trong mã.
• Đừng thêm bộ đếm hoặc giá trị nhận dạng riêng biệt vào thẻ khoá chế độ thức. Bạn nên sử dụng cùng một thẻ mỗi khi khoá chế độ thức chạy để cho phép hệ thống tổng hợp mức sử dụng theo tên, giúp dễ dàng phát hiện hành vi bất thường.

3. Khoá chế độ thức đã thu nạp có luôn được giải phóng không?

Nếu bạn đang lấy khoá chế độ thức theo cách thủ công, hãy đảm bảo rằng lệnh huỷ bỏ khoá chế độ thức luôn được thực thi. Nếu không giải phóng khoá chế độ thức, pin có thể bị tiêu hao đáng kể. 

Ví dụ: nếu một ngoại lệ chưa được giải quyết được gửi trong quá trình processingWork(), thì lệnh gọi release() có thể không bao giờ xảy ra. Thay vào đó, bạn có thể sử dụng khối try-finally để đảm bảo khoá chế độ thức được huỷ bỏ, ngay cả khi xảy ra ngoại lệ.

Ngoài ra, bạn có thể thêm thời gian chờ vào khoá chế độ thức để đảm bảo khoá này sẽ giải phóng sau một khoảng thời gian cụ thể, tránh bị giữ vô thời hạn.

fun processingWork() {
    wakeLock.apply {
        try {
            acquire(60 * 10 * 1000) // timeout after 10 minutes
            doTheWork()
        } finally {
            release()
        }
    }
}

4. Bạn có thể giảm tần suất đánh thức không?

Đối với các yêu cầu dữ liệu định kỳ, việc giảm tần suất ứng dụng đánh thức thiết bị là yếu tố then chốt để tối ưu hoá pin. Sau đây là một số ví dụ về cách giảm tần suất đánh thức:

• WorkManager: Tăng khoảng thời gian định kỳ trong PeriodicWorkRequest.
• SensorManager: Tận dụng tính năng phân lô bằng cách chỉ định maxReportLatencyMs khi đăng ký trình nghe.
• Trình cung cấp vị trí kết hợp:
  • Giảm tần suất truy xuất thông tin vị trí bằng cách sử dụng getLastLocation cho vị trí được lưu vào bộ nhớ đệm gần đây nhất.
  • Sử dụng setPriority(PRIORITY_PASSIVE) để có phương thức cập nhật ít tốn pin hơn.
  • Ngoài ra, bạn có thể tận dụng cơ chế phân nhóm vị trí bằng cách đặt khoảng thời gian cập nhật tối thiểu bằng setMinUpdateIntervalMillis.

Bạn có thể xem thêm thông tin chi tiết trong tài liệu về các phương pháp hay nhất cho khoá chế độ thức.

Gỡ lỗi khi sử dụng khoá chế độ thức quá mức

Ngay cả khi có ý định tốt nhất, việc sử dụng khoá chế độ thức quá mức vẫn có thể xảy ra. Nếu ứng dụng của bạn bị gắn cờ trong Play Console, hãy làm theo cách sau để gỡ lỗi:

Xác định ban đầu bằng Play Console

Trang tổng quan về lỗi khoá chế độ thức một phần quá mức của Android vitals cung cấp thông tin chi tiết về tên khoá chế độ thức không được miễn trừ liên quan đến ứng dụng của bạn, cho thấy các phiên và thời lượng bị ảnh hưởng. Xin lưu ý rằng bạn nên sử dụng tài liệu để xác định xem tên khoá chế độ thức là do ứng dụng hay một API khác giữ.

Trang tổng quan về tỷ lệ khoá chế độ thức một phần quá mức của Android vitals được cuộn xuống phần bảng chi tiết để xem các thẻ khoá chế độ thức quá mức.

Gỡ lỗi khoá chế độ thức quá mức do worker/công việc giữ

Bạn có thể xác định khoá chế độ thức do worker giữ bằng tên khoá chế độ thức sau:

*job*/<package_name>/androidx.work.impl.background.systemjob.SystemJobService

Bạn có thể xem danh sách đầy đủ các biến thể của tên khoá chế độ thức do worker giữ trong tài liệu. Để gỡ lỗi các khoá chế độ thức này, bạn có thể dùng Công cụ kiểm tra tác vụ trong nền để gỡ lỗi cục bộ hoặc tận dụng getStopReason để gỡ lỗi trong trường. 

Công cụ kiểm tra tác vụ trong nền của Android Studio

Ảnh chụp màn hình của Công cụ kiểm tra tác vụ trong nền, trong đó công cụ này có thể xác định một trình chạy "WeatherSyncWorker" thường xuyên thử lại và không thành công.

Để gỡ lỗi cục bộ cho các vấn đề về WorkManager, hãy sử dụng công cụ này trên trình mô phỏng hoặc thiết bị thông minh đã kết nối (cấp độ API 26 trở lên). Công cụ này cho thấy danh sách các worker và trạng thái của các worker đó (đã hoàn tất, đang thực thi, đã đưa vào hàng đợi), cho phép bạn kiểm tra thông tin chi tiết và tìm hiểu các chuỗi worker. 

Ví dụ: thông tin này có thể cho biết liệu một worker có thường xuyên không thành công hoặc thử lại do đạt đến giới hạn của hệ thống hay không. 

Hãy xem tài liệu về Công cụ kiểm tra tác vụ trong nền để biết thêm thông tin chi tiết.

WorkManager getStopReason

Để gỡ lỗi tại chỗ cho các trình thực thi có quá nhiều khoá chế độ thức, hãy sử dụng WorkInfo.getStopReason() trên WorkManager 2.9.0 trở lên hoặc đối với JobScheduler, hãy sử dụng JobParameters.getStopReason() có trên SDK 31 trở lên. 

API này giúp ghi lại lý do worker dừng (ví dụ: STOP_REASON_TIMEOUT, STOP_REASON_QUOTA), xác định chính xác các vấn đề như hết thời gian chờ thường xuyên do hết thời gian chạy.

backgroundScope.launch {
    WorkManager.getInstance(context)
        .getWorkInfoByIdFlow(workRequest.id)
        .collect { workInfo ->
            logStopReason(workRequest.id, workInfo?.stopReason)
        }
}

Hãy xem phần Tối ưu hoá mức sử dụng pin cho các API lập lịch biểu tác vụ để biết thêm thông tin chi tiết.

Gỡ lỗi các loại khoá chế độ thức quá mức khác

Đối với các trường hợp phức tạp hơn liên quan đến khoá chế độ thức được giữ theo cách thủ công hoặc API giữ khoá chế độ thức, bạn nên sử dụng tính năng thu thập dấu vết hệ thống để gỡ lỗi.

Thu thập dấu vết hệ thống

Dấu vết hệ thống là một công cụ gỡ lỗi mạnh mẽ, ghi lại chi tiết hoạt động của hệ thống trong một khoảng thời gian, cung cấp thông tin chi tiết về trạng thái CPU, hoạt động của luồng, hoạt động mạng và các chỉ số liên quan đến pin như thời lượng công việc và mức sử dụng khoá chế độ thức.

Bạn có thể ghi lại dấu vết hệ thống bằng một số phương thức: 

• Sử dụng công cụ dòng lệnh truy vết hệ thống
• Sử dụng Trình phân tích CPU của Android Studio
• Sử dụng giao diện người dùng Perfetto
• Ghi lại dấu vết theo cách thủ công trên thiết bị trực tiếp từ Tùy chọn cho nhà phát triển. 

Bật danh mục Atrace "power:PowerManagement" trong giao diện người dùng Perfetto trong thẻ Android apps & svcs (Ứng dụng và dịch vụ Android). 

Bất kể bạn chọn phương pháp nào, điều quan trọng là phải đảm bảo rằng bạn đang thu thập danh mục Atrace "power:PowerManagement" để cho phép xem các bản ghi trạng thái thiết bị. 

Kiểm tra giao diện người dùng Perfetto và phân tích SQL

Bạn có thể mở và kiểm tra dấu vết hệ thống trong giao diện người dùng Perfetto. Khi mở dấu vết, bạn sẽ thấy hình ảnh trực quan của nhiều quy trình trên dòng thời gian. Trong hướng dẫn này, chúng ta sẽ tập trung vào các kênh trong phần "Trạng thái thiết bị".

Ghim các bản nhạc trong phần "Device State" (Trạng thái thiết bị) như "Top app" (Ứng dụng hàng đầu), "Screen state" (Trạng thái màn hình), "Long Wake locks" (Khoá chế độ thức dài) và "Jobs" (Công việc) để xác định trực quan các lát khoá chế độ thức chạy trong thời gian dài.

Mỗi khối liệt kê tên sự kiện, thời điểm bắt đầu và thời điểm kết thúc sự kiện. Trong Perfetto, đây được gọi là một lát cắt.

Để phân tích nhiều dấu vết trên quy mô lớn, bạn có thể sử dụng tính năng phân tích SQL của Perfetto. Một truy vấn SQL có thể tìm thấy tất cả khoá chế độ thức được sắp xếp theo thời lượng, giúp xác định những yếu tố chính gây ra tình trạng sử dụng quá mức.

Dưới đây là một truy vấn mẫu tính tổng tất cả các thẻ khoá chế độ thức đã xảy ra trong dấu vết hệ thống, được sắp xếp theo tổng thời lượng:

SELECT slice.name as name, track.name as track_name,SUM(dur / 100000) as total_dur_ms
FROM slice
JOIN track ON slice.track_id = track.id
WHERE track.name = 'WakeLocks'GROUP BY slice.name, track.name
ORDER BY total_dur_ms DESC

Sử dụng ProfilingManager để thu thập dấu vết tại hiện trường

Đối với các vấn đề khó tái hiện, ProfilingManager (được thêm vào SDK 35) là một API có lập trình cho phép nhà phát triển thu thập dấu vết hệ thống trong trường bằng trình kích hoạt bắt đầu và kết thúc. Công cụ này giúp bạn kiểm soát tốt hơn các điểm kích hoạt bắt đầu và kết thúc cho việc thu thập hồ sơ, đồng thời thực thi giới hạn tốc độ ở cấp hệ thống để tránh ảnh hưởng đến hiệu suất của thiết bị. 

Hãy xem tài liệu về ProfilingManager để biết thêm các bước về cách triển khai tính năng thu thập dấu vết hệ thống tại hiện trường, bao gồm cả cách ghi lại dấu vết, phân tích dữ liệu phân tích tài nguyên và sử dụng lệnh gỡ lỗi cục bộ theo phương thức lập trình.

Dấu vết hệ thống được thu thập bằng ProfilingManager sẽ tương tự như dấu vết được thu thập theo cách thủ công, nhưng các quy trình hệ thống và quy trình ứng dụng khác sẽ được loại bỏ khỏi dấu vết.

Kết luận

Chỉ số khoá chế độ thức một phần quá mức trong Android vitals chỉ là một phần nhỏ trong cam kết không ngừng của chúng tôi nhằm hỗ trợ nhà phát triển giảm mức tiêu hao pin và cải thiện chất lượng ứng dụng. 

Bằng cách hiểu rõ và triển khai đúng cách khoá chế độ thức, bạn có thể tối ưu hoá đáng kể hiệu suất pin của ứng dụng. Việc tận dụng các API thay thế, tuân thủ các phương pháp hay nhất về khoá chế độ thức và sử dụng các công cụ gỡ lỗi mạnh mẽ như Công cụ kiểm tra tác vụ trong nền, dấu vết hệ thống và ProfilingManager là chìa khoá để đảm bảo ứng dụng của bạn thành công trên Google Play.