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

Khi xây dựng một ứng dụng Android cho thiết bị đeo, công việc thực sự 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ể họ phản ứng với việc tập luyện, phục hồi, 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 trong nền là yếu tố giúp họ có được những 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 của người dùng có tổng thời gian sử dụng khoá chế độ thức không được miễn trừ vượt quá 2 giờ trong khoảng thời gian 24 giờ. Mục đích 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. Cảnh báo cũng có thể được đặt 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ể 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ệ 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 trong 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ẽ giúp họ tiếp tục mang lại trải nghiệm người dùng tuyệt vời, đồng thời giảm thời gian lãng phí trong nền và duy trì khả năng kết nối cũng như đồng bộ hoá Bluetooth một cách đá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 để có thêm thông tin chi tiết về khoá chế độ thức nào đang ảnh hưởng đến chỉ số. Bằng cách tham khảo trang tổng quan về lỗi khoá một phần chế độ thức quá nhiều lần của Android vitals, họ có thể xác định nguyên nhân lớn nhất gây ra lỗi khoá một phần chế độ thức quá nhiều lần 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ụ trong nền như đồng bộ hoá định kỳ và cung cấp thông tin cập nhật định kỳ cho thiết bị đeo. 

Mặc dù nhóm biết rằng WorkManager có được 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á một phần chế độ thức quá mức được giới thiệu trong Android vitals.

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

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

WHOOP đã thiết lập cơ sở hạ tầng nội bộ để giám sát các chỉ số của 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 thực thi hết thời gian chờ thay vì hoàn tất?
3. 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 huỷ công việc.

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ộ đã gắn cờ thời gian chạy trung bình cao cho một số ít worker, giú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 cũng sử dụng Android Studio’s 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 cần quan tâm, đặc biệt tập trung vào các khoá chế độ thức liên quan, để 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 trình thực thi

WHOOP sử dụng cả tính năng lập lịch một lần và đị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 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 vào một worker cụ thể, nhưng họ không thể biết lỗi xảy ra khi worker đó là worker một lần, định kỳ hay cả hai. Vì vậy, họ đã ra mắt 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 chính xác biến thể Worker nào (định kỳ hay một lần) góp phần nhiều nhất vào các phiên có quá nhiều khoá chế độ 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 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 nằm ở cấu hình lập lịch biểu 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

Biết rằng họ cần xem xét logic bên trong trình thực thi,  nhóm đã kiểm tra 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ọ tìm những trường hợp mà công việc có thể bị kẹt 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:

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, thì whoopSensorFlow (cho biết cảm biến có được kết nối hay không) 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 khoá chế độ thức một phần cho đến khi công việc hết thời gian chờ, dẫn đến việc sử dụng khoá chế độ thức ở chế độ nền ở mức cao và việc lên lịch lại thường xuyên, không mong muốn cho SensorWorker.

Để 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 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ó 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 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. 

Nhờ những thay đổi này, nhóm nhận thấy số trường hợp công việc hết thời gian chờ mà không hoàn tất đã giảm đi, 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ủa công việc trong nền:

Bắt đầu

Nếu bạn muốn giảm tình trạng khoá một phần chế độ thức 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ố về tình trạng khoá một phần chế độ thức quá mức của ứng dụng trong Android vitals, đồng thời 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.