Tối ưu hoá 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 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ố trên Play Console.

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 việc sử dụng khoá chế độ thức một phần quá mức, đâ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 chính hiện có: quá nhiều sự cố và 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 tỷ lệ khoá chế độ thức quá mức. Kể từ ngày 1 tháng 3 năm 2026, nếu tựa đề 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 đề đó 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 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ề tỷ lệ khoá chế độ thức quá mứ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ờ.
• Chỉ số 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 API do người dùng khởi tạo cho âm thanh, vị trí và JobScheduler tạo ra sẽ được miễn trừ khỏi phép tính 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 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 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 tiếp tục chạy.

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

• Ứng dụng tự thu thập và phát hành khoá chế độ thức bằng API PowerManager cho một trường hợp sử dụng cụ thể. Thường thì 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ể cảm nhận được.
• 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ể 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 do người dùng khởi tạo, 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 đã 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 cách gỡ lỗi tình trạng sử dụng khoá chế độ thức quá mức, hãy đảm bảo 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 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 sơ đồ quyết định sau:

Sơ đồ 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. Việc thiết bị tạm dừng có gây ảnh hưởng đến 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 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ư giao tiếp liên tục với thiết bị bên ngoài), hãy tiếp tục.
4. Đã có API nào thay bạn giữ cho thiết bị hoạt động 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 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 bạn đã 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, 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ó đang đặ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:

• 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 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ì 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 trong giá trị mã.
• Đừ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 để hệ thống có thể 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ó 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ệ chưa được xử lý sẽ đượ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 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 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 đánh thức thiết bị của ứng dụng là chìa khoá để tối ưu hoá pin. Sau đây là một số ví dụ về việc 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 tình trạng sử dụng khoá chế độ thức quá mức

Ngay cả khi có ý định tốt nhất, tình trạng 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, thì sau đây là cách gỡ lỗi:

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

Trang tổng quan về 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 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ề khoá chế độ thức một phần quá mức 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 các khoá chế độ thức quá mức do trình chạy/công việc giữ

Bạn có thể xác định các 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

Bạn có thể xem danh sách đầy đủ các biến thể của tên khoá chế độ thức do trình chạy giữ 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ô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ường xuyên thử lại 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ị được kết nối (API cấp 26 trở lên). Công cụ này cho thấy 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 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 không thành công hoặc thử lại do gặp phải các 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 trong thực tế các trình chạy có khoá chế độ thức quá mứ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 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 lượng 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 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 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 một số phương thức: 

• 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 tài nguyên 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 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à 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 dấu vết trạng thái của 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 tiến trình. Các dấu vết mà chúng ta sẽ tập trung 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à 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ố hàng đầu gây ra tình trạng sử dụng quá mức.

Sau đây là truy vấn mẫu 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 nhiều quyền kiểm soá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 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ộ.

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 từ 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 và triển khai đúng cách các 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.