Cách WHOOP giảm hơn 90% số phiên khoá chế độ thức một phần quá mức

Việc xây dựng 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 trên Android, tính 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: 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 của 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 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 tiếp tục 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 của ứng dụng trên Cửa hàng Google Play, cho biết ứng dụng có thể sử dụng 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ệ phần trăm 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ữ cho CPU hoạt động lâu hơn mức cần thiết. Việc giải quyết vấn đề này sẽ cho phé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 lãng phí ở chế độ nền và duy trì kết nối Bluetooth đáng tin cậy và kịp thời cũng như đồng bộ hoá.

Xác định vấn đề

Để tìm hiểu nơi bắt đầu, trước tiên, nhóm này đã chuyển sang Android vitals để biết thêm thông tin chi tiết về những khoá chế độ thức đang ảnh hưởng đến chỉ số. Bằng cách tham khảo trang tổng quan về khoá chế độ thức một phần quá mức của Android vitals, họ có thể xác định thành phần đóng góp lớn nhất vào khoá chế độ thức một phần quá mức là một trong các worker của 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ụ ở chế độ nền như đồng bộ hoá định kỳ và cung cấp các bản cập nhật định kỳ cho thiết bị đeo. 

Mặc dù nhóm này biết rằng WorkManager thu thập khoá chế độ thức khi thực thi các tác vụ ở chế độ nền, nhưng trước đây, họ không có thông tin về cách phân phối tất cả công việc ở chế độ nền (không chỉ 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à thành phần đóng góp chính, nhóm này có thể tập trung nỗ lực vào việc xác định worker nào đang đóng góp nhiều nhất và nỗ lực giải quyết vấn đề.

Tận dụng các chỉ số và dữ liệu nội bộ để thu hẹp 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ọ theo dõi định kỳ:

1. Thời gian chạy trung bình: Worker chạy trong bao lâu?
2. Thời gian chờ: Tần suất worker hết thời gian chờ thay vì hoàn tất?
3. Số lần thử lại: Tần suất worker thử lại 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ỷ: Tần suất công việc bị huỷ?

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

Các chỉ số nội bộ đã gắn cờ thời gian chạy trung bình cao cho một số 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 tập trung vào các khoá chế độ thức được liên kết, để 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ể worker

WHOOP sử dụng cả một lần và định kỳ lịch trình 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 có 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 lỗi xảy ra khi worker là một lần, định kỳ hay cả hai. Vì vậy, họ đã triển khai 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ẽ cho phép họ xác định rõ ràng biến thể Worker nào (định kỳ hoặc một lần) đang đóng góp nhiều nhất vào các phiên có khoá chế độ thức một phần quá mức. Tuy nhiên, nhóm này đã 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 II tại WHOOP cho biết "việc phân 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 là cấu hình lên lịch mà là vấn đề về logic kinh doanh 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 rễ

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

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 các khoá chế độ thức quá mức:

Một 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, 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ữ khoá chế độ thức một phần cho đến khi công việc hết thời gian chờ, dẫn đến mức sử dụng khoá chế độ thức ở chế độ nền 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 worker để kiểm tra trạng thái kết nối trước khi cố gắng thực thi logic kinh doanh cốt lõi.

Nếu cảm biến không hoạt động, 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ó 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 đã chứng kiến tỷ lệ phần trăm khoá chế độ thức một phần quá mức giảm từ 15% xuống dưới 1% chỉ 30 ngày sau khi triển khai các thay đổi đối với Worker của họ. 

Do các thay đổi này, nhóm này đã thấy ít trường hợp công việc hết thời gian chờ mà không hoàn tất, 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 các nhà phát triển khác muốn cải thiện hiệu quả công việc ở chế độ nền:

Bắt đầu

Nếu bạn muốn giảm số lượng khoá chế độ thức một phần quá mức của ứng dụng hoặc cải thiện hiệu quả của worker, hãy xem chỉ số khoá chế độ thức một phần 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 nhất và chiến lược gỡ lỗi.