Nhận thấy rằng việc tiêu hao pin quá mức là điều đầu tiên trong tâm trí 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 phương pháp xử lý chất lượng kỹ thuật khoá chế độ thức để cải thiện tình trạng tiêu hao pin. Biện pháp xử lý này sẽ được ra mắt từng bước cho các ứng dụng bị ảnh hưởng trong những tuần tới. Những ứng dụng liên tục vượt quá ngưỡng "Lỗi khoá một phần chế độ thức quá nhiều lần" 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ả cảnh báo trên trang thông tin trên Cửa hàng Play và việc bị loại trừ 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à giữ chế độ khoá chế độ thức một phần không được miễn trừ trong ít nhất 2 giờ trung bình khi màn hình tắt trong hơn 5% số phiên người dùng trong 28 ngày qua. Khoá chế độ thức được miễn trừ nếu đó là 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ào vị trí hoặc chuyển dữ liệu do người dùng khởi tạo. Bạn có thể xem định nghĩa đầy đủ về lỗi khoá chế độ thức quá mức trong tài liệu về Android vitals.

Trong khuôn khổ sáng kiến không ngừng 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á đánh thức một phần. Mặc dù đôi khi khoá đánh thức là cần thiết, nhưng chúng tôi thường thấy các ứng dụng giữ khoá này một cách không hiệu quả hoặc không cần thiết, trong khi có những 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 mà khoá đánh thức xảy ra quá nhiều và các đề xuất của chúng tôi để tối ưu hoá khoá đánh thức.  Chúng tôi đã nhận thấy những thành công đáng kể 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á đánh thức một phần

Chúng tôi nhận thấy các nhà phát triển thường gặp khó khăn trong việc phân biệt hai khái niệm khi thực hiện hoạt động thực thi ở chế độ nền: dịch vụ trên nền trước và khoá đánh 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ị loại bỏ để giải phóng bộ nhớ, nhưng dịch vụ này không tự động ngăn CPU chuyển sang trạng thái 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 một hành động của người dùng, nhưng việc thu nhận thủ công khoá chế độ thức một phần 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ị ở trạng thái thức. 

Tham khảo biểu đồ quy trình trong phần 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 dùng nhằm tránh thu thập khoá đánh 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 các khoá đánh thức

Thông thường, một ứng dụng sẽ phát hiện thấy ứng dụng đó bị gắn cờ do SDK hoặc API hệ thống của bên thứ ba thay mặt cho ứng dụng giữ quá nhiều khoá đánh thức. Để xác định và giải quyết các khoá đánh thức này, bạn nên làm theo 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 ra lỗi trong trang tổng quan về lỗi khoá một phần chế độ thức quá nhiều lần. Tham chiếu chéo tên này với hướng dẫn Xác định khoá đánh thức do các API khác tạo để xem khoá đó có phải do một API hệ thống hoặc thư viện Jetpack đã biết tạo 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 dễ dàng xác định được khoá chế độ thức, hãy tái tạo vấn đề về khoá chế độ thức cục bộ bằng dấu vết hệ thống và kiểm tra 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á đánh 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 trao đổi vấn đề này với 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 thường gặp về 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 lộ trình được đề xuất để tối ưu hoá việc triển khai khoá chế độ thức.

Người dùng bắt đầu tải lên hoặc tải xuống

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

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

Cách giảm số lượng khoá đánh 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 Lệnh 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 khởi tạo và được miễn tính toán khoá chế độ thức quá mức.

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

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

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

Cách giảm số lượng khoá đánh 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 hệ thống bằng cách xử lý hàng loạt 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 các khoá chế độ thức do WorkManager hoặc JobScheduler tạo ra 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 worker để không hoàn tất trong một số trường hợp. Hãy cân nhắc phân tích lý do dừng hoạt động của worker, đặc biệt nếu bạn thấy STOP_REASON_TIMEOUT xuất hiện nhiều lần. 

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

• Ngoài việc ghi lại lý do dừng worker, hãy tham khảo tài liệu của chúng tôi về gỡ lỗi worker. 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  để biết thời điểm khoá đánh thức được thu thập và phát hành.
• Cuối cùng, hãy xem nghiên cứu điển hình của chúng tôi với WHOOP. Trong đó, họ đã có thể phát hiện ra một vấn đề về cấu hình của các worker và giảm đáng kể tác động của khoá đánh thức.

Giao tiếp 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 sẽ lắng nghe các sự kiện phần cứng trên một thiết bị bên ngoài và thay đổi mà người dùng thấy trong thông báo.
• Người dùng ứ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 một thiết bị bên ngoài qua Bluetooth.

Cách giảm số lượng khoá đánh 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 nhận được khoá chế độ thức thủ công trong quá trình ghép nối Bluetooth. 
• Tham khảo hướng dẫn về Giao tiếp ở chế độ nền để hiểu cách 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 thông báo bị trì hoãn. Nếu cần có khoá chế độ thức thủ công, bạn chỉ nên giữ khoá chế độ thức trong thời gian diễn ra hoạt động 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 dữ liệu vị trí vào bộ nhớ đệm để tải lên sau, chẳng hạn như vẽ tuyến đường chạy
• Ứng dụng giao đồ ăn lấy dữ liệu vị trí với tần suất cao để cập nhật tiến trình giao hàng trong giao diện người dùng thông báo hoặc tiện ích.

Cách giảm số lượng khoá đánh thức: 

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

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

• Ứng dụng đo số bước chân thu thập số bước chân hoặc quãng đường đã đi một cách thụ động. 
• Các ứng dụng an toàn giám sát cảm biến trên 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 tai nạn hoặc phát hiện tình trạng bị ngã.

Cách giảm số lượng khoá đánh thức: 

• Nếu sử dụng SensorManager, hãy giảm mức sử dụng xuống các 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 một 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ể tiêu hao nhiều pin do số lần CPU hoạt động và xử lý.
• 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 vào số bước đã đi trên thiết bị (dữ liệu trong quá khứ và dữ liệu tổng hợp) nhằm 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 từ 30 giây trở lên để tận dụng tính năng tạo 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 một 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 tận dụng các chỉ số cảm biến trên khoá chế độ thức ngắn mà hệ thống giữ lại để cập nhật vị trí, bạn sẽ không cần khoá chế độ thức để giữ cho CPU hoạt động. Sử dụng một worker hoặc khoá chế độ thức có thời lượng ngắn để xử lý việc 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: 

• Ứng dụng đồng hành giám sát âm thanh hoặc video 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ộ.
• Ứng dụng nhắn tin duy trì kết nối socket mạng với phiên bản dành cho máy tính.

Cách giảm số lượng khoá đánh 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 worker 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 một kết nối ổ cắm, thì bạn không cần 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 nhân.Sau đó, bạn có thể chọn lên lịch cho một worker hoặc lấy một khoá chế độ thức để xử lý dữ liệu.
• Ví dụ: nếu đang dùng ktor-network để theo dõi các gói dữ liệu trên một ổ cắm mạng, bạn chỉ nên lấy khoá đánh 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 những 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 mạng, nhà phát triển có thể 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á đánh thức: Tối ưu hoá pin của ứng dụng bằng chỉ số khoá đánh thức Android vitals. Ngoài ra, hãy tham khảo tài liệu mới cập nhật về wakelock. Để giúp chúng tôi tiếp tục cải thiện các tài nguyên kỹ thuật, vui lòng chia sẻ thêm ý kiến phản hồi 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.