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

Mức sử dụng khoá chế độ thức một phần quá mức 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 cùng với các chỉ báo hiện có về độ ổn định của chỉ số quan trọng: số lượng sự cố và lỗi ANR quá mức mà người dùng nhận thấy. Chúng tôi đã xác định ngưỡng hành vi xấu đối với tỷ lệ khoá đánh thức quá mức. Kể từ ngày 1 tháng 3 năm 2026, nếu tiêu đề của bạn không đáp ứng ngưỡng chất lượng này, chúng tôi có thể loại trừ tiêu đề đó khỏi các vị trí nổi bật để khám phá nội dung, chẳng hạn như danh sách đề xuất. Trong một số trường hợp, chúng tôi có thể hiển thị cảnh báo trên trang thông tin của bạn trong Cửa hàng Play để người dùng biết rằng ứng dụng của bạn có thể tiêu hao quá nhiều pin.

Cảnh báo về lỗi khoá chế độ thức quá mức trong trang 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 thập trong 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ụ trên 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á đánh 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.

Các khoá chế độ thức do âm thanh, vị trí và JobScheduler API do người dùng khởi tạo được miễn tính vào số lượng 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 tiếp tục chạy CPU của 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 năng lượng. Chế độ khoá chế độ thức hoàn toàn giúp cả màn hình và CPU đều chạy.

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

• Ứng dụng này tự động thu nạp và giải phóng khoá chế độ thức 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, một API khác sẽ thu nhận khoá chế độ thức và được phân bổ cho ứng dụng do việc sử dụng API này. 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 việc cần làm như hoàn tất quá trình tải xuống một tệp lớn 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 tiêu hao pin đáng kể. Chúng tôi nhận thấy có những trường hợp ứng dụng giữ khoá đánh 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 tiêu 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á đánh thức

Trước khi tìm hiểu cách gỡ lỗi tình trạng sử dụng khoá chế độ thức quá mức, hãy đảm bảo rằng bạn đang tuân thủ 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 này.

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

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

Sơ đồ quy trình để quyết định thời điểm thu nạp 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ó: Tham khảo tài liệu Luôn bật màn hình
2. Ứng dụng có đang chạy một dịch vụ trên nền trước không?
   • Không: Bạn không cần phải tự lấy khoá chế độ thức.
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 một thông báo sau khi thiết bị chuyển sang trạng thái hoạt động không yêu cầu 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ư đang giao tiếp với một thiết bị bên ngoài, hãy tiếp tục.
4. Đã có API thay bạn giữ cho thiết bị ở trạng thái hoạt động chưa?
   • Bạn có thể tận dụng tài liệu Xác định khoá đánh thức do các API khác tạo để xác định các trường hợp khoá đánh 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ế, bạn nên tiếp tục thu thập khoá chế độ thức theo cách thủ công.

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

Khi thu thập khoá đánh thức theo cách thủ công, việc đặt tên phù hợp là rất quan trọng đối với việc 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 (Thông tin nhận dạng cá nhân), khoá chế độ thức sẽ được ghi nhật ký dưới dạng _UNKNOWN, gây cản trở quá trình gỡ lỗi.
• Đừng đặt tên 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ì những 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 mã hoá cứng.
• Đừng thêm bộ đếm hoặc giá trị nhận dạng duy nhấ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 bạn dễ dàng phát hiện hành vi bất thường.

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

Nếu bạn đang tự lấy khoá chế độ thức, hãy đảm bảo khoá chế độ thức luôn 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 phát hiện xảy ra 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 giải phóng, ngay cả khi xảy ra một 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ể, ngăn khoá này 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ố chính để 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 xử lý hàng loạt 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 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) cho phương thức cập nhật ít tiêu hao pin hơn.
  • Ngoài ra, bạn có thể tận dụng cơ chế 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 liên quan đến khoá chế độ thức.

Gỡ lỗi tình trạng 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 gỡ lỗi theo cách sau:

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

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

Trang tổng quan Android vitals về lỗi khoá một phần chế độ thức quá mức được cuộn xuống phần thông tin chi tiết để xem các thẻ khoá chế độ thức quá mức.

Gỡ lỗi các khoá đánh thức quá mức do các worker/job nắm giữ

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

*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 nắm giữ trong tài liệu. Để gỡ lỗi các khoá đánh thức này, bạn có thể sử 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 các vấn đề tại hiện 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ông cụ kiểm tra tác vụ trong nền, trong đó công cụ này có thể xác định một worker "WeatherSyncWorker" đã thử lại nhiều lần và không thành công.

Để gỡ lỗi cục bộ các vấn đề về WorkManager, hãy sử dụng công cụ này trên một trình mô phỏng hoặc thiết bị thông minh được 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 chúng (đã hoàn tất, đang thực thi, đã xếp hàng), cho phép bạn kiểm tra thông tin chi tiết và hiểu rõ các chuỗi worker. 

Ví dụ: bạn có thể biết liệu một worker có thường xuyên gặp lỗi 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 trình thực thi tại chỗ khi có quá nhiều khoá đánh 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 nhật ký lý do khiến một worker dừng hoạt độ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 bài viết Tối ưu hoá mức sử dụng pin cho các API lập lịch tác vụ để biết thêm thông tin.

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

Đối với các tình huống phức tạp hơn liên quan đến khoá chế độ thức được giữ theo cách thủ công hoặc cá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 thông tin chi tiết về 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 nhiều phương pháp: 

• Sử dụng công cụ dòng lệnh theo dõi hệ thống
• Sử dụng Trình phân tích CPU trong 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ị ngay trong phần tuỳ 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ẻ Ứng dụng và dịch vụ Android. 

Bất kể bạn chọn phương thức nào, điều quan trọng là bạn phải đảm bảo rằng bạn đang thu thập danh mục "power:PowerManagement" Atrace để có thể xem các dấu vết 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. Các bản theo dõi mà chúng ta sẽ tập trung vào trong hướng dẫn này là các bản theo dõi trong phần "Trạng thái thiết bị".

Ghim các bản theo dõi trong phần "Trạng thái thiết bị", chẳng hạn như các bản theo dõi "Ứng dụng hàng đầu", "Trạng thái màn hình", "Khoá chế độ thức dài" và "Tác vụ" để 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, việc này được gọi là một lát cắt.

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

Sau đây là một truy vấn mẫu tổng hợp tất cả các thẻ khoá chế độ thức xuất hiện 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 những vấn đề khó tái hiện, ProfilingManager (được thêm vào SDK 35) là một API có thể lập trình, cho phép nhà phát triển thu thập dấu vết hệ thống tại hiện trường bằng các trình kích hoạt bắt đầu và kết thúc. Thư viện 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 quá trình thu thập hồ sơ, đồng thời thực thi tính năng giới hạn tốc độ ở cấp hệ thống để ngăn chặn ảnh hưởng đến hiệu suất của thiết bị. 

Hãy xem tài liệu 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 theo phương thức lập trình, phân tích dữ liệu lập hồ sơ và sử dụng các lệnh gỡ lỗi cục bộ.

Các dấu vết hệ thống được thu thập bằng ProfilingManager sẽ tương tự như các 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à các quy trình ứng dụng khác sẽ được chỉnh sửa trong 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 các khoá đánh 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, theo dõi 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.