การสร้างแอป Android สำหรับอุปกรณ์สวมใส่หมายความว่างานที่แท้จริงจะเริ่มต้นเมื่อหน้าจอปิด WHOOP ช่วยให้สมาชิกเข้าใจว่าร่างกายตอบสนองต่อการฝึก การฟื้นฟู การนอนหลับ และความเครียดอย่างไร และสำหรับสมาชิก WHOOP จำนวนมากที่ใช้ Android การซิงค์และการเชื่อมต่อที่เชื่อถือได้ในเบื้องหลังคือสิ่งที่ทำให้ข้อมูลเชิงลึกเหล่านั้นเป็นไปได้

เมื่อต้นปีที่ผ่านมา Google Play ได้เปิดตัวเมตริกใหม่ใน Android Vitals ซึ่งก็คือ Wake Lock บางส่วนที่มากเกินไป เมตริกนี้จะวัดเปอร์เซ็นต์ของเซสชันของผู้ใช้ที่การใช้ Wake Lock สะสมที่ไม่ได้รับการยกเว้นเกิน 2 ชั่วโมงในระยะเวลา 24 ชั่วโมง เป้าหมายของเมตริกนี้คือการช่วยคุณระบุและแก้ไขแหล่งที่มาที่เป็นไปได้ของการที่แบตเตอรี่หมดเร็ว ซึ่งเป็นสิ่งสำคัญในการมอบประสบการณ์การใช้งานที่ยอดเยี่ยม

ตั้งแต่วันที่ 1 มีนาคม 2026 เป็นต้นไป เราอาจยกเว้นแอปที่ยังคงไม่เป็นไปตามเกณฑ์คุณภาพออกจากพื้นที่การค้นพบของ Google Play นอกจากนี้ เรายังอาจแสดงคำเตือนในข้อมูลสินค้าใน Google Play Store เพื่อระบุว่าแอปอาจใช้แบตเตอรี่มากกว่าที่คาดไว้

Mayank Saini วิศวกร Android อาวุโสของ WHOOP กล่าวว่า "เมตริกนี้เป็นโอกาสให้ทีมได้ยกระดับประสิทธิภาพของ Android" หลังจากที่ Android Vitals แจ้งว่าเปอร์เซ็นต์ Wake Lock บางส่วนที่มากเกินไปของแอปอยู่ที่ 15% ซึ่งเกินเกณฑ์ที่แนะนำที่ 5%

ทีมมองว่าเมตริก Android Vitals เป็นสัญญาณที่ชัดเจนว่างานเบื้องหลังของแอปทำให้ CPU ทำงานนานกว่าที่จำเป็น การแก้ไขปัญหานี้จะช่วยให้ทีมสามารถมอบประสบการณ์การใช้งานที่ยอดเยี่ยมต่อไปได้ พร้อมทั้งลดเวลาเบื้องหลังที่สูญเปล่า และรักษาการเชื่อมต่อและการซิงค์บลูทูธที่เชื่อถือได้และทันเวลา

การระบุปัญหา

ทีมได้หันไปใช้ Android Vitals ก่อนเพื่อดูข้อมูลเชิงลึกเพิ่มเติมเกี่ยวกับ Wake Lock ที่ส่งผลต่อเมตริก เพื่อดูว่าจะเริ่มต้นจากตรงไหน โดยการดูแดชบอร์ด Wake Lock บางส่วนที่มากเกินไปของ Android Vitals ทีมสามารถระบุได้ว่าปัจจัยหลักที่ทำให้เกิด Wake Lock บางส่วนที่มากเกินไปคือ Worker รายหนึ่งของ WorkManager (ระบุในแดชบอร์ดเป็นandroidx.work.impl.background.systemjob.SystemJobService) แอปใช้ WorkManager สำหรับงานเบื้องหลัง เช่น การซิงค์เป็นระยะและการส่งการอัปเดตที่เกิดขึ้นซ้ำๆ ไปยังอุปกรณ์สวมใส่ เพื่อรองรับ "ประสบการณ์การใช้งานแบบเปิดตลอดเวลา" ของ WHOOP

แม้ว่าทีมจะ ทราบ ว่า WorkManager จะได้รับ Wake Lock ขณะทำงานเบื้องหลัง แต่ก่อนหน้านี้ทีมไม่สามารถมองเห็นได้ว่างานเบื้องหลังทั้งหมด (นอกเหนือจาก WorkManager) มีการกระจายอย่างไร จนกว่าจะมีการเปิดตัวเมตริก Wake Lock บางส่วนที่มากเกินไปใน Android Vitals

เมื่อแดชบอร์ดระบุว่า WorkManager เป็นปัจจัยหลัก ทีมจึงสามารถมุ่งเน้นไปที่การระบุว่า Worker รายใด มีส่วนทำให้เกิดปัญหามากที่สุด และพยายามแก้ไขปัญหา

การใช้ประโยชน์จากเมตริกและข้อมูลภายในเพื่อจำกัดสาเหตุให้แคบลง

WHOOP ได้ตั้งค่าโครงสร้างพื้นฐานภายในเพื่อตรวจสอบเมตริก WorkManager ไว้แล้ว โดยจะตรวจสอบสิ่งต่อไปนี้เป็นระยะ

1. เวลาทำงานเฉลี่ย: Worker ทำงานนานเท่าใด
2. การหมดเวลา: Worker หมดเวลาแทนที่จะทำงานให้เสร็จบ่อยเพียงใด
3. การลองใหม่: Worker ลองใหม่บ่อยเพียงใดหากงานหมดเวลาหรือล้มเหลว
4. การยกเลิก: งานถูกยกเลิกบ่อยเพียงใด

การติดตามมากกว่าแค่ความสำเร็จและความล้มเหลวของ Worker ช่วยให้ทีมมองเห็นประสิทธิภาพของงาน

เมตริกภายในแจ้งว่า เวลาทำงานเฉลี่ยสูง สำหรับ Worker บางราย ซึ่งช่วยให้ทีมจำกัดการตรวจสอบให้แคบลงได้มากยิ่งขึ้น

นอกเหนือจากเมตริกภายในแล้ว ทีมยังใช้ Android Studio’s เครื่องมือตรวจสอบงานในเบื้องหลัง เพื่อตรวจสอบและแก้ไขข้อบกพร่องของ Worker ที่สนใจ โดยมุ่งเน้นไปที่ Wake Lock ที่เชื่อมโยง เพื่อให้สอดคล้องกับเมตริกที่แจ้งใน Android Vitals

การตรวจสอบ: การแยกความแตกต่างระหว่าง Worker แต่ละรูปแบบ

WHOOP ใช้การกำหนดเวลาแบบ ครั้งเดียว และแบบ เป็นระยะ สำหรับ Worker บางราย ซึ่งช่วยให้แอปสามารถใช้ตรรกะ Worker เดียวกันซ้ำสำหรับงานที่เหมือนกันซึ่งมีเกณฑ์ความสำเร็จเดียวกัน โดยแตกต่างกันเพียงเวลาเท่านั้น

การใช้เมตริกภายในช่วยให้ทีมจำกัดการค้นหาให้แคบลงได้เฉพาะ Worker รายหนึ่ง แต่ทีมไม่สามารถบอกได้ว่าข้อบกพร่องเกิดขึ้นเมื่อ Worker ทำงานแบบครั้งเดียว แบบเป็นระยะ หรือทั้งสองอย่าง ดังนั้น ทีมจึงเปิดตัวการอัปเดตเพื่อใช้ เมธอด setTraceTag ของ WorkManager เพื่อแยกความแตกต่างระหว่าง Worker รูปแบบครั้งเดียวกับรูปแบบเป็นระยะของ Worker รายเดียวกัน

รายละเอียดเพิ่มเติมนี้จะช่วยให้ทีมระบุได้อย่างชัดเจนว่า Worker รูปแบบใด (แบบเป็นระยะหรือแบบครั้งเดียว) มีส่วนทำให้เกิดเซสชันที่มี Wake Lock บางส่วนที่มากเกินไปมากที่สุด อย่างไรก็ตาม ทีมรู้สึกประหลาดใจเมื่อข้อมูลเผยให้เห็นว่าไม่มีรูปแบบใดที่มีส่วนทำให้เกิดปัญหามากกว่าอีกรูปแบบหนึ่ง

Manmeet Tuteja วิศวกร Android ระดับ II ของ WHOOP กล่าวว่า "การแยกรูปแบบยังช่วยให้เรายืนยันได้ว่าปัญหาเกิดขึ้นใน Worker ทั้งสอง รูปแบบ ซึ่งชี้ให้เห็นว่าปัญหาไม่ได้เกิดจากการกำหนดค่าการกำหนดเวลา แต่เกิดจากปัญหาตรรกะทางธุรกิจที่ใช้ร่วมกันภายในโค้ดของ Worker"

การเจาะลึกพฤติกรรมของ Worker และการแก้ไขสาเหตุหลัก

เมื่อทราบว่าต้องดูตรรกะ ภายใน Worker ทีมจึงตรวจสอบพฤติกรรมของ Worker อีกครั้งสำหรับ Worker ที่ถูกแจ้งระหว่างการตรวจสอบ โดยเฉพาะอย่างยิ่ง ทีมกำลังมองหาอินสแตนซ์ที่งานอาจติดขัดและไม่เสร็จสมบูรณ์

ทั้งหมดนี้สรุปได้ว่าสาเหตุหลักของ Wake Lock ที่มากเกินไปคือ

CoroutineWorker ที่ออกแบบมาให้รอการเชื่อมต่อกับเซ็นเซอร์ WHOOP ก่อนดำเนินการต่อ 

หากงานเริ่มต้นโดยไม่มีเซ็นเซอร์เชื่อมต่อ whoopSensorFlow ซึ่งระบุว่าเซ็นเซอร์เชื่อมต่ออยู่หรือไม่ จะเป็น null SensorWorker ไม่ถือว่านี่เป็นเงื่อนไขการออกก่อนกำหนดและยังคงทำงานต่อไป ซึ่งเป็นการรอการเชื่อมต่ออย่างไม่มีกำหนด ด้วยเหตุนี้ WorkManager จึงเก็บ Wake Lock บางส่วนไว้จนกว่างานจะหมดเวลา ซึ่งนำไปสู่การใช้ Wake Lock เบื้องหลังสูงและการกำหนดเวลาใหม่ของ SensorWorker ที่ไม่ต้องการบ่อยครั้ง

ทีม WHOOP ได้อัปเดตตรรกะของ Worker เพื่อตรวจสอบสถานะการเชื่อมต่อก่อนที่จะพยายามดำเนินการตรรกะทางธุรกิจหลัก

หากเซ็นเซอร์ไม่พร้อมใช้งาน Worker จะออก ซึ่งหลีกเลี่ยงสถานการณ์การหมดเวลาและปล่อย Wake Lock ข้อมูลโค้ดต่อไปนี้แสดงวิธีแก้ปัญหา

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()
            }
}

ลดเซสชันที่มี Wake Lock บางส่วนที่มากเกินไปได้ 90%

หลังจากเปิดตัวการแก้ไขแล้ว ทีมยังคงตรวจสอบแดชบอร์ด Android Vitals เพื่อยืนยันผลกระทบของการเปลี่ยนแปลง

ท้ายที่สุด WHOOP พบว่าเปอร์เซ็นต์ Wake Lock บางส่วนที่มากเกินไปลดลงจาก 15% เหลือไม่ถึง 1% เพียง 30 วัน หลังจากที่นำการเปลี่ยนแปลงไปใช้กับ Worker

การเปลี่ยนแปลงนี้ส่งผลให้ทีมพบอินสแตนซ์ที่งานหมดเวลาโดยไม่เสร็จสมบูรณ์น้อยลง ซึ่งส่งผลให้เวลาทำงานเฉลี่ยลดลง

คำแนะนำของทีม WHOOP สำหรับนักพัฒนาแอปคนอื่นๆ ที่ต้องการปรับปรุงประสิทธิภาพของงานเบื้องหลังมีดังนี้

เริ่มต้นใช้งาน

หากคุณสนใจที่จะลองลด Wake Lock บางส่วนที่มากเกินไปของแอปหรือพยายามปรับปรุงประสิทธิภาพของ Worker ให้ดูเมตริก Wake Lock บางส่วนที่มากเกินไปของแอปใน Android Vitals และอ่านเอกสารประกอบเกี่ยวกับ Wake Lock เพื่อดูแนวทางปฏิบัติแนะนำและกลยุทธ์การแก้ไขข้อบกพร่องเพิ่มเติม