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á chế độ 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 trên blog này, chúng ta sẽ khám phá khoá chế độ thức là gì, một số phương pháp hay nhất để sử dụng chúng và cách bạn có thể hiểu rõ hơn về hành vi của ứng dụng bằng chỉ số 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 việc sử dụng quá nhiều khoá chế độ thức một phần, đây là một chỉ số 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ỉ số ổn định của chỉ số quan trọng hiện có: quá nhiều sự cố và sự cố ANR mà người dùng cảm nhận được. Chúng tôi đã xác định ngưỡng hành vi xấu đối với việc sử dụng quá nhiều khoá chế độ thức. Kể từ ngày 1 tháng 3 năm 2026, nếu tựa game 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ừ tựa game đó khỏi các nền tảng khám phá nổi bật như đề 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 ứng dụng của bạn trên Cửa hàng Play để cho người dùng biết rằng ứng dụng của bạn có thể gây tiêu hao pin quá mức.

Cảnh báo về việc sử dụng quá nhiều khoá chế độ thức trong trang tổng quan 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 khi màn hình tắt và ứng dụng ở chế độ nền hoặc đang chạy một dịch vụ trên nền trước. Android vitals coi việ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ờ.
• Việc 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 API do người dùng khởi tạo cho âm thanh, vị trí và JobScheduler tạo ra được miễn trừ khỏi tính toán 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 giữ cho CPU của thiết bị chạy ngay cả khi người dùng không tương tác tích cực với thiết bị. 

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

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

• Ứng dụng thu thập và phát hành khoá chế độ thức theo cách thủ công bằng API PowerManager cho một trường hợp sử dụng cụ thể. Thông thường, khoá này được thu thậ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 thu thập bởi một API khác và được phân bổ cho ứng dụng do việc sử dụng API. Bạn có thể tìm hiểu thêm 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 xuống một tệp lớn do người dùng khởi tạo, nhưng việc sử dụng quá nhiều 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 đã thấy các trường hợp ứng dụng giữ khoá chế độ thức trong nhiều giờ hoặc không phát hành đú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á chế độ thức

Trước khi xem xét cách gỡ lỗi việc sử dụng quá nhiều khoá chế độ thức, hãy đảm bảo bạn đang tuân 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.

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 thu thập khoá chế độ thức một phần theo cách thủ công, hãy làm theo biểu đồ quyết định sau:

Lưu đồ quyết định thời điểm thu thập khoá chế độ thức theo cách thủ công

1. Màn hình có cần bật không?
   • Có: Thay vào đó, hãy tham khảo tài liệu Giữ màn hình bật
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 thu thập khoá chế độ thức theo cách thủ công.
3. Trải nghiệm người dùng có bị ảnh hưởng nếu thiết bị tạm 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 yêu cầu khoá chế độ thức.
   • Có: Nếu việc ngăn thiết bị tạm dừng là rất quan trọng, chẳng hạn như việc liên lạc liên tụ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 thức thay cho bạn chưa?
   • Bạn có thể tận dụng tài liệu Xác định khoá chế độ thức do các API khác tạo để xác định các tình huống mà khoá chế độ thức do các API khác tạo ra, 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 rằng không có lựa chọn thay thế nào, 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 cho khoá chế độ thức đúng cách không?

Khi thu thập 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:

• Không đưa bất kỳ Thông tin nhận dạng cá nhân (PII) nào vào 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 là _UNKNOWN, gây cản trở việc gỡ lỗi.
• Đừng đặt tên cho khoá chế độ thức theo phương thức lập trình bằng tên lớp hoặc 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 sử 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 dễ dàng phát hiện hành vi bất thường.

3. Khoá chế độ thức thu thập được có luôn được phát hành không?

Nếu bạn đang thu thập khoá chế độ thức theo cách thủ công, hãy đảm bảo rằng quá trình phát hành khoá chế độ thức luôn được thực thi. Việc không phát hành khoá chế độ thức có thể gây tiêu hao pin đáng kể. 

Ví dụ: nếu một ngoại lệ không được phát hiện được đưa 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 phát hành, 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 phát hành sau một khoảng thời gian cụ thể, ngăn không cho 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à chìa khoá để tối ưu hoá pin. Dưới đâ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 PeriodicWorkRequests.
• 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ế xử lý hàng loạt 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 về khoá chế độ thức.

Gỡ lỗi việc sử dụng quá nhiều khoá chế độ thức

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

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

Trang tổng quan về việc sử dụng quá nhiều khoá chế độ thức một phần 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 kết với ứng dụng của bạn, cho biết các 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 do ứng dụng giữ hay do một API khác giữ.

Trang tổng quan về việc sử dụng quá nhiều khoá chế độ thức một phần của Android vitals đã 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 việc sử dụng quá nhiều khoá chế độ thức do trình chạy/công việc giữ

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

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

Danh sách đầy đủ các biến thể của tên khoá chế độ thức do trình chạy giữ có trong tài liệu. Để gỡ lỗi các khoá chế độ 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 đề trong thực tế. 

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, nơi công cụ này có thể xác định một trình chạy "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 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 hiển thị danh sách các trình chạy 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 trình chạy. 

Ví dụ: công cụ này có thể cho biết liệu một trình chạy 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. 

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 trong thực tế các trình chạy 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, JobParameters.getStopReason() có trên SDK 31 trở lên. 

API này giúp ghi lại lý do khiến một trình chạy dừng (ví dụ: STOP_REASON_TIMEOUT, STOP_REASON_QUOTA), xác định các vấn đề như 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)
        }
}

Xem bài viết 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 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 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 của 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ể thu thập dấu vết hệ thống bằng nhiều phương thức: 

• Sử dụng công cụ dòng lệnh dấu 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ừ các lựa chọn dành cho nhà phát triển. 

Bật danh mục "power:PowerManagement" Atrace 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à phải đảm bảo rằng bạn đang thu thập "power:PowerManagement" danh mục Atrace để cho phép 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 một dòng thời gian. Các dấu vết mà chúng ta sẽ tập trung vào trong hướng dẫn này là các dấu vết trong phần "Trạng thái thiết bị".

Ghim các dấu vết trong phần "Trạng thái thiết bị" như dấu vết "Ứng dụng hàng đầu", "Trạng thái màn hình", "Khoá chế độ thức dài" và "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 của sự kiện, thời điểm sự kiện bắt đầu và thời điểm sự kiện kết thúc. Trong Perfetto, đây được gọi là một lát.

Để phân tích nhiều dấu vết có thể mở rộng, bạn có thể sử dụng tính năng phân tích SQL của Perfetto. Truy vấn SQL có thể tìm thấy tất cả cá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ố đóng góp hàng đầu vào việc sử dụng quá mức.

Dưới đây là một truy vấn ví dụ tổng hợp 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 trong thực tế

Đối với các vấn đề khó tái tạo, ProfilingManager (được thêm vào SDK 35) là một API theo phương thức lập trình cho phép nhà phát triển thu thập dấu vết hệ thống trong thực tế bằng các trình kích hoạt bắt đầu và kết thúc. API này cung cấp khả năng kiểm soát tốt hơn đối với các điểm kích hoạt bắt đầu và kết thúc để 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 tác độ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 trong thực tế, bao gồm cách thu thập 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ộ.

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à các quy trình ứng dụng khác sẽ bị xoá 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 liên tục 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.