Việc tạo một ứng dụng Android cho thiết bị đeo có nghĩa là công việc thực sự bắt đầu khi màn hình tắt. WHOOP giúp các thành viên hiểu được cách cơ thể phản ứng với quá trình tập luyện, phục hồi, giấc ngủ và căng thẳng. Đối với nhiều thành viên WHOOP sử dụng Android, khả năng đồng bộ hoá và kết nối đáng tin cậy ở chế độ nền là những yếu tố giúp họ có được thông tin chi tiết đó.

Đầu năm nay, Google Play đã phát hành một chỉ số mới trong Android vitals: Tỷ lệ khoá chế độ thức một phần quá mức. Chỉ số này đo lường tỷ lệ phần trăm số phiên người dùng mà trong đó, mức sử dụng khoá chế độ thức tích luỹ, không được miễn trừ vượt quá 2 giờ trong khoảng thời gian 24 giờ. Mục tiêu của chỉ số này là giúp bạn xác định và giải quyết các nguồn có thể gây tiêu hao pin. Đây là điều quan trọng để mang lại trải nghiệm tuyệt vời cho người dùng.

Kể từ ngày 1 tháng 3 năm 2026, những ứng dụng vẫn không đáp ứng ngưỡng chất lượng có thể bị loại trừ khỏi các nền tảng khám phá của Google Play. Một cảnh báo cũng có thể xuất hiện trên trang thông tin trên Cửa hàng Play, cho biết ứng dụng có thể tiêu hao nhiều pin hơn dự kiến.

Theo Mayank Saini, Kỹ sư Android cấp cao tại WHOOP,  điều này "mang đến cho nhóm cơ hội nâng cao hiệu quả của Android", sau khi Android vitals gắn cờ tỷ lệ khoá chế độ thức một phần quá mức của ứng dụng là 15% (vượt quá ngưỡng 5% được đề xuất).

Nhóm này xem chỉ số Android vitals là một tín hiệu rõ ràng cho thấy công việc ở chế độ nền của họ đang giữ CPU ở trạng thái hoạt động lâu hơn mức cần thiết. Việc giải quyết vấn đề này sẽ giúp họ tiếp tục mang lại trải nghiệm tuyệt vời cho người dùng, đồng thời giảm thời gian hoạt động không cần thiết ở chế độ nền, cũng như duy trì kết nối và đồng bộ hoá Bluetooth đáng tin cậy và kịp thời.

Xác định vấn đề

Để tìm ra điểm bắt đầu, trước tiên, nhóm đã chuyển sang Android vitals để biết thêm thông tin chi tiết về những khoá đánh thức đang ảnh hưởng đến chỉ số này. Bằng cách tham khảo trang tổng quan Android vitals về lỗi khoá một phần chế độ thức quá nhiều, họ đã xác định được nguyên nhân chính gây ra lỗi khoá một phần chế độ thức quá nhiều là một trong các worker WorkManager (được xác định trong trang tổng quan là androidx.work.impl.background.systemjob.SystemJobService). Để hỗ trợ "trải nghiệm luôn bật" của WHOOP, ứng dụng này sử dụng WorkManager cho các tác vụ trong nền như đồng bộ hoá định kỳ và gửi các bản cập nhật định kỳ đến thiết bị đeo. 

Mặc dù nhóm biết rằng WorkManager sẽ nhận được một khoá chế độ thức trong khi thực thi các tác vụ ở chế độ nền, nhưng trước đây họ không biết cách phân phối tất cả công việc ở chế độ nền (ngoài WorkManager) cho đến khi chỉ số khoá chế độ thức một phần quá mức được giới thiệu trong Android vitals.

Khi trang tổng quan xác định WorkManager là yếu tố chính gây ra vấn đề, nhóm đã có thể tập trung nỗ lực vào việc xác định những worker nào đóng góp nhiều nhất và tìm cách giải quyết vấn đề.

Sử dụng các chỉ số và dữ liệu nội bộ để thu hẹp phạm vi nguyên nhân

WHOOP đã thiết lập cơ sở hạ tầng nội bộ để theo dõi các chỉ số WorkManager. Họ định kỳ giám sát:

1. Thời gian chạy trung bình: Trình thực thi chạy trong bao lâu?
2. Thời gian chờ: Tần suất trình chạy hết thời gian chờ thay vì hoàn thành là bao nhiêu?
3. Số lần thử lại: Trình thực thi thử lại bao nhiêu lần nếu công việc hết thời gian chờ hoặc không thành công?
4. Số lần huỷ: Công việc bị huỷ bao nhiêu lần?

Việc theo dõi không chỉ thành công và thất bại của nhân viên giúp nhóm nắm được hiệu quả công việc của họ.

Các chỉ số nội bộ được gắn cờ thời gian chạy trung bình cao cho một số ít worker, cho phép họ thu hẹp phạm vi điều tra hơn nữa. 

Ngoài các chỉ số nội bộ, nhóm này cũng sử dụng Công cụ kiểm tra tác vụ trong nền của Android Studio để kiểm tra và gỡ lỗi các worker mà họ quan tâm, đặc biệt là các khoá đánh thức liên kết, nhằm điều chỉnh cho phù hợp với chỉ số được gắn cờ trong Android vitals.

Điều tra: Phân biệt giữa các biến thể của worker

WHOOP sử dụng cả chế độ lập lịch một lần và chế độ lập lịch định kỳ cho một số worker. Điều này cho phép ứng dụng sử dụng lại cùng một logic Worker cho các tác vụ giống hệt nhau với cùng tiêu chí thành công, chỉ khác nhau về thời gian.

Việc sử dụng các chỉ số nội bộ giúp họ thu hẹp phạm vi tìm kiếm xuống một worker cụ thể, nhưng họ không thể biết liệu lỗi có xảy ra khi worker là một lần, định kỳ hay cả hai. Vì vậy, họ đã triển khai một bản cập nhật để sử dụng phương thức setTraceTag của WorkManager nhằm phân biệt giữa các biến thể một lần và định kỳ của cùng một Worker.

Thông tin chi tiết bổ sung này sẽ giúp họ xác định rõ ràng biến thể Worker nào (định kỳ hoặc một lần) đóng góp nhiều nhất vào các phiên có quá nhiều khoá đánh thức một phần. Tuy nhiên, nhóm đã rất ngạc nhiên khi dữ liệu cho thấy không có biến thể nào đóng góp nhiều hơn biến thể còn lại.

Manmeet Tuteja, Kỹ sư Android cấp II tại WHOOP cho biết "việc chia tách đó cũng giúp chúng tôi xác nhận rằng vấn đề đang xảy ra ở cả hai biến thể, điều này cho thấy vấn đề không phải do cấu hình lập lịch mà là do một vấn đề về logic nghiệp vụ dùng chung trong quá trình triển khai worker".

Tìm hiểu sâu hơn về hành vi của worker và khắc phục nguyên nhân gốc

Khi biết rằng họ cần xem xét logic trong trình thực thi,  nhóm đã xem xét lại hành vi của trình thực thi đối với những trình thực thi đã được gắn cờ trong quá trình điều tra. Cụ thể, họ đang tìm kiếm những trường hợp mà công việc có thể bị tắc nghẽn và không hoàn thành.

Tất cả những điều này đã dẫn đến việc tìm ra nguyên nhân gốc rễ của tình trạng khoá chế độ thức quá mức:

CoroutineWorker được thiết kế để chờ kết nối với cảm biến WHOOP trước khi tiếp tục. 

Nếu công việc bắt đầu mà không có cảm biến nào được kết nối, thì whoopSensorFlow (cho biết liệu cảm biến có được kết nối hay không) sẽ là null. SensorWorker không coi đây là điều kiện thoát sớm và tiếp tục chạy, chờ kết nối vô thời hạn. Do đó, WorkManager giữ một phần khoá chế độ thức cho đến khi hết thời gian chờ của tác vụ, dẫn đến việc sử dụng khoá chế độ thức trong nền ở mức cao và việc lên lịch lại SensorWorker thường xuyên và không mong muốn.

Để giải quyết vấn đề này, nhóm WHOOP đã cập nhật logic của worker để kiểm tra trạng thái kết nối trước khi cố gắng thực thi logic nghiệp vụ cốt lõi.

Nếu không có cảm biến, worker sẽ thoát, tránh trường hợp hết thời gian chờ và giải phóng khoá chế độ thức. Đoạn mã sau đây cho thấy giải pháp:

class SensorWorker(appContext: Context, params: WorkerParameters): CoroutineWorker(appContext, params) {
   override suspend fun doWork(): Result {
      ...
      // Check the sensor state and perform work or return failure
       return whoopSensorFlow.replayCache
            .firstOrNull()
            ?.let { cachedData ->
                processSensorData(cachedData)
                Result.success()
            } ?: run {
                Result.failure()
            }
}

Giảm 90% số phiên có tỷ lệ khoá chế độ thức một phần quá mức

Sau khi triển khai bản sửa lỗi, nhóm này tiếp tục theo dõi trang tổng quan Android vitals để xác nhận tác động của các thay đổi. 

Cuối cùng, WHOOP nhận thấy tỷ lệ khoá chế độ thức một phần quá mức giảm từ 15% xuống dưới 1% chỉ sau 30 ngày triển khai các thay đổi đối với Worker của họ. 

Nhờ những thay đổi này, nhóm đã ghi nhận ít trường hợp công việc hết thời gian chờ mà chưa hoàn thành hơn, dẫn đến thời gian chạy trung bình thấp hơn. 

Lời khuyên của nhóm WHOOP dành cho những nhà phát triển khác muốn cải thiện hiệu suất của hoạt động ở chế độ nền:

Bắt đầu

Nếu bạn muốn giảm số lượng lỗi khoá một phần chế độ thức quá mức của ứng dụng hoặc muốn cải thiện hiệu suất của worker, hãy xem chỉ số về lỗi khoá một phần chế độ thức quá mức của ứng dụng trong Android vitals và xem tài liệu về khoá chế độ thức để biết thêm các phương pháp hay và chiến lược gỡ lỗi.