Nhận thấy rằng tình trạng tiêu hao pin quá mức là điều đầu tiên trong tâm trí của người dùng Android, Google đã thực hiện các bước quan trọng để giúp nhà phát triển tạo ra các ứng dụng tiết kiệm pin hơn. Vào ngày 1 tháng 3 năm 2026, Cửa hàng Google Play bắt đầu triển khai các biện pháp xử lý chất lượng kỹ thuật về tính năng khoá chế độ thức để cải thiện tình trạng hao pin. Biện pháp xử lý này sẽ được ra mắt dần dần cho các ứng dụng chịu ảnh hưởng trong những tuần tiếp theo. Những ứng dụng liên tục vượt quá ngưỡng "Khoá chế độ thức một phần quá mức" trong Android vitals có thể chịu ảnh hưởng rõ rệt đến sự hiện diện của ứng dụng trên Cửa hàng Play, bao gồm cả việc nhận cảnh báo trên trang thông tin ứng dụng trên Cửa hàng Play và bị loại khỏi các nền tảng khám phá như đề xuất.

Người dùng có thể thấy cảnh báo trên trang thông tin của bạn trên Cửa hàng Play nếu ứng dụng của bạn vượt quá ngưỡng hành vi xấu. 

Sáng kiến này đã nâng hiệu suất pin lên thành một chỉ số quan trọng cốt lõi cùng với các chỉ số về độ ổn định như sự cố và lỗi ANR. "Ngưỡng hành vi xấu" được xác định là việc giữ một khoá chế độ thức một phần không được miễn trừ trong trung bình ít nhất 2 giờ khi màn hình tắt trong hơn 5% số phiên của người dùng trong 28 ngày qua. Một khoá chế độ thức được miễn trừ nếu đó là một khoá chế độ thức do hệ thống giữ và mang lại lợi ích rõ ràng cho người dùng mà không thể tối ưu hoá thêm, chẳng hạn như phát âm thanh, truy cập vị trí hoặc chuyển dữ liệu do người dùng yêu cầu. Bạn có thể xem định nghĩa đầy đủ về khoá chế độ thức quá mức trong tài liệu Android vitals.

Trong khuôn khổ sáng kiến đang diễn ra của chúng tôi nhằm cải thiện thời lượng pin trên toàn bộ hệ sinh thái Android, chúng tôi đã phân tích hàng nghìn ứng dụng và cách chúng sử dụng khoá chế độ thức một phần. Mặc dù đôi khi cần có khoá chế độ thức, nhưng chúng tôi thường thấy các ứng dụng giữ khoá chế độ thức một cách không hiệu quả hoặc không cần thiết, trong khi có các giải pháp hiệu quả hơn. Blog này sẽ trình bày những trường hợp phổ biến nhất khi khoá chế độ thức quá mức xảy ra và các đề xuất của chúng tôi để tối ưu hoá khoá chế độ thức.Chúng tôi đã thấy được thành công có thể đo lường được từ các đối tác như WHOOP, những người đã tận dụng các đề xuất này để tối ưu hoá hành vi ở chế độ nền.

Sử dụng dịch vụ trên nền trước so với khoá chế độ thức một phần

Chúng tôi thường thấy nhà phát triển gặp khó khăn trong việc hiểu sự khác biệt giữa hai khái niệm khi thực thi ở chế độ nền: dịch vụ trên nền trước và khoá chế độ thức một phần.

Dịch vụ trên nền trước là một API vòng đời báo hiệu cho hệ thống rằng một ứng dụng đang thực hiện công việc mà người dùng có thể nhận thấy và không nên bị buộc tắt để thu hồi bộ nhớ, nhưng dịch vụ này không tự động ngăn CPU chuyển sang chế độ ngủ khi màn hình tắt. Ngược lại, khoá chế độ thức một phần là một cơ chế được thiết kế đặc biệt để giữ cho CPU hoạt động ngay cả khi màn hình tắt. 

Mặc dù dịch vụ trên nền trước thường cần thiết để tiếp tục hành động của người dùng, nhưng việc thu thập khoá chế độ thức một phần theo cách thủ công chỉ cần thiết khi kết hợp với dịch vụ trên nền trước trong thời gian hoạt động của CPU. Ngoài ra, bạn không cần sử dụng khoá chế độ thức nếu đã sử dụng một API giúp thiết bị luôn ở trạng thái thức. 

Tham khảo sơ đồ quy trình trong Chọn API phù hợp để giữ cho thiết bị luôn ở trạng thái thức để đảm bảo bạn hiểu rõ về công cụ cần sử dụng nhằm tránh thu thập khoá chế độ thức trong những trường hợp không cần thiết.

Thư viện bên thứ ba thu thập khoá chế độ thức

Thông thường, một ứng dụng sẽ phát hiện thấy rằng ứng dụng đó bị gắn cờ vì khoá chế độ thức quá mức do SDK bên thứ ba hoặc API hệ thống giữ thay cho ứng dụng. Để xác định và giải quyết các khoá chế độ thức này, bạn nên thực hiện các bước sau:

• Kiểm tra Android vitals: Tìm tên chính xác của khoá chế độ thức gây lỗi trong trang tổng quan về khoá chế độ thức một phần quá mức. Tham chiếu chéo tên này với hướng dẫn Xác định khoá chế độ thức do các API khác tạo để xem khoá chế độ thức đó có được tạo bởi một API hệ thống đã biết hoặc thư viện Jetpack hay không. Nếu có, bạn có thể cần tối ưu hoá việc sử dụng API và có thể tham khảo hướng dẫn được đề xuất.
• Ghi lại dấu vết hệ thống: Nếu không thể dễ dàng xác định khoá chế độ thức, hãy tái tạo vấn đề về khoá chế độ thức cục bộ bằng cách sử dụng dấu vết hệ thống và kiểm tra dấu vết đó bằng Giao diện người dùng Perfetto. Bạn có thể tìm hiểu thêm về cách thực hiện việc này trong phần Gỡ lỗi các loại khoá chế độ thức quá mức khác của bài đăng này trên blog.
• Đánh giá các giải pháp thay thế: Nếu một thư viện không hiệu quả của bên thứ ba chịu trách nhiệm và không thể định cấu hình để tôn trọng thời lượng pin, hãy cân nhắc việc thông báo vấn đề này cho chủ sở hữu SDK, tìm một SDK thay thế hoặc tự xây dựng chức năng.

Các trường hợp phổ biến của khoá chế độ thức

Dưới đây là thông tin chi tiết về một số trường hợp sử dụng cụ thể mà chúng tôi đã xem xét, cùng với đường dẫn được đề xuất để tối ưu hoá việc triển khai khoá chế độ thức.

Tải lên hoặc tải xuống do người dùng yêu cầu

Ví dụ về các trường hợp sử dụng:

• Các ứng dụng truyền trực tuyến video mà người dùng kích hoạt quá trình tải một tệp lớn xuống để truy cập ngoại tuyến.
• Các ứng dụng sao lưu nội dung nghe nhìn mà người dùng kích hoạt quá trình tải ảnh gần đây lên thông qua lời nhắc thông báo.

Cách giảm khoá chế độ thức: 

• Không thu thập khoá chế độ thức theo cách thủ công. Thay vào đó, hãy sử dụng API Chuyển dữ liệu do người dùng yêu cầu (UIDT). Đây là đường dẫn được chỉ định cho các tác vụ chuyển dữ liệu chạy trong thời gian dài do người dùng yêu cầu và được miễn tính toán khoá chế độ thức quá mức.

Đồng bộ hoá một lần hoặc định kỳ ở chế độ nền

Ví dụ về các trường hợp sử dụng:

• Một ứng dụng thực hiện đồng bộ hoá định kỳ ở chế độ nền để tìm nạp dữ liệu cho quyền truy cập ngoại tuyến. 
• Các ứng dụng máy đếm bước chân tìm nạp số bước theo định kỳ.

Cách giảm khoá chế độ thức:

• Không thu thập khoá chế độ thức theo cách thủ công. Sử dụng WorkManager được định cấu hình cho công việc một lần hoặc định kỳ. WorkManager tôn trọng tình trạng của hệ thống bằng cách phân lô các tác vụ và có khoảng thời gian định kỳ tối thiểu (15 phút), thường là đủ cho các bản cập nhật ở chế độ nền. 
• Nếu bạn xác định được khoá chế độ thức do WorkManager hoặc JobScheduler tạo với mức sử dụng khoá chế độ thức cao, thì có thể là do bạn đã định cấu hình sai trình thực thi để không hoàn tất trong một số trường hợp. Hãy cân nhắc việc phân tích các lý do dừng trình thực thi, đặc biệt nếu bạn thấy có nhiều trường hợp STOP_REASON_TIMEOUT. 

workManager.getWorkInfoByIdFlow(syncWorker.id)
  .collect { workInfo ->
      if (workInfo != null) {
        val stopReason = workInfo.stopReason
        logStopReason(syncWorker.id, stopReason)
      }
  }

• Ngoài việc ghi nhật ký các lý do dừng trình thực thi, hãy tham khảo tài liệu của chúng tôi về gỡ lỗi trình thực thi. Ngoài ra, hãy cân nhắc việc thu thập và phân tích dấu vết hệ thống để hiểu thời điểm thu thập và phát hành khoá chế độ thức.
• Cuối cùng, hãy xem nghiên cứu điển hình của chúng tôi với WHOOP, nơi họ có thể phát hiện ra vấn đề về cấu hình của trình thực thi và giảm đáng kể tác động của khoá chế độ thức.

Giao tiếp qua Bluetooth

Ví dụ về các trường hợp sử dụng:

• Ứng dụng quản lý thiết bị đồng hành nhắc người dùng ghép nối thiết bị bên ngoài qua Bluetooth.
• Ứng dụng quản lý thiết bị đồng hành lắng nghe các sự kiện phần cứng trên thiết bị bên ngoài và thay đổi mà người dùng có thể thấy trong thông báo.
• Người dùng của ứng dụng thiết bị đồng hành bắt đầu chuyển tệp giữa thiết bị di động và thiết bị Bluetooth.
• Ứng dụng quản lý thiết bị đồng hành thỉnh thoảng cập nhật chương trình cơ sở cho thiết bị bên ngoài qua Bluetooth.

Cách giảm khoá chế độ thức:

• Sử dụng ghép nối thiết bị đồng hành để ghép nối các thiết bị Bluetooth nhằm tránh thu thập khoá chế độ thức theo cách thủ công trong quá trình ghép nối Bluetooth. 
• Tham khảo hướng dẫn Giao tiếp ở chế độ nền để hiểu cách thực hiện giao tiếp qua Bluetooth ở chế độ nền. 
• Việc sử dụng WorkManager thường là đủ nếu không có tác động nào đến người dùng đối với việc giao tiếp bị trì hoãn. Nếu bạn cho rằng cần có khoá chế độ thức theo cách thủ công, chỉ cần giữ khoá chế độ thức trong thời gian hoạt động của Bluetooth hoặc xử lý dữ liệu hoạt động.

Theo dõi vị trí

Ví dụ về các trường hợp sử dụng:

• Các ứng dụng thể dục lưu vào bộ nhớ đệm dữ liệu vị trí để tải lên sau, chẳng hạn như vẽ biểu đồ tuyến đường chạy
• Các ứng dụng giao đồ ăn tìm nạp dữ liệu vị trí với tần suất cao để cập nhật tiến trình giao hàng trong thông báo hoặc tiện ích.

Cách giảm khoá chế độ thức:

• Tham khảo hướng dẫn của chúng tôi để Tối ưu hoá việc sử dụng vị trí. Cân nhắc việc triển khai thời gian chờ, tận dụng tính năng phân lô yêu cầu vị trí hoặc sử dụng tính năng cập nhật vị trí thụ động để đảm bảo hiệu suất pin.
• Khi yêu cầu cập nhật vị trí bằng cách sử dụng API FusedLocationProvider hoặc LocationManager, hệ thống sẽ tự động kích hoạt tính năng đánh thức thiết bị trong lệnh gọi lại sự kiện vị trí. Khoá chế độ thức ngắn gọn do hệ thống quản lý này được miễn tính toán khoá chế độ thức một phần quá mức.
• Tránh thu thập khoá chế độ thức riêng biệt, liên tục để lưu vào bộ nhớ đệm dữ liệu vị trí, vì điều này là dư thừa. Thay vào đó, hãy duy trì các sự kiện vị trí trong bộ nhớ hoặc bộ nhớ cục bộ và tận dụng WorkManager để xử lý các sự kiện đó theo khoảng thời gian định kỳ.

override fun onCreate(savedInstanceState: Bundle?) {
    locationCallback = object : LocationCallback() {
        override fun onLocationResult(locationResult: LocationResult?) {
            locationResult ?: return
            // System wakes up CPU for short duration
            for (location in locationResult.locations){
                // Store data in memory to process at another time
            }
        }
    }
}

Giám sát cảm biến tần suất cao

Ví dụ về các trường hợp sử dụng:

• Các ứng dụng máy đếm bước chân thu thập thụ động số bước hoặc quãng đường đã đi. 
• Các ứng dụng an toàn giám sát các cảm biến của thiết bị để phát hiện những thay đổi nhanh chóng theo thời gian thực, nhằm cung cấp các tính năng như phát hiện sự cố hoặc phát hiện ngã.

Cách giảm khoá chế độ thức:

• Nếu sử dụng SensorManager, hãy giảm mức sử dụng xuống khoảng thời gian định kỳ và chỉ khi người dùng đã cấp quyền truy cập một cách rõ ràng thông qua hoạt động tương tác trên giao diện người dùng. Việc giám sát cảm biến tần suất cao có thể gây hao pin nhiều do số lần đánh thức và xử lý CPU xảy ra.
• Nếu bạn đang theo dõi số bước hoặc quãng đường đã đi, thay vì sử dụng SensorManager, hãy tận dụng Recording API hoặc cân nhắc sử dụng Health Connect để truy cập số bước của thiết bị trong quá khứ và tổng hợp để thu thập dữ liệu theo cách tiết kiệm pin.
• Nếu bạn đang đăng ký một cảm biến bằng SensorManager, hãy chỉ định maxReportLatencyUs là 30 giây trở lên để tận dụng tính năng phân lô cảm biến nhằm giảm thiểu tần suất gián đoạn CPU. Khi thiết bị được đánh thức sau đó bằng một điều kiện kích hoạt khác, chẳng hạn như lượt tương tác của người dùng, truy xuất vị trí hoặc lệnh theo lịch biểu, hệ thống sẽ gửi ngay dữ liệu cảm biến được lưu vào bộ nhớ đệm.

val accelerometer = sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER)

sensorManager.registerListener(this,
                 accelerometer,
                 samplingPeriodUs, // How often to sample data
                 maxReportLatencyUs // Key for sensor batching 
              )

• Nếu ứng dụng của bạn yêu cầu cả dữ liệu vị trí và dữ liệu cảm biến, hãy đồng bộ hoá quá trình truy xuất và xử lý sự kiện của chúng. Bằng cách kết hợp các chỉ số đọc cảm biến vào khoá chế độ thức ngắn gọn mà hệ thống giữ để cập nhật vị trí, bạn sẽ tránh được việc cần có khoá chế độ thức để giữ cho CPU luôn ở trạng thái thức. Sử dụng trình thực thi hoặc khoá chế độ thức có thời lượng ngắn để xử lý quá trình tải lên và xử lý dữ liệu kết hợp này.

Nhắn tin từ xa

Ví dụ về các trường hợp sử dụng:

• Các ứng dụng đồng hành giám sát video hoặc âm thanh cần giám sát các sự kiện xảy ra trên một thiết bị bên ngoài được kết nối bằng mạng cục bộ.
• Các ứng dụng nhắn tin duy trì kết nối ổ cắm mạng với biến thể dành cho máy tính.

Cách giảm khoá chế độ thức:

• Nếu các sự kiện mạng có thể được xử lý ở phía máy chủ, hãy sử dụng FCM để nhận thông tin trên máy khách. Bạn có thể chọn lên lịch cho một trình thực thi được tăng tốc nếu cần xử lý thêm dữ liệu FCM. 
• Nếu các sự kiện phải được xử lý ở phía máy khách thông qua kết nối ổ cắm, thì không cần có khoá chế độ thức để lắng nghe các gián đoạn sự kiện. Khi các gói dữ liệu đến đài Wi-Fi hoặc đài di động, phần cứng đài sẽ kích hoạt một gián đoạn phần cứng dưới dạng khoá chế độ thức của kernel. Sau đó, bạn có thể chọn lên lịch cho một trình thực thi hoặc thu thập khoá chế độ thức để xử lý dữ liệu.
• Ví dụ: nếu bạn đang sử dụng ktor-network để lắng nghe các gói dữ liệu trên ổ cắm mạng, bạn chỉ nên thu thập khoá chế độ thức khi các gói đã được gửi đến máy khách và cần được xử lý.

val readChannel = socket.openReadChannel()
while (!readChannel.isClosedForRead) {
    // CPU can safely sleep here while waiting for the next packet
    val packet = readChannel.readRemaining(1024) 
    if (!packet.isEmpty) {
         // Data Arrived: The system woke the CPU and we should keep it awake via manual wake lock (urgent) or scheduling a worker (non-urgent)
         performWorkWithWakeLock { 
              val data = packet.readBytes()
              // Additional logic to process data packets
         }
    }
}

Tóm tắt

Bằng cách áp dụng các giải pháp được đề xuất này cho các trường hợp sử dụng phổ biến như đồng bộ hoá ở chế độ nền, theo dõi vị trí, giám sát cảm biến và giao tiếp qua mạng, nhà phát triển có thể nỗ lực giảm mức sử dụng khoá chế độ thức không cần thiết. Để tiếp tục tìm hiểu, hãy đọc bài đăng khác trên blog kỹ thuật của chúng tôi hoặc xem video kỹ thuật về cách khám phá và gỡ lỗi khoá chế độ thức: Tối ưu hoá pin ứng dụng bằng chỉ số khoá chế độ thức của Android vitals. Ngoài ra, hãy tham khảo tài liệu wakelock được cập nhật của chúng tôi. Để giúp chúng tôi tiếp tục cải thiện tài nguyên kỹ thuật, vui lòng chia sẻ mọi ý kiến phản hồi bổ sung về hướng dẫn của chúng tôi trong khảo sát ý kiến phản hồi về tài liệu.